DNS-кеш у пользователей: почему сайт показывает старый IP

Старый IP не всегда живёт в зоне

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

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

TTL задаёт ожидание, но не гарантирует синхронность

TTL показывает, сколько времени ответ можно хранить в кэше. Если у записи TTL был 3600 секунд, часть резолверов может держать старый IP около часа. Если до переноса стоял высокий TTL, окно расхождения будет длиннее. Поэтому TTL снижают заранее, а не в момент аварии.

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

Где именно может застрять старый ответ

Старый IP может жить в нескольких местах:

публичный DNS-резолвер ещё не обновил ответ;
роутер пользователя кэширует DNS;
операционная система держит локальный кэш;
браузер использует собственный DNS или DoH;
корпоративная сеть проксирует DNS через внутренний сервер;
CDN или reverse proxy отдаёт старый контент уже после правильного DNS.

Последний вариант особенно неприятен: DNS уже показывает новый IP, но пользователь видит старую страницу из кэша приложения или CDN. Тогда проблема выше DNS. Проверка должна идти не только по имени, но и по HTTP-ответу, сертификату и заголовкам.

Проверка старого IP

Практический порядок:

1. проверить A/AAAA у авторитетного NS;

2. сравнить 1.1.1.1, 8.8.8.8 и резолвер пользователя;

3. посмотреть TTL ответа;

4. очистить локальный DNS-кэш или проверить с другого устройства;

5. запросить страницу с заголовками и убедиться, что контент идёт с нужного сервера.

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

Кейс: клиент видел старый кабинет

После миграции личного кабинета часть пользователей продолжала попадать на старый сервер. Авторитетный DNS уже отдавал новый IP, но корпоративный резолвер одного клиента держал старое значение. Команда не стала менять A-запись снова: она попросила клиента проверить домен через мобильную сеть и публичный резолвер. Там кабинет открывался правильно.

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

Что фиксировать при жалобе

домен и поддомен;
старый и новый IP;
время DNS-правки;
TTL до изменения и после;
сеть пользователя;
резолвер, который вернул старый ответ;
HTTP-код и сертификат, если IP уже новый.

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

При выборочных жалобах лучше не просить пользователя «просто обновить страницу» десять раз. Нужны конкретные данные: какой домен он открыл, какой IP получил, какая сеть использовалась, в какое время появилась ошибка и повторяется ли она в мобильной сети. Если есть возможность, полезно сравнить обычный браузер и команду `nslookup` или `dig` на той же машине. Такой набор не требует от пользователя глубокого знания DNS, но позволяет отличить локальный кэш от неправильной записи. Если старый ответ видит только одна корпоративная сеть, правка в публичной зоне уже не ускорит обновление внутри этой сети.

Связь с DNS-сервером и авторитетным ответом здесь прямая: пока не ясно, кто отдаёт старый IP, нельзя понять, ждать TTL или искать ошибку в зоне.

Как отличить кешированный адрес от другой неисправности

Сначала сравните одинаковое имя

Домен для VPN, поддомены VPN и домен для VPN сервера могут иметь независимые записи и TTL. Сайт VPN сервиса не обязательно использует тот же адрес, что клиент. Адрес VPN сервера сверяйте по точному имени и семейству адресов, иначе старый и новый результаты могут относиться к разным компонентам.

Проверьте, кто отвечает устройству

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

Клиентский профиль и сертификат

Профиль VPN может содержать прямой IP, и тогда изменение DNS не обновит его автоматически. VPN подписка должна выдавать актуальную конфигурацию. Сертификат VPN сервера должен соответствовать используемому имени. Ошибка сертификата VPN после переезда требует отдельного разбора, даже если старый адрес уже исчез из кеша.

Контроль после изменения

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

FAQ о DNS-кэше

Почему у меня сайт новый, а у клиента старый?

Вы можете использовать разные резолверы, сети и локальные кэши. Проверять нужно не только свой браузер, а внешний ответ.

Можно ли ускорить обновление DNS у всех пользователей?

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

Когда проблема уже не в DNS-кэше?

Если DNS отдаёт новый IP, но контент старый, смотрят CDN, приложение, кэш сервера, редиректы и backend.

Нужно ли очищать кэш браузера при DNS-проблеме?

Иногда да, но сначала лучше понять, какой именно уровень держит старый ответ: DNS, браузер, роутер или CDN.

Нужно ли очищать DNS для VPN после смены IP сервера?

Сначала выясните, где сохранён старый адрес: в резолвере, приложении или самом профиле. Если профиль содержит IP напрямую, очистка DNS не поможет. Если он содержит имя, иногда достаточно дождаться TTL и переподключить клиент; массово сбрасывать настройки всех устройств без проверки причины не стоит.

Почему после обновления кеша VPN соединение остаётся на старом узле?

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

Нужно ли переустанавливать VPN, если DNS показывает старый IP?

Обычно сначала проверяют кеши и действующую зону. Сверьте DNS для VPN и ответ от авторитетного сервера. Если VPN сайт открывается по-разному, сравните имя, IPv4 и IPv6, а также резолвер браузера. Переустановка клиента не обновляет записи у оператора DNS и может стереть полезный журнал.

Источники

---