После миграции сайт открывается со старого сервера: разбор DNS

MAATRIX

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

Первая реакция: «миграция не сработала»

Типичная картина: вы выключили старый сервер приложением по чек-листу, подняли новый, скопировали файлы или базу, поменяли A-запись у домена — и открываете сайт в браузере. Видите старую версию. Открываете в режиме инкогнито — та же старая версия. Начинаете перепроверять конфиг nginx, права на файлы, содержимое базы на новом сервере — и не находите там ничего плохого, потому что там всё в порядке.

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

Отдельный частый вариант этой же паники: сайт грузится по-разному в зависимости от устройства. С телефона в мобильной сети — новая версия, с рабочего ноутбука через провайдерский Wi-Fi — старая. Это тоже DNS-кеш, только на стороне разных резолверов, и объясняется в следующем разделе.

Реальная причина: кеш DNS на разных уровнях

DNS устроен как цепочка кешей, и каждый уровень в этой цепочке хранит запись столько времени, сколько ему разрешили — то самое значение TTL (Time To Live), указанное в секундах у самой записи. Пока TTL не истёк, кеш имеет полное право отдавать старый ответ, даже не обращаясь к авторитативному серверу заново. Уровни кеширования, с которыми вы столкнётесь:

• Резолвер интернет-провайдера пользователя. Большинство людей используют DNS-сервер своего провайдера (или роутера, который проксирует его). Этот резолвер запросил A-запись вашего домена когда-то раньше, получил старый IP и TTL, и будет отдавать этот ответ всем клиентам провайдера, пока TTL не истечёт — независимо от того, что вы поменяли запись пять минут назад.
• Кеш операционной системы. Windows, macOS и Linux кешируют DNS-ответы локально (в Windows это видно через ipconfig /displaydns, в macOS кеш обслуживается mDNSResponder). Это отдельный кеш поверх резолвера — именно поэтому админ, только что менявший запись, тоже может видеть старую версию у себя на машине.
• Кеш браузера. Chrome, Firefox и другие браузеры держат собственный DNS-кеш независимо от ОС (в Chrome он смотрится по адресу chrome://net-internals/#dns). Он живёт своей жизнью и не всегда синхронизирован с системным.
• Публичные DNS-резолверы (Google 8.8.8.8, Cloudflare 1.1.1.1) — тоже кешируют по TTL, но у них кеш обычно короче держится «залипшим», потому что они массово обслуживают весь мир и быстрее актуализируют популярные записи.
• Кеширующие резолверы у корпоративных сетей, VPN-провайдеров, мобильных операторов — отдельная непредсказуемая прослойка, из-за которой одни посетители видят новый сайт, а другие старый в один и тот же момент времени.

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

TTL старой записи и почему обновление растягивается по времени

TTL — это число секунд, которое вы (или предыдущий администратор) указали у A-записи домена. Типичные значения: 300 (5 минут), 3600 (час), 14400 (4 часа), 86400 (24 часа). Если у вашей старой записи TTL стоял, скажем, 86400 секунд (24 часа), это означает буквально следующее: любой резолвер, который успел закешировать старый IP хотя бы за секунду до вашей правки, имеет право отдавать этот старый IP ещё до суток — и будет прав с точки зрения протокола.

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

Проверить текущий TTL записи можно так:

dig maatrix.io A

В ответе будет строка вида:

maatrix.io.        3600    IN    A    198.51.100.10

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

dig @ns1.your-dns-provider.com maatrix.io A

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

Как проверить реальное состояние DNS независимо от своего кеша

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

1. Запрос к публичному резолверу напрямую, в обход системного DNS:

dig @8.8.8.8 maatrix.io A +short
dig @1.1.1.1 maatrix.io A +short

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

2. Запрос напрямую к авторитативному NS-серверу домена, чтобы исключить вообще любое кеширование:

dig +trace maatrix.io A

Команда +trace пройдёт всю цепочку от корневых серверов до NS вашего домена и покажет, что реально отдаёт авторитативный сервер прямо сейчас — это самый надёжный источник истины.

3. nslookup с явным резолвером, если вы привыкли к nslookup, а не dig:

nslookup maatrix.io 8.8.8.8

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

• whatsmydns.net
• dnschecker.org

Это удобно, когда нужно объяснить клиенту или коллеге «нет, у нас всё настроено верно, вот скриншот с 20 точками мира, 18 из них уже видят новый сервер» — снимает панику лучше любых слов.

5. Проверка своего же локального кеша, если хочется понять, почему именно у вас в браузере старая версия:

# macOS — посмотреть, что резолвер отдаёт прямо сейчас без явного DNS
scutil --dns | grep nameserver

# Windows — посмотреть закешированные записи
ipconfig /displaydns

# Windows — сбросить кеш ОС
ipconfig /flushdns

# Linux с systemd-resolved
resolvectl flush-caches

Если после dig @8.8.8.8 вы видите новый IP, а обычный dig maatrix.io (без указания резолвера) — старый, значит проблема именно в вашем локальном/провайдерском кеше, и это ожидаемо: подождите TTL или сбросьте кеш вручную.

Что стоило сделать заранее: снизить TTL до миграции

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

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

Пошагово:

За 24-48 часов до переезда:
  1. Зайти в панель DNS-провайдера/регистратора.
  2. У A-записи домена снизить TTL с 86400 (или что там стоит) до 300.
  3. Сохранить, IP пока НЕ трогать.
  4. Подождать не меньше, чем был старый TTL (в примере — сутки).

В день миграции:
  5. Проверить dig @8.8.8.8 domain A +short — убедиться, что TTL в ответе уже маленький (300, а не старое значение).
  6. Только теперь менять A-запись на IP нового сервера.
  7. Через 5-15 минут большинство резолверов уже подхватят новый IP.

После стабилизации (через несколько дней после переезда):
  8. Можно вернуть TTL к более длинному значению (3600-86400) — короткий TTL постоянно держать не обязательно, он немного увеличивает нагрузку на авторитативные DNS-серверы и число запросов от резолверов.

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

Временное решение: обращение к новому серверу в обход DNS

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

Способ 1 — curl с явным Host-заголовком, без изменения чего-либо на компьютере:

curl -H "Host: maatrix.io" http://198.51.100.10/

Для HTTPS сложнее — нужно ещё и правильный SNI, чтобы сервер выдал верный TLS-сертификат для домена, а не дефолтный:

curl --resolve maatrix.io:443:198.51.100.10 https://maatrix.io/

Флаг --resolve — самый чистый способ: curl делает вид, что DNS для maatrix.io уже указывает на 198.51.100.10, но при этом отправляет корректные заголовки Host и SNI, так что и веб-сервер, и TLS отработают как в проде.

Способ 2 — правка файла hosts на своей машине, если нужно не разово проверить curl'ом, а полноценно полистать сайт в браузере как будущий пользователь нового сервера:

# Linux/macOS: /etc/hosts
# Windows: C:\Windows\System32\drivers\etc\hosts

198.51.100.10   maatrix.io
198.51.100.10   www.maatrix.io

После сохранения файла на Linux/macOS сброс кеша не обязателен, но если браузер продолжает упрямиться — киньте sudo dscacheutil -flushcache (macOS) или откройте страницу в приватном окне, где браузерный DNS-кеш минимален. Для HTTPS этот способ работает без проблем с сертификатом, потому что браузер обращается по имени maatrix.io, просто резолвит его локально в новый IP, — SNI и Host будут правильными автоматически.

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

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

Частые вопросы