После смены хостинга, подключения CDN, выпуска SSL-сертификата или изменения почтовых записей владелец ожидает, что сайт сразу начнет работать одинаково для всех. На практике бывает иначе: у вас открывается новая версия, у клиента все еще виден старый сервер, а у части пользователей браузер показывает ошибку сертификата или не находит домен.
Такая ситуация не всегда означает, что хостинг упал. Часто проблема находится в DNS: записи обновились в панели управления, но не дошли до всех резолверов, закэшировались у провайдера или конфликтуют с другими настройками. Ниже — практический порядок проверки без лишней теории.
Что значит «DNS-записи не обновляются»
DNS превращает доменное имя в технические данные: IP-адрес сервера, CNAME для CDN, MX для почты, TXT для подтверждений, CAA для выпуска сертификатов. Когда вы меняете запись, вы меняете не сам сайт, а маршрут, по которому пользователи и сервисы находят нужный ресурс.
Проблема начинается, когда разные участники цепочки видят разные ответы. Один DNS-резолвер уже получил новый IP, другой все еще держит старый ответ. Браузер мог сохранить результат локально. Корпоративная сеть могла использовать собственный DNS. А сервис выпуска SSL-сертификата может проверять домен через свои резолверы и видеть не то, что видите вы.
Типичные признаки
Чаще всего владелец сталкивается с такими симптомами:
- сайт открывается у администратора, но не открывается у клиентов;
- после переноса часть пользователей видит старую версию сайта;
- домен ведет на новый сервер, но `www` или поддомен остался на старом;
- SSL-сертификат не выпускается, хотя запись уже добавлена;
- браузер показывает сертификат не от того сайта;
- почта с домена работает нестабильно после изменения MX, SPF или DKIM;
- CDN включен, но новая DNS-запись дает ошибку `502` или ведет не туда.
Во всех этих случаях важно не ограничиваться проверкой «у меня открывается». Нужно посмотреть, что происходит снаружи и на разных этапах маршрута.
Почему изменения доходят не сразу
У каждой DNS-записи есть TTL. Это значение подсказывает, как долго резолвер может хранить старый ответ в кэше. Если до изменения записи TTL был высоким, часть сетей может продолжать использовать прежние данные, пока кэш не обновится.
Но TTL — не единственная причина. Иногда запись изменена не в той DNS-зоне. Например, домен делегирован на одни NS-серверы, а правки сделаны в панели другого провайдера. В интерфейсе все выглядит правильно, но публичный интернет спрашивает не эту зону.
Еще один частый случай — конфликт записей. Для одного имени нельзя одновременно ожидать поведение обычной A-записи и CNAME, если настройки несовместимы. При подключении CDN владелец может изменить запись для `example.ru`, но забыть про `www.example.ru`. При выпуске SSL может мешать CAA-запись, старый CNAME или отсутствие нужной TXT-записи для проверки домена.
Пример после переноса сайта
Интернет-магазин переезжает на новый хостинг. Владелец меняет A-запись основного домена, проверяет сайт со своего компьютера и видит новую версию. Через час клиент пишет, что попадает на старый сайт и оформляет заказ в старой корзине.
Что могло произойти:
- у клиента или его провайдера еще закэширован старый IP;
- запись `www` не изменили, а клиент заходит именно через нее;
- редирект с `www` на основной домен настроен на старом сервере;
- SSL-сертификат выпущен только для одного варианта домена;
- CDN или прокси продолжает использовать старый origin.
Правильный вывод: нужно проверять не только главную страницу, но и оба варианта домена, HTTPS, редиректы и фактический IP, на который приходит запрос.
Как проверить DNS вручную
Начните с базовой схемы: кто обслуживает DNS, какие записи отдает публичный интернет и какой сервер отвечает по HTTPS.
Проверьте NS-серверы
Сначала убедитесь, что домен делегирован туда, где вы вносите изменения. Если NS-серверы указывают на одного провайдера, а запись вы правите у другого, изменение не повлияет на сайт.
Проверьте NS через любой DNS-инструмент или команду `dig NS example.ru`. Сравните результат с панелью регистратора. Если вы недавно меняли NS, учитывайте, что старые и новые серверы могут некоторое время встречаться параллельно у разных резолверов.
Сравните ответы разных резолверов
Проверьте A, AAAA и CNAME-записи через несколько публичных DNS-резолверов. Важно смотреть не только факт ответа, но и конкретное значение: IP, имя CNAME, наличие IPv6, TTL.
Если один резолвер показывает новый IP, а другой — старый, сайт может открываться не у всех. Если IPv4 ведет на новый сервер, а IPv6 остался старым или сломанным, часть пользователей тоже получит ошибку. Если CNAME указывает на CDN, проверьте, что CDN знает этот домен и правильно направляет запрос к origin-серверу.
Проверьте HTTPS отдельно
DNS может быть уже правильным, но HTTPS все равно не работает. Откройте сайт по `https://`, проверьте сертификат для основного домена и `www`, посмотрите срок действия и цепочку сертификата. Для быстрой проверки можно использовать страницу проверки SSL.
Если сертификат еще не выпущен, причина может быть в DNS-проверке домена. Сервис сертификации должен увидеть нужную запись или правильный маршрут. Когда разные резолверы получают разные ответы, выпуск сертификата может задержаться или завершиться ошибкой.
Как понять, что проблема влияет на клиентов
Главный риск DNS-проблемы — частичная недоступность. Владелец видит рабочий сайт и не понимает, что часть пользователей уже теряет доступ. Поэтому полезно проверять сайт так, как его видит внешний посетитель.
Проверьте:
- открывается ли главная страница по HTTP и HTTPS;
- работает ли вариант с `www` и без `www`;
- не возникает ли лишняя цепочка редиректов;
- какой HTTP-статус возвращает сервер;
- не отличается ли ответ для важных страниц: корзины, формы заявки, личного кабинета;
- совпадает ли сертификат с текущим доменом;
- не отвечает ли старый сервер вместо нового.
Для быстрой внешней проверки можно использовать проверку доступности сайта. Она помогает отделить локальную проблему браузера от ситуации, когда сайт действительно недоступен извне.
Пример с SSL после изменения DNS
Компания подключает новый домен к сайту и добавляет CNAME на платформу. В панели все сохранено, но сертификат не выпускается. Владелец несколько раз нажимает «повторить выпуск», хотя причина не в кнопке.
Что стоит проверить: делегирован ли домен на правильные NS, видят ли публичные резолверы новый CNAME, нет ли CAA-записи, запрещающей выпуск у выбранного центра сертификации, не включен ли прокси-режим там, где проверка ожидает прямой DNS-ответ. Если после проверки остается неясность, лучше собрать факты и обратиться к специалисту, а не менять записи наугад.
Почему автоматический мониторинг лучше ручной проверки
Ручная проверка нужна при настройке и расследовании. Но она не заменяет мониторинг: владелец не будет постоянно открывать сайт с разных сетей, проверять SSL и замечать, что ошибка появилась ночью или после очередного изменения DNS.
Автоматический мониторинг помогает заметить проблему раньше клиента. Web-Puls регулярно проверяет доступность сайта и помогает быстрее понять, что сайт перестал открываться или начал отвечать ошибкой. Это особенно полезно после переноса на новый хостинг, подключения CDN, изменения DNS-записей или выпуска нового SSL-сертификата.
Хорошая практика — добавить проверку сразу после изменений и оставить ее включенной. Тогда вы увидите не только разовый результат, но и историю: когда началась проблема, сколько она длилась, какие ответы возвращал сайт.
Что делать, если DNS уже сломан
Не меняйте все записи подряд. Так легко сделать диагностику сложнее. Действуйте по шагам.
- Зафиксируйте симптомы: какая ошибка, у кого, на каком домене и в какое время.
- Проверьте NS-серверы и убедитесь, что правите активную DNS-зону.
- Сравните A, AAAA, CNAME, CAA и TXT-записи у разных резолверов.
- Проверьте `www` и основной домен отдельно.
- Убедитесь, что SSL-сертификат покрывает нужные имена.
- Проверьте, куда фактически приходит запрос: на новый сервер, CDN или старый origin.
- После исправления включите мониторинг и наблюдайте, стабилизировался ли ответ.
Если проблему нужно не только заметить, но и разобрать технически, можно отправить заявку на профессиональную поддержку через форму Web-Puls: оставить заявку. Для сложных случаев с DNS, SSL, хостингом или сервером также можно использовать контактную информацию.
Вывод
DNS-проблемы коварны тем, что редко выглядят одинаково для всех. Один пользователь видит новый сайт, другой — старый сервер, третий — ошибку SSL. Поэтому после любых изменений в DNS важно проверять делегирование, разные варианты домена, HTTPS, редиректы и ответ сайта извне.
Ручная диагностика помогает найти причину, а автоматический мониторинг помогает не пропустить момент, когда сайт снова станет недоступен. Если сайт важен для заявок, продаж или личного кабинета, проверку доступности лучше включать до того, как первые жалобы придут от клиентов.