Nginx: conflicting server name — предупреждение о конфликте server_name

#Что означает предупреждение

Nginx выбирает виртуальный хост по имени из заголовка Host. Если одно имя встречается в двух блоках server на одинаковой паре адрес:порт, второй блок для этого имени игнорируется, а в журнал и вывод nginx -t попадает предупреждение. Реальная проблема в том, что запросы могут обслуживаться не тем блоком, который вы ожидаете: например, старой конфигурацией, оставшейся в sites-enabled или conf.d.

#Типичные причины

#Порядок

1. Выведите полную итоговую конфигурацию и найдите все блоки с этим именемВ терминале сервера выполните sudo nginx -T 2>&1 и сохраните вывод в защищённый файл для просмотра; предупреждение conflicting server name ... on ... ignored укажет имя хоста и listen-адрес. Найдите все строки server_name с этим именем, но учитывайте, что одинаковый домен в блоках для 80 и 443 — нормален.
2. Определите, из каких файлов они подключеныВ полном выводе nginx -T перед каждым подключённым конфигурационным файлом есть комментарий с его путём. Запишите именно файлы, которые содержат конфликтующие блоки на одинаковых адресе/порту и имени сервера; не удаляйте блок только потому, что домен встречается дважды.
3. Проверьте каталоги sites-enabled, conf.d и include в основном файлеПроверьте действующие include в nginx.conf, каталоги /etc/nginx/conf.d/ и /etc/nginx/sites-enabled/ (если они используются). Один сайт может подключаться и через символьную ссылку, и отдельным файлом; выясните, какая версия конфигурации рабочая, и сохраните её копию.
4. Удалите дубликаты или объедините блокиЕсли обнаружен настоящий дубликат, оставьте один нужный серверный блок на конкретной паре адрес/порт, а лишний отключите штатным способом панели или уберите соответствующий include после резервной копии. Не объединяйте бездумно HTTPS и HTTP: им нужны разные настройки сертификата и перенаправления.
5. Проверьте, нет ли временных файлов *.bak, *.old, *~, которыеЕсли Nginx подключает файлы через широкую маску conf.d/*, туда могли попасть резервные .old, .bak и файлы редактора. Проверьте их содержимое и расположение; переносите устаревший файл за пределы подключаемой директории, а не выполняйте rm по предложенному примеру без проверки назначения.
6. Команды для отдельных ситуацийВыберите только подходящий вариант. Это не одна последовательность: часть команд диагностирует проблему, а часть меняет настройки или данные.
   Выберите подходящий вариант — это не команды для последовательного выполнения

   Вариант 1Найти все блоки server с этим именем в итоговой конфигурации

   Linux · Терминал (Bash)КомандаНужен sudoКопировать всёВыделить

   Найти все блоки server с этим именем в итоговой конфигурации

   sudo nginx -T 2>/dev/null | grep -nE "server_name|# configuration file"

   Вариант 2Какие файлы подключены

   Linux · Терминал (Bash)КомандаНужен sudoКопировать всёВыделить

   Какие файлы подключены

   ls -l /etc/nginx/sites-enabled/ /etc/nginx/conf.d/

   sudo grep -RnE "server_name .*example\.ru" /etc/nginx/

   Вариант 3Удалить лишнюю ссылку из sites-enabled (сам файл в sites-available останется)

   Linux · Терминал (Bash)КомандаКопировать всёВыделить

   Удалить лишнюю ссылку из sites-enabled (сам файл в sites-available останется)

   ls -l /etc/nginx/sites-enabled/

   # Устаревший файл отключайте только после проверки include и сохранения резервной копии.

   Вариант 4Один блок на порт: HTTP перенаправляет на HTTPS, HTTPS обслуживает сайт

   NginxКомандаКопировать всёВыделить

   Один блок на порт: HTTP перенаправляет на HTTPS, HTTPS обслуживает сайт

   server {

   listen 80;

   server_name example.ru www.example.ru;

   return 301 https://example.ru$request_uri;

   }

   server {

   listen 443 ssl http2;

   server_name example.ru;

   ssl_certificate /etc/letsencrypt/live/example.ru/fullchain.pem;

   ssl_certificate_key /etc/letsencrypt/live/example.ru/privkey.pem;

   root /var/www/example.ru/public;

   }

   Вариант 5Проверить и применить

   Linux · Терминал (Bash)КомандаНужен sudoКопировать всёВыделить

   Проверить и применить

   sudo nginx -t && sudo systemctl reload nginx

7. Проверьте конфигурацию и перезагрузите nginxПосле изменения выполните sudo nginx -t и прочитайте не только строку test is successful, но и предупреждения; затем sudo systemctl reload nginx. Проверьте каждый конфликтовавший домен с правильным SNI/Host, включая HTTPS, чтобы убедиться, что используется нужный виртуальный хост и сертификат.

#Проверка результата

Выполните curl -I -H "Host: example.ru" http://127.0.0.1/ и убедитесь, что отвечает нужный блок (по заголовкам или содержимому). После устранения дублей предупреждение при nginx -t исчезнет. Если вы используете панель управления (ISPmanager, HestiaCP), не редактируйте её файлы вручную: панель пересоздаст конфигурацию, поэтому меняйте настройки через панель.

#Как понять, какой блок реально отвечает

Добавьте в каждый подозрительный блок свой заголовок: add_header X-Block "example-main" always; и проверьте командой curl -sI -H "Host: example.ru" http://127.0.0.1/ | grep X-Block. Так вы увидите, какая конфигурация обслуживает имя. После выявления лишних блоков удалите их и уберите заголовки. Для больших конфигураций удобно сохранить вывод nginx -T в файл и искать дубли утилитой sort | uniq -d: sudo nginx -T 2>/dev/null | grep -E "^\s*server_name" | sort | uniq -d покажет повторяющиеся строки server_name.