Сайт после смены хостинга: DNS и пропагация

Почему после смены хостинга сайт не открывается сразу

Вы перенесли сайт на новый хостинг, обновили IP-адрес в панели DNS, но сайт то открывается, то нет, а у части посетителей по-прежнему отображается старая версия или ошибка. Это классическая ситуация, которую обычно называют «DNS не обновился». На самом деле DNS — система распределённая, и обновление записи по всему миру не происходит мгновенно: процесс распространения изменений называется DNS-пропагацией.

Ключевое, что нужно понимать с самого начала: пропагация — это не единый момент «включилось», а постепенный процесс, который для разных пользователей и разных резолверов завершается в разное время. Кто-то увидит новый сервер уже через минуту, кто-то — через несколько часов, а иногда и через сутки.

В этой статье разберём, как устроен этот процесс, что такое TTL и кэш резолверов, как проверить, что видят пользователи в разных точках, и как сделать миграцию так, чтобы сайт оставался доступным на всех этапах.

Как устроено обновление DNS: иерархия и кэши

Чтобы понять, почему изменения доходят не сразу, нужно представить цепочку, по которой ваш компьютер узнаёт IP-адрес домена.

1. Вы вводите uptimechecker.ru в браузере.
2. Операционная система смотрит в локальный кэш — вдруг этот адрес уже резолвился.
3. Если нет — запрос уходит к резолверу (обычно роутер или DNS-сервер провайдера), у которого тоже есть свой кэш.
4. Резолвер при необходимости обращается к авторитативным DNS-серверам домена и получает актуальную запись.
5. Полученный ответ снова кэшируется на всех промежуточных узлах.

Важно: авторитативный сервер — единственное место, где хранится «истина». Все остальные участники цепочки хранят копии, и именно эти копии устаревают. Когда вы меняете A-запись на новом хостинге, вы меняете её только на авторитативном сервере; все кэши по всему миру ещё какое-то время помнят старый IP.

Что такое TTL и почему он управляет скоростью пропагации

TTL (Time To Live) — это срок жизни записи, который авторитативный сервер сообщает каждому, кто у него спрашивает. Он задаётся в секундах и говорит резолверу: «можешь помнить этот ответ N секунд, потом переспроси».

Например, TTL = 300 означает, что резолвер может держать ответ в кэше 5 минут. TTL = 86400 — сутки.

Разберём на примере. Допустим, у вашего домена A-запись с TTL = 3600 (один час). Вы меняете IP на новый:

• Резолвер, который спросил за минуту до изменения, будет помнить старый IP ещё целый час.
• Резолвер, который спросит через минуту после изменения, сразу получит новый IP.
• Локальный кэш вашего компьютера может держать старый адрес до истечения своего TTL.

Отсюда два практических вывода:

1. Чем меньше TTL, тем быстрее разойдутся изменения. Поэтому перед миграцией TTL снижают заранее.
2. Даже после смены записи старый IP будет жить в кэшах до истечения TTL — и пользователи, чей резолвер ещё не переспросил, продолжат попадать на старый сервер.

Как TTL влияет на разные типы записей

Обратите внимание на NS: смена DNS-серверов зоны распространяется медленнее всего, потому что кэшируется не только на резолверах, но и на уровне вышестоящих зон (родительской зоны .ru/.com). Если при миграции вы меняете не только A-запись, но и сами NS-серверы, закладывайте на это до 48 часов.

Кэш резолверов: почему «у всех уже работает, а у меня нет»

Главный источник путаницы при миграции — это разница между тем, что видите вы, и тем, что видят ваши пользователи. Каждый резолвер кэширует ответы независимо.

Типичная картина через пару часов после смены IP:

• Пользователь А (резолвер уже переспросил) — попадает на новый сервер.
• Пользователь Б (резолвер держит старый кэш) — всё ещё видит старый сервер.
• Вы сами (локальный кэш ОС не сброшен) — можете видеть что угодно, даже если всё уже обновилось.

Именно поэтому проверять «обновился ли DNS» только со своего компьютера — ненадёжно: вы видите один конкретный кэш, а не общую картину.

Отрицательное кэширование

Отдельный нюанс — кэширование отрицательных ответов. Если до миграции резолвер запрашивал поддомен, которого не было (получал NXDOMAIN), этот отрицательный ответ тоже кэшируется на срок, указанный в SOA-записи зоны. Из-за этого иногда кажется, что «запись добавили, а её всё равно нет». Подробнее про саму ошибку NXDOMAIN — в статье про DNS_PROBE_FINISHED_NXDOMAIN.

Самопроверка: как узнать, что видят резолверы

Проверять пропагацию нужно не «в целом», а по конкретным резолверам. Базовый инструмент — dig, который умеет спрашивать конкретный DNS-сервер.

Проверка на авторитативном сервере

Сначала убедимся, что новая запись вообще попала в зону. Для этого спросим напрямую авторитативный сервер домена. Сначала найдём его:

dig NS uptimechecker.ru +short

Вернётся список серверов зоны, например:

ns1.hosting.example.
ns2.hosting.example.

Теперь спросим A-запись у одного из них напрямую:

dig A example.com @ns1.hosting.example

Разберём ключевые строки ответа:

;; ANSWER SECTION:
example.com.            300     IN      A       203.0.113.20

• example.com. — запрошенное имя.
• 300 — TTL, который сервер сейчас раздаёт.
• IN A — тип записи.
• 203.0.113.20 — IP-адрес. Если здесь новый IP, значит, зона обновлена корректно, и осталось дождаться распространения по кэшам. Если здесь старый IP — вы меняли запись не в той зоне или не на том сервере.

