Поменяли DNS, а открывается старый сайт: что проверить

Если после изменения DNS открывается старый сайт, сначала выясните, куда разрешается точное имя и что отдаёт полученный адрес. Ожидание обновления помогает только там, где действительно используется прежний DNS-ответ. Если запрос уже приходит на новую инфраструктуру, а она возвращает старую страницу или перенаправляет назад, менять запись ещё раз бессмысленно. Нужна последовательная проверка: имя, DNS-ответ, направление подключения и содержимое ответа сайта.

Ниже — порядок разбора для собственного домена и разрешённой инфраструктуры. Он не заменяет полный план переезда. Не удаляйте старую площадку и не отключайте почтовые записи ради проверки главной страницы. Сначала сохраните текущую конфигурацию и выясните, какие сервисы используют домен. Любое изменение должно иметь понятную цель и способ возврата. Сам факт отличия двух ответов ещё не определяет, какая сторона настроена неверно.

Запишите точный адрес и последнее подтверждённое изменение

Для диагностики полезна короткая карточка: какой домен открывали, было ли www, использовался ли поддомен, на какой адрес перешёл браузер и что именно осталось старым. Старая картинка, вся прежняя страница и прежняя ссылка после перенаправления — разные наблюдения. Добавьте время проверки и сеть. Не начинайте с фразы «у всех старое», если проверено одно устройство в одном месте.

Отдельно запишите, что меняли: запись адреса, значение псевдонима, серверы имён или настройки посредника. Панель регистратора и панель обслуживания DNS могут относиться к разным частям процесса. Скриншот нового значения не доказывает, что редактировалась используемая зона. Сопоставьте изменение с действующим обслуживанием домена. Если это неизвестно, сначала установите ответственного за DNS, а не создавайте ещё один похожий набор записей.

Зафиксируйте ожидаемую конфигурацию, не публикуя закрытые сведения. Какой вариант имени должен приводить на новую площадку? Должен ли адрес с www перенаправлять на основной? Используется ли промежуточный сервис? Ответы берут из плана проекта. Нельзя считать любой IP, отличающийся от адреса сервера, ошибкой: архитектура может включать посредника, и её нужно учитывать при сравнении.

Разделите запись у источника и ответ, который использует клиент

DNS-данные могут сохраняться в кэше. Поле TTL относится к допустимому времени кэширования записи; устройство этого поля описано в RFC 1035. Для практической работы с выбранным провайдером полезна его документация о TTL. Не воспринимайте новое значение TTL в панели как команду немедленно стереть все ранее сохранённые ответы у внешних участников.

Попросите специалиста сравнить ответ действующего авторитетного источника и ответы используемых рекурсивных серверов. Сохраните имя, тип записи, значение, время и источник каждого наблюдения. Эти сведения полезнее картинки с одним неизвестным IP. Если сравнивались разные типы или разные имена, расхождение ещё не объясняет проблему. Проверку нужно повторить для одинакового запроса и сопоставимых условий.

Изменение повторяют только после понимания результата. Если в действующей зоне всё ещё старое значение, ожидание чужого кэша не решит исходную ошибку. Если источник уже правильный, а конкретный клиент использует прежний ответ, работа продолжается с этой цепочкой. Здесь нет универсального обещания «всё исправится через столько-то часов»: порядок проверки не устанавливает срок для всей инфраструктуры и всех посетителей.

Проверьте разные имена и адресные пути

Основное имя, www и другие поддомены нужно проверять отдельно. В описании типов DNS-записей A связывается с IPv4, AAAA — с IPv6, а CNAME задаёт псевдоним имени. Наличие корректной записи одного типа не подтверждает корректность остальных. Составьте список реально используемых имён и путей, вместо того чтобы исправлять только ту строку, которая первой оказалась в панели.

Учебная ситуация: для основного имени уже изменён путь через IPv4, а отдельная настройка другого адресного пути осталась прежней. Это гипотеза для проверки, а не утверждение о вашем домене. Нельзя по ней автоматически удалять AAAA или отключать IPv6. Сначала выясните ожидаемую схему и подтвердите, каким путём прошёл конкретный запрос. Исправление должно сохранять поддерживаемую архитектуру, а не просто убирать неудобную строку.

Аналогично адрес с www может иметь собственную цепочку. Проверьте, где заканчивается разрешение имени и куда затем направляет веб-сервер. Если браузер после перехода показывает другое имя, дальше анализируется уже оно. Не объединяйте DNS-псевдоним и HTTP-перенаправление в одно действие: они относятся к разным этапам. Для передачи специалисту достаточно сохранить наблюдаемую последовательность без предположений о её причине.

Новый сервер тоже способен отдавать старую версию

Когда установлено, что запрос достигает ожидаемой инфраструктуры, проверьте выбранный сайт и опубликованную версию. На одной машине могут обслуживаться разные домены и каталоги. Доступ по голому IP не всегда соответствует доступу по нужному имени. Поэтому проверка «на новом адресе что-то открывается» недостаточна. Специалист должен сохранить корректное имя запроса и параметры защищённого подключения, не обходя проверку сертификата ради положительного результата.

Выберите безопасный отличительный признак версии: согласованный заголовок тестовой страницы, идентификатор сборки или другой уже предусмотренный проектом маркер. Не добавляйте посетителям случайный текст на главную только ради диагностики. Сопоставьте ответ с размещённой версией и настройками маршрута. Если служба запущена из старого выпуска, корректный DNS будет честно приводить посетителя к старому содержимому.

Временное правило перенаправления тоже может вернуть пользователя на прежнюю площадку. Запишите цепочку и место её формирования. Не создавайте встречное перенаправление на другом сервере: это может сделать маршрут ещё сложнее. Исправляйте подтверждённое правило по плану с возможностью возврата. После изменения проверьте не только главную, но и известный внутренний адрес, чтобы не скрыть проблему на остальных страницах.

Кэш страницы проверяйте после проверки маршрута

Если новая инфраструктура отдаёт правильный документ, а пользователь продолжает видеть старый, выясните, откуда пришёл показанный ресурс. Для этого полезен фактический запрос в инструментах браузера и наблюдения со стороны сайта. Кэш страницы и DNS-кэш — разные объекты проверки. Очистка одного не доказывает обновление другого. Другой браузер или сеть могут помочь сравнить поведение, но сами по себе не устанавливают причину.

При использовании промежуточного кэширования уточните, какое содержимое хранится и где требуется обновление. Не очищайте всё без разбора: массовая потеря кэша способна изменить нагрузку на приложение. Начните с подтверждённого проблемного ресурса и действующего порядка обновления проекта. Если осталась только старая картинка, проверьте её отдельный адрес и версию файла, не повторяя переключение всего домена.

Что считать завершением проверки

Повторите одинаковый набор наблюдений: нужные имена, используемые адресные пути, конечный URL и признак опубликованной версии. Отметьте условия каждой проверки. Успешный результат из одной сети подтверждает именно это наблюдение, а не мгновенное обновление всех клиентов. Если осталось известное расхождение, укажите его источник и следующее действие. Не прячьте неопределённость под общим статусом «переезд завершён».

Старую площадку выводят из работы по отдельному согласованному плану после проверки зависимостей и актуальных данных. Не используйте её отключение как способ заставить всех найти новую. Для проверки серверной настройки передайте исходные записи и результаты сравнения. В поддержке сайта дополнительно исследуют перенаправления, выпуск и содержимое. Такой пакет сведений помогает найти оставшееся старое значение, вместо повторных изменений DNS без понимания результата.