После смены IP часть пользователей видит старый сайт: TTL и DNS-кэш

Почему после смены IP один пользователь видит новый сайт, а другой — старый

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

Типичная ситуация после переноса выглядит так: администратор открывает сайт и видит новый VPS, а пользователь присылает скрин старой версии. Переносить файлы заново или перезапускать Nginx в этот момент рано. Сначала нужно понять, где именно остался старый адрес.

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

Что TTL реально означает после изменения A-записи

TTL определяет, сколько времени рекурсивный DNS-сервер может хранить полученный DNS-ответ. Это не единый таймер, который запускается во всём интернете в момент изменения записи.

Если A-запись имела TTL 3600 секунд, resolver, запросивший её минуту назад, может хранить старый IP ещё почти час. Другой DNS мог получить ту же запись 50 минут назад и обновит её примерно через десять минут. Поэтому пользователи переключаются не одновременно.

Почему уменьшение TTL после смены IP не очищает старый кеш

Проблема начинается, если TTL уменьшили одновременно со сменой IP. Допустим, до переноса запись имела TTL 86400. DNS-сервер уже получил старый IP с этим значением. Затем администратор меняет адрес и ставит TTL 300.

Уже сохранённый ответ не получит новый TTL задним числом. Resolver продолжит жить по старому значению, которое получил вместе со старой записью. TTL 300 начнёт работать для последующих ответов после нового запроса к authoritative DNS.

Текущий остаточный TTL можно увидеть через dig:

dig example.com
dig example.com @1.1.1.1
dig example.com @8.8.8.8

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

Как проверить authoritative DNS после смены IP

Сначала нужно проверить источник DNS-данных самого домена. Если authoritative DNS всё ещё содержит старую запись, очищать Windows, браузер и роутер бессмысленно.

Первая типичная ошибка — A-запись изменили не там. В панели уже виден новый IP, но домен делегирован на другие NS. Для интернета эта правка просто не существует.

Как узнать authoritative NS домена

dig NS example.com

На Windows:

nslookup -type=NS example.com

Или в PowerShell:

Resolve-DnsName example.com -Type NS

Сравните полученные NS с панелью, где редактировалась зона. Если домен делегирован на ns1.provider.net и ns2.provider.net, проверять нужно именно их.

Как запросить запись непосредственно у authoritative DNS

dig @ns1.provider.net example.com A +norecurse
dig @ns2.provider.net example.com A +norecurse

В заголовке ответа dig полезно смотреть флаг aa — authoritative answer. Он подтверждает, что сервер отвечает как авторитетный для запрошенной зоны, а не просто возвращает рекурсивно полученный результат.

Если два authoritative NS дают разные ответы, вопрос уже не в кеше пользователя. Нужно проверять синхронизацию DNS-зоны или конфигурацию DNS-сервиса.

Для сложного случая с недавно изменённым делегированием пригодится:

dig +trace example.com

Когда authoritative DNS не должен показывать IP VPS

Правило «authoritative DNS должен вернуть IP нового VPS» работает только для схемы, где домен напрямую указывает на сервер. Если используется Cloudflare Proxy, CDN, reverse proxy или внешний балансировщик, публичная DNS-запись может совершенно правильно вести не на origin-сервер, а на промежуточную инфраструктуру.

Например, при включённом проксировании Cloudflare запрос dig example.com обычно вернёт адреса Cloudflare. Сравнивать их с IP VPS и делать вывод «DNS неправильный» нельзя. В такой схеме отдельно проверяются DNS frontend и origin за ним.

Как узнать, каким DNS реально пользуется проблемный пользователь

Фраза «DNS стоит автоматически» для диагностики почти бесполезна. Нужно получить конкретный адрес resolver, который использует устройство, а затем проверить именно его.

Windows

Самый простой вариант:

ipconfig /all

Найдите активный сетевой адаптер и строки DNS Servers. В PowerShell можно получить DNS-серверы интерфейсов так:

Get-DnsClientServerAddress

Если указан адрес домашнего роутера, например 192.168.1.1, это ещё не означает, что роутер сам выполняет рекурсию: он может пересылать запросы DNS провайдера или другому upstream resolver.