Проверка на публичном резолвере

Теперь посмотрим, что отдаёт внешний резолвер, у которого есть собственный кэш:

dig A example.com @8.8.8.8

Если резолвер уже обновился, в ANSWER SECTION будет новый IP. Если нет — старый, а строка 300 покажет, сколько секунд ещё осталось жить этому кэшу (TTL уменьшается с каждым запросом).

Сравним несколько резолверов:

dig A example.com @8.8.8.8 +short
dig A example.com @1.1.1.1 +short
dig A example.com @77.88.8.8 +short

Каждая команда выведет один IP. Если они расходятся — пропагация ещё идёт: часть резолверов видит новый адрес, часть старый.

Проверка локального кэша вашего компьютера

Чтобы понять, что видит именно ваша машина, спросите системный резолвер без указания сервера:

dig A example.com +short

Если здесь старый IP, а на 8.8.8.8 уже новый — проблема в вашем локальном кэше или кэше резолвера провайдера, а не в самой зоне.

Сводка: что и где проверять

Внешний инструмент вроде проверки DNS-записей UptimeChecker полезен тем, что показывает картину «снаружи», независимо от кэша вашего компьютера и настроек провайдера.

Как провести миграцию без простоя: правильный порядок

Главная ошибка — менять IP и ждать, пока «разойдётся», ничего не контролируя. Правильный сценарий выглядит иначе.

1. Снизьте TTL заранее

За 24–48 часов до миграции уменьшите TTL у A-записи до минимального (например, 300 секунд или меньше). Тогда, когда настанет момент переключения, кэши будут «жить» всего несколько минут, а не сутки.

Важно: снижать TTL нужно заранее, потому что старый (большой) TTL уже разошёлся по кэшам, и его нужно просто «переждать». Если вы снизите TTL за сутки до переключения, все резолверы к моменту переключения уже будут хранить запись с коротким сроком жизни.

2. Подготовьте новый сервер до переключения

Полностью перенесите файлы и базу, настройте сайт на новом хостинге, проверьте его по временному адресу или по IP. Убедитесь, что сайт корректно отвечает до того, как переключите DNS. Иначе после смены записи часть посетителей попадёт на недонастроенный сервер.

3. Переключите запись

Обновите A-запись (или CNAME) на новый IP. С этого момента начинается пропагация. Закладывайте, что в течение времени, равного старому TTL, часть трафика всё ещё будет уходить на старый сервер.

4. Держите оба сервера доступными

Пока пропагация не завершилась, не выключайте старый сервер сразу. Посетители, чей резолвер ещё не обновился, попадают на старый сервер, и он должен отвечать. Частая практика — оставить старый сервер работающим ещё на 24–48 часов, а при необходимости настроить на нём редирект или заглушку «сайт переехал».

5. Контролируйте процесс

Периодически проверяйте резолверы через dig и проверку DNS, пока не убедитесь, что все видят новый IP. Только после этого отключайте старое окружение.

Частые ошибки при миграции

Почему «DNS не обновился» — это почти всегда кэш, а не поломка

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

Поэтому прежде чем паниковать и «чинить DNS», выполните три действия:

1. Проверьте запись на авторитативном сервере (dig A example.com @ns1.hosting.example) — новая ли она.
2. Сбросьте локальный кэш и проверьте через публичные резолверы.
3. Если публичные резолверы видят новый IP, а вы — нет, проблема локальная, и она уйдёт сама после сброса кэша или истечения TTL.

Как сбросить локальный кэш

На macOS:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

На Windows (от администратора):

ipconfig /flushdns

На Linux (systemd-resolved):

sudo systemd-resolve --flush-caches

После сброса также стоит проверить сайт в режиме инкогнито — браузер хранит собственный кэш DNS отдельно от системы.

Когда пропагация затянулась: что проверить

Если прошло заметно больше времени, чем старый TTL, а часть резолверов всё ещё отдаёт старый IP, проверьте следующее.

1. Точно ли вы сменили запись в нужной зоне. Проверьте через dig @ns — какой IP отдаёт авторитативный сервер.
2. Не сменили ли вы заодно NS. Смена NS-серверов кэшируется до 48 часов на уровне родительской зоны — это отдельная, более медленная операция.
3. Нет ли на старом сервере своего DNS. Иногда трафик уходит на старый хостинг, который продолжает отдавать свои ответы.
4. Не закеширован ли ответ на уровне провайдера дольше TTL. Некоторые резолверы нарушают TTL и держат кэш дольше; поможет смена резолвера на публичный для проверки.

Сверить актуальное состояние записей и состояние домена удобно через проверку DNS-записей и проверку домена — они показывают картину внешнего наблюдателя без привязки к вашему кэшу.

Коротко: чек-лист смены хостинга

1. За 24–48 часов снизьте TTL у A-записи до 300 секунд.
2. Перенесите и проверьте сайт на новом сервере по временному адресу.
3. Обновите A-запись на новый IP.
4. Оставьте старый сервер работать ещё 24–48 часов.
5. Контролируйте пропагацию через dig к разным резолверам.
6. Сбрасывайте локальный кэш, когда проверяете со своего компьютера.
7. Отключайте старое окружение только после того, как все резолверы видят новый IP.

Пропагация — процесс предсказуемый, если понимать TTL и кэши. UptimeChecker помогает держать процесс под контролем: проверка DNS-записей покажет, какой IP видит внешний наблюдатель в текущий момент, а проверка доступности — что сайт корректно отвечает на новом сервере, пока идёт распространение изменений.