Конфликтующее имя сервера 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которых оба ссылались на определенный домен (то есть 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, повторно: ... Address already in useсообщение об ошибке выше:
Все , что я должен был сделать sudo fuser -k 80/tcpто service nginx restartработал как шарм!
Я нашел ответ здесь: https://easyengine.io/tutorials/nginx/trou устранение неисправностей/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, в котором я прокомментировал все настройки, кроме открытия блока сервера и закрывающей скобки ... и это вызвало конфликтную ошибку.

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