Linux

Для систем с systemd-resolved:

resolvectl status

Файл /etc/resolv.conf тоже полезен, но там может находиться локальный stub вроде 127.0.0.53. В таком случае реальный upstream лучше смотреть через resolvectl status.

macOS

scutil --dns

Вывод может содержать несколько resolver для разных интерфейсов и доменных областей. Это особенно актуально при VPN и корпоративных профилях.

Почему DNS в сетевых настройках ещё не доказывает, что браузер использует его

Chrome, Edge, Firefox и некоторые системные конфигурации умеют использовать Secure DNS или DNS over HTTPS. В этом режиме DNS-запрос может уйти к отдельному DoH-провайдеру, минуя обычный DNS Windows или роутера.

Отсюда характерная ситуация: nslookup через DNS провайдера показывает старый IP, а браузер уже открывает новый сайт. Или наоборот — системный DNS новый, а браузерный DoH ещё получает другой ответ.

VPN и корпоративные агенты добавляют ещё один слой. Они могут подменять DNS, использовать собственные resolver или применять split DNS только для отдельных доменных зон.

Как найти DNS-сервер, который всё ещё возвращает старый IP

Когда authoritative DNS уже правильный, старый кеш удобно искать сравнением нескольких recursive resolver. Смотрите одновременно IP и остаточный TTL.

dig example.com
dig example.com @1.1.1.1
dig example.com @8.8.8.8

На Windows:

nslookup example.com
nslookup example.com 1.1.1.1
nslookup example.com 8.8.8.8

В PowerShell:

Resolve-DnsName example.com
Resolve-DnsName example.com -Server 1.1.1.1
Resolve-DnsName example.com -Server 8.8.8.8

Если известен DNS проблемного пользователя, добавьте его отдельным запросом:

nslookup example.com DNS_IP

Как читать остаточный TTL

Если DNS пользователя отдаёт старый IP с TTL 180 секунд, обычно разумнее повторить тест через несколько минут, чем снова менять A-запись. При нормальном обновлении после исчерпания кеша resolver запросит свежую запись.

Большой остаточный TTL объясняет, почему проблема затрагивает только часть аудитории. Например, в панели TTL уже 300, а конкретный resolver показывает старый IP с остатком в несколько тысяч секунд. Значит, его кеш появился раньше, когда действовало прежнее значение.

Старый IP найден. DNS-зону дальше не трогаем, пока новая проверка не покажет другую проблему.

Почему очистка DNS-кеша на компьютере помогает не всегда

ipconfig /flushdns очищает локальный кеш DNS Client в Windows. Он не очищает кеш интернет-провайдера, Cloudflare DNS, Google DNS, домашнего роутера или браузерного DoH.

Как отдельно проверить локальный кеш Windows

До очистки можно посмотреть его содержимое:

ipconfig /displaydns

Или через PowerShell:

Get-DnsClientCache

Затем очистить:

ipconfig /flushdns

После этого ipconfig /displaydns или Get-DnsClientCache позволяют отдельно проверить именно локальный кеш.

nslookup выполняет другую задачу: он обращается к DNS-серверу и помогает посмотреть ответ upstream resolver. Поэтому команда полезна после flushdns, но не как доказательство того, что Windows DNS Client Cache очищен.

nslookup example.com

Если upstream DNS сам возвращает старый IP, компьютер снова получит его. Повторять flushdns десять раз бессмысленно.

Linux и локальный DNS-кеш

На Linux с systemd-resolved:

resolvectl flush-caches

Но принцип тот же: локальный кеш и кеш upstream resolver — разные уровни.

Проверьте файл hosts

После ручного тестирования нового сервера в hosts нередко остаётся старая запись. Она может полностью обойти DNS и пережить сам перенос.

Windows:

C:\Windows\System32\drivers\etc\hosts

Linux и macOS:

/etc/hosts

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

Когда браузер вообще не использует системный DNS

Secure DNS, DNS over HTTPS, VPN-клиент, корпоративный агент или локальный DNS-прокси могут создать отдельный путь разрешения имени. Поэтому ситуация «Windows всё очистили, но в браузере ничего не изменилось» вполне реальна.

