Домен настроен, а сайт не открывается: разбираемся с DNS
Как отличить DNS-кеш от проблем сервера: A и AAAA, TTL, dig, curl --resolve и проверка HTTPS.
Контейнер запущен, деплой зелёный, A-запись изменена — а на ноутбуке сайт не открывается. В такой ситуации полезнее сначала сравнить маршруты запроса, чем сразу перезапускать приложение.
В этой статье все адреса демонстрационные: example.com — домен, 203.0.113.10 — новый сервер, 198.51.100.20 — старый. Вывод команд смоделирован и не содержит данных реальной инфраструктуры.
Где может остаться старый адрес
Браузер → кеш ОС → роутер / VPN / DNS провайдера → авторитетный DNSЭто упрощённая схема. Браузер может использовать собственный DNS over HTTPS, а VPN — отдельные резолверы. Поэтому успешный dig ещё не доказывает, что браузер получает тот же ответ.
Начнём с двух одинаковых HTTPS-запросов. Единственное различие будет в выборе IP.
1. Сравниваем обычный запрос и правильный IP
curl --head --location --max-time 15 https://example.com
curl --head --location --max-time 15 --resolve example.com:443:203.0.113.10 https://example.com--resolve подставляет IP для конкретной пары домен/порт в рамках этого запуска curl. Имя сайта в URL сохраняется, поэтому TLS проверяется для example.com. Это удобнее, чем открывать https://203.0.113.10 и получать ошибку несовпадения сертификата. Механизм описан в руководстве curl.
Результаты помогают сузить поиск:
| Обычный запрос | Запрос с --resolve |
Что проверять дальше |
|---|---|---|
| Таймаут или ошибка DNS | Ожидаемый сайт | DNS-ответы и кеши |
| Ошибка сертификата | Корректный HTTPS | Не ведёт ли обычный DNS на другой узел |
| Ошибка в обоих | Та же ошибка | Сервер, порты, прокси, сертификат |
| Работают оба | Работают оба | Браузер, его DNS, прокси или расширения |
Если используется CDN, его IP может намеренно отличаться от адреса origin-сервера. Тогда отдельно проверяйте маршрут через CDN: обход через --resolve не доказывает, что исправен сам CDN.
2. Смотрим DNS-ответ и TTL
dig example.com A +noall +answer
dig example.com AAAA +noall +answerУсловный устаревший ответ:
example.com. 840 IN A 198.51.100.20840 — оставшийся TTL в этом ответе, в секундах. В данном примере кеш может хранить запись ещё около 14 минут. TTL ограничивает время хранения DNS-записи; базовое описание есть в RFC 1035.
Новый TTL, заданный у провайдера, не сокращает задним числом срок уже закешированного старого ответа. Поэтому изменение записи не обязано немедленно стать видимым всем устройствам.
Для будущего переезда уменьшайте TTL заранее и дожидайтесь истечения прежнего значения, прежде чем переключать IP.
3. Сравниваем резолверы
Спросим публичные DNS напрямую:
dig @1.1.1.1 example.com A +noall +answer
dig @8.8.8.8 example.com A +noall +answerЗатем найдём авторитетные серверы:
dig example.com NS +shortПодставьте одно из полученных имён вместо условного ns1.example.net:
dig @ns1.example.net example.com A +noall +answerЕсли авторитетный сервер уже отвечает новым IP, а используемый резолвер — старым, проверьте TTL его ответа. Если старое значение остаётся и на авторитетном сервере, возможно, изменена не та DNS-зона или домен делегирован другому провайдеру.
В панели регистратора проверьте текущие NS. Запись, добавленная в неиспользуемую DNS-панель, не изменит реальный ответ домена.
4. Учитываем кеш ОС и браузера
На macOS ответ системного резолвера можно посмотреть так:
dscacheutil -q host -a name example.comНа Linux полезна проверка через системный механизм разрешения имён:
getent ahostsv4 example.comСравните результат с dig. Проверьте также файл hosts, настройки защищённого DNS в браузере и DNS, назначенные VPN. Не публикуйте содержимое всей сетевой конфигурации: там могут быть внутренние домены и адреса.
Очистка DNS-кеша компьютера не очищает кеш роутера. Очистка кеша страниц браузера тоже не заставит DNS провайдера немедленно забыть старый IP.
Чтобы быстро сравнить сети, можно проверить сайт через мобильный интернет. Это меняет сразу несколько условий, поэтому такой результат — подсказка, а не окончательное доказательство конкретной причины.
5. Не забываем про IPv6
Правильная A-запись не исключает ошибочную AAAA. Сравните запросы:
curl -4 --head --max-time 15 https://example.com
curl -6 --head --max-time 15 https://example.comЕсли IPv4 работает, а IPv6 — нет, проверьте AAAA и реальную доступность сервера по IPv6. Сам по себе сбой curl -6 не доказывает ошибку домена: в текущей сети может вообще не быть IPv6-маршрута.
Оставляйте AAAA только для работающего IPv6-адреса. Если IPv6 не настроен, удалите устаревшую запись вместо отключения IPv6 на всех устройствах.
Если curl работает, а браузер нет
Откройте полный адрес с https:// и проверьте, не попали ли вы на www, для которого не настроены DNS и сертификат. Посмотрите текст ошибки браузера: ошибка разрешения имени, таймаут и ошибка сертификата требуют разных проверок.
Попробуйте другое окно или браузер и сравните настройки DNS/proxy. При использовании VPN запишите, меняется ли результат с ним и без него. Настройки меняйте по одной, чтобы понимать, что именно повлияло на результат.
Что прислать для диагностики
Обычно достаточно текста ошибки, времени проверки и результатов двух запросов curl и одного запроса dig. Перед публикацией замените реальные домены, адреса клиентов и любые заголовки авторизации:
domain: example.com
expected_ip: 203.0.113.10
client_ip: ********
Authorization: Bearer ********Не отправляйте полный HAR без проверки: в нём могут оказаться cookies, токены, параметры запросов и содержимое ответов.
Если авторитетный DNS уже правильный, запрос с --resolve работает, а локальный резолвер отдаёт старый адрес с уменьшающимся TTL, перезапуск приложения не поможет. Нужно дождаться истечения кеша или обновить именно тот резолвер, который возвращает устаревший ответ.