DNS
Домен вообще резолвится и указывает на нужный IP?
Практическая диагностика · DNS и сервер
Сайт открывается по IP, но не открывается по домену: что проверить
Если сервер отвечает по IP, а привычный адрес сайта не работает, проблема обычно находится между доменным именем и веб-сервером: DNS, NS, кеш, виртуальный хост, HTTPS или редирект. Ниже — последовательность, которая помогает быстро понять, на каком именно этапе ломается путь.
Быстрый маршрут
Что проверить за первые 5 минут
Не начинаем с переустановки сертификата или правки nginx. Сначала определяем, до какого этапа запрос доходит нормально.
NS
У регистратора указаны те серверы имён, где реально создана зона?
Host
Веб-сервер знает этот домен и выбирает правильный virtual host?
HTTPS
Сертификат выпущен именно для домена и порт 443 отвечает?
Кеш
Проблема у всех или только на одном компьютере/провайдере?
Если IP открывается, это ещё не доказывает, что сайт настроен правильно.По IP может отвечать default-сайт сервера, тогда как доменный virtual host или HTTPS-конфигурация остаются сломанными.
Как устроен путь
Где именно может сломаться открытие сайта по домену
Браузер не идёт к сайту «по названию». Сначала домен преобразуется в IP, затем запрос попадает на веб-сервер, который по имени Host выбирает нужный сайт, а при HTTPS дополнительно участвуют TLS и сертификат.
Доменexample.ru
→
DNSA / AAAA
→
IPсервер
→
Hostvirtual host
→
TLSсертификат
→
СайтHTTP 200/3xx
Проверка по этой цепочке важнее случайных действий. Если DNS уже возвращает неправильный IP, нет смысла искать ошибку в PHP. Если DNS правильный, а сервер отдаёт чужой сайт, проблема скорее в virtual host. Если HTTP работает, а HTTPS нет — фокус смещается на порт 443, SNI и сертификат.
Шаг 1
Проверьте, куда домен резолвится сейчас
Для обычного сайта ключевой вопрос простой: какой IP возвращает DNS для домена и совпадает ли он с реальным сервером. Проверяем как основной домен, так и www, если он используется.
| Что видим | Что это означает | Куда смотреть дальше |
|---|---|---|
| A-запись указывает на старый IP | DNS ещё ведёт на прежний сервер | Зона DNS, TTL, кеш провайдера |
| A-запись правильная | IPv4-маршрут выглядит верно | Host, HTTPS, веб-сервер |
| Есть AAAA на нерабочий IPv6 | Часть клиентов может идти по IPv6 | Исправить IPv6 или убрать ошибочную AAAA |
| Домен не резолвится вообще | Проблема DNS/делегации | NS, состояние зоны, DNSSEC |
Особенно неприятен вариант с неправильной AAAA-записью: с одного подключения сайт открывается, а с другого — нет. Это может выглядеть как случайная проблема, хотя на деле разные клиенты выбирают IPv4 и IPv6.
Шаг 2
Проверьте NS: домен может смотреть не в ту DNS-зону
Даже правильная A-запись бесполезна, если вы редактируете не ту зону. Частая ситуация после переезда: записи меняют в панели хостинга, а у регистратора домен делегирован на другие NS. В интерфейсе всё выглядит «правильно», но публичный DNS этих изменений не видит.
Сверяем NS у регистратора с авторитетными NS домена. Затем проверяем, что именно на этих серверах создана актуальная зона и в ней есть нужные A/AAAA-записи.
Практический признак: в панели DNS вы видите новый IP, а внешняя проверка упорно показывает старый. Сначала выясняем, кто сейчас авторитетен для домена.
После смены NS изменения могут распространяться не мгновенно. Но если прошло достаточно времени, а разные резолверы стабильно видят старые серверы имён, причина уже не в «магическом кеше», а в самой делегации или настройке зоны.
Шаг 3
Если DNS правильный, проверяем virtual host веб-сервера
На одном IP могут работать десятки сайтов. Nginx или Apache выбирает нужную конфигурацию по имени домена из заголовка Host. Поэтому запрос к IP и запрос к домену — технически не одно и то же.
Если по IP открывается заглушка, другой сайт или страница панели, это вообще не подтверждает работу нужного проекта. В конфигурации должны быть указаны рабочие имена домена, а запрос должен попадать в правильный document root и upstream.
Открывается чужой сайт
Скорее всего срабатывает default virtual host или домен не добавлен в нужную конфигурацию.
По IP 200, по домену 404
Запрос уже дошёл до сервера, но маршрутизация для этого Host отличается.
По домену 502
DNS и virtual host уже работают, дальше ищем проблему upstream/PHP/backend.
HTTP работает, HTTPS нет
Переходим к отдельной конфигурации 443 и сертификату.
Шаг 4
HTTP может работать, а HTTPS — ломаться отдельно
Порт 80 и порт 443 обычно обслуживаются разными server-блоками. Поэтому сайт может нормально отвечать по http://example.ru, но не открываться по https://example.ru.
Проверяем, слушает ли сервер 443, есть ли домен в HTTPS-конфигурации, подходит ли сертификат по имени и не истёк ли он. Если сертификат выпущен только для www.example.ru, а пользователь открывает example.ru, браузер покажет ошибку имени.
Отдельно проверяем редиректы. Ошибка вроде http → https → www → http способна создать цикл, хотя каждый кусок конфигурации по отдельности выглядит логичным.
Шаг 5
Если проблема только у вас — проверьте локальный и провайдерский DNS-кеш
После смены IP часть резолверов может ещё использовать старое значение до истечения TTL. Поэтому один компьютер уже открывает новый сервер, а другой — продолжает ходить на старый.
Сравниваем ответ нескольких независимых DNS-резолверов и локального компьютера. Если публичные проверки уже показывают новый IP, а ваш компьютер — старый, очищаем локальный кеш и проверяем, не прописан ли домен вручную в файле hosts.
Проверяем DNS-кеш ОС, браузер и ручные записи hosts.
Сравниваем с публичными DNS и другим подключением.
Возвращаемся к A/AAAA, NS, Host и HTTPS.
Практика
Команды, которые быстро разделяют DNS и серверную проблему
Ниже — безопасные диагностические команды. Подставьте свой домен и реальный IP сервера.
nslookup example.ruСмотрим, какой IP получает ваш компьютер.
Resolve-DnsName example.ruУдобно видеть A, AAAA и другие типы записей.
curl -I -H "Host: example.ru" http://203.0.113.10/Показывает, как веб-сервер отвечает именно для этого домена.
curl -I --resolve example.ru:443:203.0.113.10 https://example.ru/Проверяет HTTPS на конкретном сервере, сохраняя имя домена для TLS и Host.
Команда
ping может показать, резолвится ли имя, но отсутствие ответа ICMP не означает, что сайт недоступен: многие серверы и firewall просто не отвечают на ping.Типовые сценарии
Что означает результат проверки
Один и тот же симптом «по IP открывается, по домену нет» может иметь разные причины. Ниже — самые частые развилки.
| Результат | Вероятная причина | Следующий шаг |
|---|---|---|
| DNS возвращает старый IP | Не обновлена зона или ещё жив кеш | Проверить NS, TTL и авторитетный DNS |
| DNS правильный, по Host открывается чужой сайт | Не настроен virtual host | Проверить server_name / ServerName и document root |
| HTTP по домену работает, HTTPS нет | Порт 443, SNI или сертификат | Проверить HTTPS-конфигурацию и SSL |
| С одного провайдера работает, с другого нет | Кеш, IPv6 или разная DNS-резолюция | Сравнить A/AAAA у разных резолверов |
| По домену 502/504 | Домен уже дошёл до сервера | Искать backend/upstream, а не DNS |
| По домену бесконечный редирект | Конфликт HTTP/HTTPS или www/non-www | Проверить всю цепочку редиректов |
DNSдомен → нужный IP
→
Host/TLSсервер выбирает нужный сайт
→
HTTPполучаем ожидаемый ответ
Чего не делать
Типичные действия, которые только запутывают диагностику
Сразу менять DNS
Если текущая A-запись уже правильная, лишние изменения только создадут новый период кеширования.
Считать ping окончательной проверкой
ICMP может быть запрещён, при этом HTTP и HTTPS работают нормально.
Перевыпускать SSL до проверки DNS
Сертификат не исправит домен, который ведёт на чужой сервер.
Править nginx «на глаз»
Сначала подтверждаем, что запрос дошёл до нужного IP и какой Host получает сервер.
Удалять AAAA без проверки
IPv6 может быть рабочим и использоваться частью клиентов; удаляем запись только если она действительно ведёт не туда.
Ждать «до 72 часов» при любой ошибке
TTL объясняет кеширование, но не исправляет неправильные NS, IP или конфигурацию веб-сервера.
Чек-лист
Сайт работает по IP, но не по домену
- Проверить A: домен возвращает реальный IPv4 сервера.
- Проверить AAAA: IPv6 либо настроен, либо ошибочная запись отсутствует.
- Сверить NS: редактируется именно авторитетная DNS-зона.
- Сравнить резолверы: понять, проблема глобальная или локальная.
- Проверить hosts: на компьютере нет старой ручной записи.
- Проверить Host: веб-сервер выбирает нужный virtual host.
- Проверить HTTP: домен получает ожидаемый код и содержимое.
- Проверить HTTPS: порт 443, SNI и сертификат настроены для домена.
- Проверить редиректы: нет цикла HTTP/HTTPS и www/non-www.
- Проверить backend: 502/504 после правильного DNS — уже серверная проблема.
- Очистить кеш локально: только если внешние проверки уже показывают новое значение.
- Повторить с другой сети: подтвердить, что исправление видно не только вам.
Когда нужна серверная диагностика
Если DNS уже правильный, дальше важнее не менять записи, а смотреть сервер
Когда A/AAAA и NS подтверждены, домен приходит на нужный IP, а ответ остаётся неправильным, проблема смещается в инфраструктуру: конфигурацию nginx/Apache, TLS, reverse proxy, firewall, PHP-FPM, контейнер или приложение.
Особенно полезно передавать специалисту уже собранные факты: домен, ожидаемый IP, результат DNS-проверки, HTTP-код, работает ли HTTP отдельно от HTTPS и что показывает запрос с заданным Host. Это сокращает диагностику намного сильнее, чем сообщение «домен не работает».
Вопросы
Короткие ответы
Почему сайт по IP открывается, а по домену — нет?
Потому что открытие по домену проходит дополнительные этапы: DNS должен вернуть нужный IP, веб-сервер должен узнать имя Host, а для HTTPS ещё требуется корректная TLS-конфигурация и сертификат.
Если A-запись правильная, DNS точно ни при чём?
Не всегда. Нужно проверить AAAA, NS, кеш и то, что вы смотрите именно публичную авторитетную зону, а не запись в другой панели.
Сколько ждать после изменения DNS?
Зависит от TTL старой записи и кешей резолверов. Вместо универсального ожидания лучше сравнить ответы нескольких DNS-серверов и увидеть, какое значение они реально возвращают сейчас.
Почему по HTTP сайт работает, а по HTTPS нет?
HTTPS использует отдельный порт и TLS-конфигурацию. Причиной может быть отсутствие server-блока на 443, неподходящий сертификат, ошибка SNI или цикл редиректов.
Поможет ли очистка DNS-кеша?
Только если локальный компьютер держит старое значение. Если публичный DNS сам возвращает неправильный IP, очистка локального кеша проблему не исправит.
Нужно ли менять DNS, если домен отдаёт 502?
Обычно нет. Код 502 означает, что запрос уже дошёл до веб-сервера или прокси; дальше нужно диагностировать upstream/backend.