Здесь flushdns уже не поможет. Нужно проверить, включён ли Secure DNS в браузере, есть ли активный VPN и не используется ли корпоративный resolver.

Как отличить DNS-кеш от браузерного, CDN и серверного кеша

Если DNS уже возвращает новый IP, старая страница ещё не доказывает проблему DNS. Нужно отдельно определить адрес соединения и отдельно проверить содержимое HTTP-ответа.

Начните с DNS:

dig example.com @1.1.1.1
dig example.com @8.8.8.8

Затем запросите заголовки:

curl -I https://example.com/

Для подробной проверки:

curl -v https://example.com/

В verbose-выводе curl ищите адрес, к которому устанавливается соединение. В зависимости от версии вывод может выглядеть примерно так:

* Connected to example.com (203.0.113.20) port 443

Если это новый IP, DNS уже выполнил свою работу для конкретного запроса. Старая страница находится выше: в CDN, reverse proxy, браузере, кеше приложения или непосредственно на новом origin.

Диагностический файл на новом сервере

На новом origin можно временно создать уникальный файл, которого нет на старой площадке, например:

server-check.txt

С содержимым:

new-server

После проверки файл нужно удалить. Если перед origin стоит CDN, обычный запрос к такому файлу тоже может пройти через него, поэтому для точной проверки сервера лучше использовать curl --resolve, который будет разобран ниже.

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

Что меняется, если сайт работает через Cloudflare или другой proxy/CDN

При проксировании через Cloudflare публичный DNS обычно указывает на инфраструктуру Cloudflare, а не на origin VPS. Поэтому после смены IP origin-сервера обычный dig не обязан показать новый адрес VPS.

Здесь нужно разделить три уровня:

• DNS frontend, который видит пользователь;
• Cloudflare или другой reverse proxy/CDN;
• origin-сервер, куда proxy отправляет запрос.

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

Старая версия при этом может находиться в трёх разных местах:

• Cloudflare продолжает обращаться к старому origin;
• Cloudflare уже обращается к новому origin, но отдаёт закешированный старый объект;
• новый origin сам содержит старую копию сайта.

Это три разные неисправности. Очищать CDN-кеш бессмысленно, если proxy по-прежнему отправляет запросы на старый origin. И наоборот: менять DNS origin повторно не нужно, если запрос уже приходит на новый VPS, а старый HTML сидит в кеше.

Какие заголовки могут помочь

У CDN и reverse proxy иногда встречаются диагностические HTTP-заголовки вроде Age, CF-Cache-Status или X-Cache. Они помогают понять, был ли ответ получен из кеша, но набор и смысл заголовков зависят от конкретного сервиса и его конфигурации.

curl -I https://example.com/

Не делайте вывод по одному заголовку. Сначала определите фактическую архитектуру: DNS-only это запись или proxied, где находится origin и можно ли проверить его напрямую.

Как доказать, на какой сервер реально приходит HTTPS-запрос

DNS-команда показывает адрес, который resolver вернул клиенту. Для миграции этого иногда недостаточно. Надёжнее дополнительно проверить, куда устанавливается реальное TCP/TLS-соединение и что отвечает конкретный origin.

Проверка через curl -v

curl -v https://example.com/

В выводе найдите IP соединения. Если он совпадает с ожидаемым новым адресом, конкретный запрос уже дошёл по нужному маршруту.

Как проверить новый VPS напрямую через curl --resolve

curl --resolve позволяет временно подставить IP для домена только в одном запросе. При этом сохраняются имя хоста, HTTPS и SNI, поэтому метод намного удобнее простого обращения к https://IP/.

curl -I --resolve example.com:443:NEW_IP https://example.com/

Для сравнения можно проверить старый сервер:

curl -I --resolve example.com:443:OLD_IP https://example.com/

Если обычный запрос показывает старую страницу, а --resolve на новый IP отдаёт новую, новый origin работает. Проблему нужно искать в DNS-маршруте, proxy или CDN.

Если --resolve на новый IP тоже показывает старую версию, DNS можно временно исключить: запрос направлен прямо на новый сервер.

