Ім'я сервера Nginx, що суперечить субдомену

Наразі у мене є vhost, який працює на Nginx для foo.domain.com, і все працює чудово.

Я створив новий файл для нового піддомену, який я хочу додати під назвою bar.domain.com. Я використовую однакові настройки для обох.

Коли я перезапускаю Nginx, я отримую

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

Коли я переходжу до bar.domain.com, я бачу те, що я повинен бачити, але коли я переходжу на foo.domain.com, я бачу сторінку, на яку посилання bar.domain.com.

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;

        ...
}

Бар

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;
}

Де я помиляюся?

Мені здається, що для ваших блоків https потрібні імена серверів, указані, наприклад

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;
}

Також у вас можуть бути додаткові файли /etc/nginx/sites-available/<site-name>, пов’язані з цим /etc/nginx/sites-enabled/<site-name>.

Параметри в цих файлах можуть суперечити /etc/nginx/sites-available/defaultфайлу

У мене була аналогічна проблема, коли у мене випадково було дублюване ім’я сервера:

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

Виправлено, змінивши його на:

server_name myserver.example.com;

Також перевіряйте кожен файл на /etc/nginx/conf.dнаявність дублікатів.

У моєму випадку nginx -tпройшли тести - я отримав це повідомлення про помилку при спробі запуску nginx.

Мої /etc/nginx/sites-enabledфайли не містили дублікатів домену (ім'я сервера) і мали лише 1 посилання на server_default(і жодних localhostдублікатів)

Натомість було 2 файли, в conf.dяких обидва посилалися на певний домен (тобто два файли мали рядок типу:, servername mydomain.comде одне з доменних імен було вказано у 2 файлах).

Моє рішення: Тому переконайтеся, що всі файли, в conf.dяких посилається лише будь-яке значення servername(ім'я домену), не більше одного разу.

( на жаль, після виправлення вищезгаданої проблеми, тепер я отримую:
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use) повідомлення про помилки при спробі перезапустити nginx.)

оновлення : FYI, re: ... Address already in useповідомлення про помилку вище:
Все, що я повинен був зробити, sudo fuser -k 80/tcpтоді service nginx restartпрацював як шарм!
Відповідь я знайшов тут: https://easyengine.io/tutorials/nginx/troubleshooting/emerg-bind-failed-98-address-already-in-use/

update2 :
Було запропоновано, що інший процес використовував порт 80 (саме тому його вбивство спрацювало, а також має сенс b / c nginx не працював на той час).
https://community.letsencrypt.org/t/nginx-emerg-bind-to-80-failed-98-address-already-in-use/52914/4

Вони також зазначають, що перегляд процесу, перш ніж просто вбити його, може дати зрозуміти, що викликало проблему.
Отже, краще, мабуть, використовувати або: sudo fuser -k 80/tcp(без опції -k), після чого grepцифри для цих процесів.
systemctl list-unit-filesвисновок, може дати зрозуміти про конфліктний процес

або:,
fuser -kivn tcp 80де:
-vдрукує назву процесу на додаток до ідентифікатора процесу,
-iвін підказує перед вбивством
https://community.letsencrypt.org/t/nginx-emerg-bind-to-80-failed-98-address-already- в користуванні / 52914/5

У моєму випадку я не міг знайти жодного дубліката. Однак у мене був default.conf, де я прокоментував усі налаштування, за винятком блоку сервера відкриття та дужки закриття ... і це спричинило суперечливу помилку.

В основному це було причиною проблеми, яку не враховував блок сервера БЕЗ директиви імені сервера, а не дублікат.