Nginx tên máy chủ xung đột cho tên miền phụ

Tôi hiện có một vhost chạy trên Nginx cho foo.domain.com và mọi thứ đều hoạt động tốt.

Tôi đã tạo một tệp mới cho một tên miền phụ mới mà tôi muốn thêm được gọi là bar.domain.com. Tôi sử dụng cùng một cài đặt cho cả hai.

Khi tôi khởi động lại Nginx, tôi nhận được

Restarting nginx: nginx: [warn] conflicting server name "" on 0.0.0.0:443, ignored nginx.

Khi tôi truy cập bar.domain.com, tôi thấy những gì tôi phải thấy, nhưng khi tôi truy cập foo.domain.com tôi thấy trang mà bar.domain.com liên kết đến.

Foo

upstream php-handler {
    server unix:/var/run/php5-fpm.sock;
}

server {
        listen 80;
        server_name foo.domain.com;
        return 301 https://$server_name$request_uri;
}

server {
        listen 443;

        ssl on;
        ssl_certificate      [path_foo]/cacert.pem;
        ssl_certificate_key  [path_foo]/privkey.pem;

        root [path]/foo;

        ...
}

Quán ba

server {
        listen 80;
        server_name bar.domain.com;
        return 301 https://$server_name$request_uri;
}

server {
        listen 443;

        ssl on;
        ssl_certificate      [path_bar]/cacert.pem;
        ssl_certificate_key  [path_bar]/privkey.pem;

        root [path]/bar;
}

Tôi làm sai ở đâu?

Có vẻ như các khối https của bạn cũng cần tên máy chủ, ví dụ:

server {
    listen 443;
    server_name bar.domain.com;
    ssl on;
    ssl_certificate      [path_bar]/cacert.pem;
    ssl_certificate_key  [path_bar]/privkey.pem;

    root [path]/bar;
}

Bạn cũng có thể có các tệp bổ sung /etc/nginx/sites-available/<site-name>được liên kết đến /etc/nginx/sites-enabled/<site-name>.

Các cài đặt trong các tệp đó có thể xung đột với /etc/nginx/sites-available/defaulttệp

Tôi gặp vấn đề tương tự khi vô tình có tên máy chủ trùng lặp:

server_name myserver.example.com myserver.example.com;

Đã sửa bằng cách thay đổi nó thành:

server_name myserver.example.com;

Ngoài ra kiểm tra từng tập tin /etc/nginx/conf.dcho trùng lặp.

Trong trường hợp của tôi, nginx -tđã vượt qua các bài kiểm tra - Tôi đã nhận được thông báo lỗi đó khi cố gắng khởi động nginx.

Các /etc/nginx/sites-enabledtệp của tôi không bị trùng lặp tên miền (tên máy chủ) và chỉ có 1 tham chiếu đến server_default(và không có localhostbản sao)

Thay vào đó, có 2 tệp trong conf.dđó cả hai đều tham chiếu một tên miền cụ thể (tức là 2 tệp có một dòng như : servername mydomain.com, trong đó một trong các tên miền được liệt kê trong 2 tệp).

Giải pháp của tôi: Vì vậy, hãy chắc chắn rằng tất cả các tệp conf.dchỉ tham chiếu bất kỳ servernamegiá trị cụ thể (tên miền) nào một lần, tối đa.

( không may sau khi khắc phục sự cố ở trên, bây giờ tôi nhận được:
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use) thông báo lỗi khi tôi cố gắng khởi động lại nginx.)

cập nhật : FYI, re: ... Address already in usethông báo lỗi ở trên:
Tất cả những gì tôi phải làm là sudo fuser -k 80/tcpsau đó service nginx restartlàm việc như một cơ duyên!
Tôi tìm thấy câu trả lời ở đây: https://easyengine.io/tutorials/nginx/troubledhoot/emerg-bind-fails-98-address-al yet-in-use /

update2 :
Có ý kiến ​​cho rằng một quy trình khác đang sử dụng cổng 80, (đó là lý do tại sao việc giết nó hoạt động và cũng có nghĩa là b / c nginx không chạy vào thời điểm đó).
https://community.letsencrypt.org/t/nginx-emerg-bind-to-80-fails-98-address-al yet-in-use / 52914/4

Họ cũng chỉ ra rằng việc nhìn thấy quá trình, trước khi giết nó, có thể cung cấp cái nhìn sâu sắc về những gì gây ra vấn đề.
Do đó, có lẽ tốt hơn để sử dụng một trong hai: sudo fuser -k 80/tcp(không có tùy chọn -k), theo sau là một grepcho các số quy trình.
systemctl list-unit-filesđầu ra, có thể cung cấp cái nhìn sâu sắc về quá trình xung đột

hoặc :
fuser -kivn tcp 80, trong đó:
-vin tên quy trình cùng với id tiến trình
-ikhiến nó nhắc nhở trước khi giết
https://community.letsencrypt.org/t/nginx-emerg-bind-to-80-failed-98-address-al yet- đang sử dụng / 52914/5

Trong trường hợp của tôi, tôi không thể tìm thấy bất kỳ bản sao. Tuy nhiên, tôi đã có default.conf nơi tôi nhận xét tất cả các cấu hình ngoại trừ khối máy chủ mở và khung đóng ... và điều này gây ra lỗi xung đột.

Về cơ bản, đó là một khối máy chủ không được tính đến mà không có lệnh server_name gây ra sự cố, không phải là một bản sao.