Есть ограничение. Если firewall origin разрешает HTTPS только с IP CDN или reverse proxy, прямое соединение может быть заблокировано. Такой отказ не означает, что новый origin неисправен — нужно учитывать сетевую схему.

Почему нужно проверить A, AAAA, www и CNAME-цепочку

Проверка одной A-записи ещё не закрывает DNS-диагностику. Пользователь может идти по IPv6, открывать www вместо корневого домена или получать конечный IP через CNAME с собственным TTL.

A и AAAA нужно смотреть отдельно

dig A example.com
dig AAAA example.com

На Windows:

Resolve-DnsName example.com -Type A
Resolve-DnsName example.com -Type AAAA

Если A уже ведёт на новый VPS, а AAAA остался на старом сервере, часть клиентов с рабочим IPv6 может продолжать видеть старую площадку.

При этом наличие AAAA не означает, что клиент всегда выберет IPv6. Современные ОС и приложения могут учитывать доступность IPv4/IPv6 и качество соединения. Поэтому симптом способен проявляться только на части сетей.

Особенно неприятный вариант — старый сервер по IPv6 не падает, а продолжает нормально отвечать. Ошибки соединения нет. Пользователь просто честно получает старый сайт.

Корневой домен и www могут вести по разным цепочкам

dig A example.com
dig AAAA example.com
dig A www.example.com
dig AAAA www.example.com

Если www.example.com настроен через CNAME, проверяйте и конечную цель:

dig www.example.com

Схема может выглядеть так:

www.example.com
CNAME site.provider.net

site.provider.net
A 203.0.113.20

CNAME и конечная A/AAAA-запись кешируются как отдельные DNS-данные и могут иметь разные TTL. Поэтому посмотреть только TTL у www.example.com иногда недостаточно.

Несколько IP не всегда означают ошибку

Домен может легитимно возвращать несколько A или AAAA из-за балансировки, GeoDNS, CDN или отказоустойчивой схемы. В таком случае задача не сводится к поиску одного «правильного IP».

Нужно сравнивать полученные адреса с ожидаемой архитектурой. Если из четырёх IP три актуальны, а один ведёт на старый сервер, проблема реальна. Если все адреса принадлежат рабочему frontend-кластеру, разные ответы сами по себе ничего не доказывают.

Почему старый IP иногда встречается даже после ожидаемого TTL

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

Resolver может временно отдать stale-ответ

Некоторые рекурсивные DNS поддерживают механизм serve-stale. Если актуальный ответ невозможно быстро получить, например authoritative DNS временно недоступен, resolver может при определённых условиях использовать ранее сохранённые данные вместо немедленной ошибки.

Такой сценарий не означает, что TTL «не работает». Это механизм устойчивости resolver, который проявляется только при определённых условиях.

В цепочке может быть несколько TTL

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

Публичный DNS — это не один сервер в одной стойке

Крупные публичные DNS используют распределённую инфраструктуру и Anycast. Запросы из разных сетей могут попадать на разные узлы сервиса, а их кеши не обязаны находиться в одном состоянии в конкретную секунду.

Поэтому проверка 8.8.8.8 с вашего сервера не доказывает, что пользователь на другом континенте обращается к тому же физическому узлу и видит тот же кеш.

Разный IP может быть предусмотрен архитектурой

GeoDNS, балансировщик или несколько A/AAAA способны намеренно отдавать разные адреса. Перед тем как назвать один из них старым кешем, убедитесь, что он действительно больше не должен обслуживать домен.

Если ожидаемый TTL уже закончился, не начинайте с повторной смены DNS. Сначала проверьте, что именно сейчас считается «старым»: DNS-ответ, CNAME, один из нескольких адресов или уже содержимое сайта.

Можно ли ускорить обновление DNS после того, как IP уже изменён

Централизованно удалить корректно закешированный DNS-ответ со всех recursive resolver нельзя. Уже полученный старый IP обычно живёт по тому TTL, который resolver получил вместе с ним.

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

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

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

Когда лучше ничего больше не менять

Если authoritative DNS правильный, новый origin проверен через curl --resolve, а один конкретный resolver возвращает старый IP с уменьшающимся TTL, дополнительная правка DNS только усложнит диагностику.

