Имя конфликтующего сервера 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.

Фу

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

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

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

Исправлено изменением его на:

server_name myserver.example.com;

У вас также могут быть дополнительные файлы в /etc/nginx/sites-available/<site-name> которые связаны с /etc/nginx/sites-enabled/<site-name>.

Настройки в этих файлах могут конфликтовать с /etc/nginx/sites-available/default файл

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

В моем случае, nginx -t пройдены тесты - я получил это сообщение об ошибке при попытке запустить nginx.

Мой /etc/nginx/sites-enabled файлы были свободны от дубликатов домена (имени сервера) и имели только 1 ссылка на server_default (и нет localhost дубликаты)

Вместо этого было 2 файла в conf.d которые оба ссылались на конкретный домен (т.е. в 2 файлах была строка вроде: 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-in-use/52914/5

В моем случае я не смог найти ни одного дубликата. Однако у меня был default.conf, в котором я прокомментировал всю конфигурацию, кроме открывающего блока сервера и закрывающей скобки ... и это вызвало конфликтную ошибку.

По сути, проблема была вызвана неучтенным серверным блоком БЕЗ директивы server_name, а не дубликатом.