Конфликтующее имя сервера Nginx для субдомена

Question

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

Куда я иду не так?

18

nginx ssl virtualhost

Источник

RockJake28 26 июл '15 в 14:42

9 ответов

Решение

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

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

4

Источник

hanxue 23 дек '15 в 10:39

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

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

Исправлено путем изменения на:

server_name myserver.example.com;

4

Источник

Steve Tauber 08 май '16 в 14:11

Также проверьте каждый файл в /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

3

Источник

SherylHohman 13 ноя '18 в 21:24

Другая возможная причина появления этого сообщения: дополнительные блоки сервера, созданные с помощью certbot для получения сертификатов от Let's Encrypt.

Оказалось, что каждый запуск certbot добавлял несколько серверных блоков в мои файлы конфигурации nginx, эти записи можно идентифицировать по комментарию «управляется certbot». Эти дополнительные блоки обрабатывают, например, перенаправление http на https. Некоторое время они не беспокоили nginx, но когда я добавил еще один блок сервера для субдомена через /sites-available, эти предупреждения о «конфликтующих именах серверов» действительно всплыли.

1

Источник

mschomm 14 фев '21 в 15:09

В какой-то момент я сделал резервную копию файла конфигурации NGINX «по умолчанию» . Это и было причиной проблемы, поскольку файл резервной копии также рассматривался как файл конфигурации, что делало его дубликатом. Удаление этого резервного файла устранило проблему.

0

Источник

Libby Lebyane 26 сен '21 в 23:17

Мой случай был таков, что у меня было несколько поддоменов и конфиг для каждого из них. У них были правильныеserver_nameна каждом сервере. На одном сервере указан 80 порт, на втором нет (должен был быть 443). При запуске certbot я увидел это предупреждение nginx.

      server {
    root /var/www/41/html;
    index index.html;  
    server_name 41.mezinamiridici.cz;   
    location / {
        try_files $uri $uri/ /index.html;
    }

    listen 443 ssl; #this was missing
    ssl_certificate /etc/letsencrypt/live/41.mezinamiridici.cz/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/41.mezinamiridici.cz/privkey.pem; # managed by Certbot
}

server {
    if ($host = 41.mezinamiridici.cz) {
        return 301 https://$host$request_uri;
    } # managed by Certbot
    server_name 41.mezinamiridici.cz;
    listen 80;
    listen [::]:80;
}

0

Источник

Leos Literak 31 дек '20 в 09:14

У меня была такая же проблема при использовании Nginx с AWS Elastic Beanstalk и puma. Проблема заключалась в том, что существует специальный файл ngnix, который расширяет конфигурацию nginx по умолчанию и оба определяют "локальный хост сервера". Использование правильного имени сервера устранило проблему.

0

Источник

Peter T. 29 ноя '20 в 00:37

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

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

0

Источник

Dario Zadro 05 май '19 в 18:44

Другие вопросы по тегам nginx ssl virtualhost

Lloyd Wilson 26 июл '15 в 15:24 2015-07-26 15:24 · Accepted Answer · 2015-07-26 15:24

Похоже, ваши блоки 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;
}

13

Источник

Lloyd Wilson 26 июл '15 в 15:24