Старый IP найден. Ждём его кеш, а не перестраиваем зону.

Проверка за 10–15 минут: где остался старый IP

1. Узнать authoritative NS домена.
2. Запросить A непосредственно у authoritative DNS с +norecurse.
3. Проверить AAAA.
4. Проверить корневой домен и www.
5. Просмотреть CNAME-цепочку, если она есть.
6. Сравнить ответы 1.1.1.1 и 8.8.8.8.
7. Определить DNS, который реально использует проблемное устройство.
8. Проверить Secure DNS/DoH и VPN.
9. Посмотреть IP и остаточный TTL проблемного resolver.
10. Проверить hosts.
11. При необходимости очистить локальный DNS-кеш.
12. Проверить фактический IP соединения через curl -v.
13. Проверить новый origin через curl --resolve.
14. Если используется CDN, отделить DNS frontend от origin и CDN-кеша.
15. Не отключать старый сервер, пока переход не завершён и схема записи данных не подготовлена.

Authoritative DNS старый — исправляем зону. Authoritative новый, resolver старый — смотрим TTL. DNS пользователя новый, а соединение идёт не туда — проверяем DoH, VPN и proxy. Соединение уже приходит на новый origin, но страница старая — DNS больше не основная гипотеза.

Как подготовить следующую смену IP без долгого переходного периода

TTL нужно уменьшать до смены IP. Если сделать это одновременно с переключением A-записи, предыдущие кеши продолжат жить по старому значению.

Если сейчас TTL равен 14400 или 86400, сначала установите временное более короткое значение, а затем дождитесь, пока старый TTL успеет выйти из ранее созданных кешей. Только после этого короткий TTL действительно помогает быстро переключить адрес.

Для подготовленной миграции иногда используют 300–600 секунд, если DNS-провайдер и архитектура позволяют такое значение. Это не универсальный постоянный TTL. После стабилизации его можно увеличить.

1. Проверить текущие TTL A, AAAA и CNAME.
2. Заранее уменьшить TTL необходимых записей.
3. Дождаться окончания предыдущего высокого TTL.
4. Проверить новый origin через hosts или curl --resolve.
5. Убедиться, что HTTPS, виртуальный хост и редиректы работают на новом сервере.
6. Изменить A/AAAA либо origin в панели proxy/CDN — в зависимости от архитектуры.
7. Проверить authoritative DNS.
8. Сравнить ответы нескольких recursive resolver.
9. Контролировать фактическое HTTPS-соединение.
10. Не выключать старый origin сразу после переключения.
11. После стабилизации вернуть рабочий TTL.

Перед переносом полезно убедиться, что публичные resolver уже получают пониженный TTL:

dig example.com @1.1.1.1
dig example.com @8.8.8.8

Если вчера запись имела TTL 86400, а сегодня в панели стоит 300, этого недостаточно. Ранее созданные кеши ещё могут жить по старому значению.

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

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

У WordPress, WooCommerce, форума или личного кабинета ситуация сложнее. Пока часть пользователей работает со старым origin, а часть уже с новым, оба сервера могут принимать изменения: заказы, формы, комментарии, регистрации, изменения профилей.

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

Поэтому для динамического проекта переходный период нужно планировать отдельно. Возможные схемы зависят от приложения: единая база данных на время переключения, синхронизация, запрет записи на старом origin, режим обслуживания или перенаправление запросов со старого сервера на новый. Универсального варианта здесь нет.

Что проверить перед выключением старого сервера

• authoritative DNS соответствует новой схеме;
• основные публичные resolver больше не возвращают старую запись;
• A, AAAA, www и CNAME проверены;
• CDN или proxy обращается к новому origin;
• curl --resolve подтверждает работу нового сервера;
• динамические данные не расходятся между двумя площадками;
• старый IP больше не нужен для рабочих запросов.

Тогда проблема «часть пользователей видит старый сайт» перестаёт быть ожиданием вслепую. Можно точно определить resolver, IP соединения и уровень, на котором сохранилось старое состояние. И уже после этого решать: ждать TTL, чистить локальный кеш, исправлять DNS или вообще уходить в диагностику CDN и самого сервера.