Nginx Linux

Nginx открывает сайт по умолчанию вместо нужного домена

  • Обновлено
  • Чтение ≈ 3 минуты
  • Нужны права администратора

Краткий ответ

Nginx выбирает виртуальный сервер по IP/порту и затем имени запроса. Если Host не совпадает с server_name, запрос может попасть в default_server для этой пары адреса и порта.

В этой статье
  1. Что означает и когда возникает ошибка
  2. Причины и как их различить
  3. Пошаговая диагностика и исправление
  4. Проверка результата
  5. Если проблема осталась

#Что означает и когда возникает ошибка

У HTTPS есть дополнительный этап выбора сертификата через SNI: неверный сертификат и неверный контент требуют отдельно проверить SSL-настройки, а не только Host. Подделанный Host нельзя принимать как доказательство нужного домена.

#Причины и как их различить

Возможная причинаКак узнатьЧто делать
Нет точного server_nameВ конфигурации пропущен домен, его вариант www или допущена опечатка.Для одного имени сайт правильный, для другого появляется стартовая страница.Проверить имена и добавить только свои подтверждённые домены.
Запрос попал на другой IP/портA/AAAA-записи или балансировщик указывают не на тот входной адрес.По IPv4 сайт верный, по IPv6 либо отдельному порту — другой.Сверить DNS, listen IPv4/IPv6 и маршрутизацию внешнего прокси.
Активен не тот виртуальный серверФайл в conf.d не подключён, приоритет default_server другой либо конфигурация не перечитана.Nginx -T не содержит ожидаемый server_name или указан другой порт.Проверить include, reload после nginx -t.

#Пошаговая диагностика и исправление

  1. Проверьте имя и адрес без изменения сервераВ браузере откройте оба адреса https://example.com/ и https://www.example.com/, подставив свой домен. Запишите, на каком появляется чужой сайт. На компьютере проверьте DNS через nslookup example.com; если есть AAAA-запись, отдельно проверьте IPv6, когда сеть поддерживает его. Не меняйте DNS наугад: отложенное обновление записей может создавать временные различия.
  2. Посмотрите фактическую конфигурациюНа сервере войдите по SSH и выполните sudo nginx -T 2>&1 | grep -nE "server_name|listen |default_server|include ". Сверьте listen 80, listen 443 ssl и IPv6-варианты с фактически задействованными адресами. Убедитесь, что нужный server_name находится в конфигурации, которую действительно читает работающий Nginx, а не только в файле панели хостинга.
  3. Выберите виртуальный сервер для теста управляемым способомНа своём компьютере команда curl --resolve example.com:443:203.0.113.10 -I https://example.com/ проверит HTTPS на выбранном IP с правильными Host и SNI; адрес 203.0.113.10 является только примером из документационной сети, его обязательно замените действительным публичным IP вашего сервера. Не применяйте -k: проверка сертификата должна остаться включённой. Если сертификат ещё не настроен, зафиксируйте ошибку отдельно.
  4. Исправьте server_name/слушающие адреса для собственного доменаЕсли в настройке отсутствует нужное имя, добавьте его в правильный server-блок и проверьте, что у него ожидаемые root либо proxy_pass, а также отдельный сертификат для HTTPS. Не указывайте чужие домены, не используйте server_name _; как универсальное исправление. Помните: _ — обычное имя, а сервер по умолчанию определяется параметром default_server для конкретного listen.
  5. Проверьте DNS и внешний проксиЕсли запрос по --resolve приходит в нужный виртуальный сервер, но без него — нет, проверьте A и AAAA у авторитетного DNS, настройки CDN и адрес назначения у балансировщика. Для IPv6 должен существовать корректно настроенный listen [::]:443 ssl или другой подходящий IPv6 listener. Если сервер не должен обслуживать IPv6, корректируйте DNS только после проверки фактической архитектуры.
  6. Безопасно примените и выполните обратную проверкуСохраните копию изменяемого файла, запустите sudo nginx -t, затем при успехе sudo systemctl reload nginx. Откройте сайт по обоим именам и проверьте сертификат. Если появился другой сайт или неверный сертификат, верните копию и повторите тест/reload, прежде чем продолжать. Сопоставьте access.log нужного виртуального сервера с тестовым запросом.
  7. Команды для отдельных ситуацийВыберите только подходящий вариант. Это не одна последовательность: часть команд диагностирует проблему, а часть меняет настройки или данные.
    Выберите подходящий вариант — это не команды для последовательного выполнения
    Вариант 1Команды на своём компьютере без sudo.
    Linux · Терминал (Bash)Команда
    Команды на своём компьютере без sudo. Замените имя и документационный IP на фактические, не отключайте проверку TLS.
    nslookup example.com
    curl --resolve example.com:443:203.0.113.10 -I https://example.com/
    Вариант 2SSH на сервере, нужен sudo; смотрите действующую конфигурацию, скрывайте приватные строки.
    Linux · Терминал (Bash)КомандаНужен sudo
    SSH на сервере, нужен sudo; смотрите действующую конфигурацию, скрывайте приватные строки.
    sudo nginx -T 2>&1 | grep -nE "server_name|listen |default_server|include "

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

Проверка: по каждому назначенному домену открывается нужный сайт с правильным сертификатом, запрос на неверный Host не обслуживается неожиданным приватным приложением.

#Если проблема осталась

Сохраните дату, точный URL без паролей и токенов, код ответа, обезличенные строки error.log и access.log за это время и перечень уже сделанных изменений. Сравните работу при обращении через публичный адрес и через внутренний балансировщик, если он есть. Если причину пока не удалось подтвердить, восстановите исходную конфигурацию из копии и передайте эти сведения администратору или разработчику приложения; не меняйте несколько параметров одновременно.

Так эту ошибку тоже называют

502 502 Bad Gateway в Nginx: причины и быстрый способ найти виновника Ответ `502 Bad Gateway` означает, что Nginx, выступая шлюзом, не смог получить корректный ответ от backend-сервера — чаще всего PHP-FPM или приложения за `proxy_pass`. С… Сайты, серверы и хостинг Nginx NginxLinux Nginx: 502 Bad Gateway с PHP-FPM — причины и решение Проверьте, запущен ли php-fpm, путь к сокету и права. Сайты, серверы и хостинг Nginx Linux 504 Nginx 504 Gateway Time-out — причины и как исправить Ошибка `504 Gateway Time-out` значит, что Nginx отправил запрос приложению (PHP-FPM, Node.js, другому серверу), но не дождался ответа за отведённое время. Чаще всего при… Сайты, серверы и хостинг Nginx NginxLinuxPHP-FPM Nginx: ERR_TOO_MANY_REDIRECTS — цикл редиректов http/https и www — причины и решение Найдите петлю редиректов в конфиге и CMS, проверьте Cloudflare и proxy. Сайты, серверы и хостинг Nginx Linux 504 Nginx: 504 Gateway Time-out — upstream не отвечает вовремя — причины и решение Nginx выдаёт 504 Gateway Time-out, когда backend (PHP-FPM, Node.js, прокси) не успевает ответить за отведённое время. Увеличьте proxy_read_timeout или fastcgi_read_timeo… Сайты, серверы и хостинг Nginx Linux

Источники и обновления

Последнее обновление статьи: 2 ноября 2026. Версии программ и интерфейсы меняются — если шаги не совпадают с вашей версией, сверяйтесь с документацией производителя.