Проблемы с DNS после переезда

MAATRIX

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

Быстрая диагностика: куда указывает домен сейчас

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

# какой IP отдаёт ваш домен
dig +short example.com A
# полный ответ с TTL и источником
dig example.com A
# спросить конкретно у публичного резолвера Google
dig @8.8.8.8 example.com A
# и у Cloudflare
dig @1.1.1.1 example.com A

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

Почему обновление не мгновенное: TTL и кэши

Главная причина «сайт открывается со старого сервера» — TTL. Каждая DNS-запись несёт время жизни в секундах: столько резолверы по всему миру хранят её в кэше, прежде чем спросить заново. Если у вашей A-записи был TTL 86400 (сутки), то после смены IP часть пользователей будет попадать на старый сервер ещё до суток — ровно столько, сколько указано в TTL.

# текущий TTL записи (число во второй колонке)
dig example.com A
# пример: example.com. 86400 IN A 1.2.3.4  — сутки кэша

Отсюда правило переезда: снижать TTL нужно ЗАРАНЕЕ, за день-два до смены IP, до 300 секунд. Тогда в момент переключения мир подхватит новый адрес за минуты. Если вы этого не сделали и меняете IP при большом TTL — остаётся только ждать, пока старое значение истечёт. Ускорить чужие кэши насильно нельзя, они честно держат запись ровно столько, сколько вы сами велели в TTL.

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

Проверяем, что записи вообще правильные

Часто дело не в кэше, а в ошибке в самих записях. Пройдитесь по чек-листу. A-запись должна указывать на новый IP — и для голого домена, и для www, если он используется. Убедитесь, что где-то не осталось второй A-записи со старым IP: две записи заставят трафик случайно уходить то туда, то сюда.

# проверяем и www, и голый домен
dig +short example.com A
dig +short www.example.com A
# на каких NS-серверах живёт зона
dig +short example.com NS

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

Локальный кэш: когда проблема только у вас

Бывает, что весь мир уже видит новый сервер, а у вас упорно открывается старый. Почти всегда это локальный кэш — операционной системы, браузера или домашнего роутера. Проверить легко: если dig @8.8.8.8 отдаёт новый IP, а сайт всё равно старый, чистите своё:

# сброс кэша DNS
# Linux (systemd-resolved)
resolvectl flush-caches
# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
# Windows
ipconfig /flushdns

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

Почта, поддомены и другие записи

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

# проверка почтовых записей
dig +short example.com MX
# поддомены тоже проверьте отдельно
dig +short shop.example.com A

То же касается поддоменов, SPF/DKIM для почты, записей CNAME. Каждая запись обновляется по своему TTL независимо. Составьте перед переездом список всех записей зоны и после переключения сверьтесь с ним через dig — так вы не забудете обновить поддомен и не сломаете то, что переезжать не должно было.

Частая скрытая проблема после переезда — сломанная почта из-за записей защиты от спама. Если сервер сайта одновременно рассылал письма, то SPF-запись перечисляет разрешённые для отправки IP, и старый адрес в ней после переезда становится неверным, а новый — не добавленным. В итоге письма уходят, но попадают в спам у получателей. Проверьте TXT-запись SPF и обновите в ней IP отправляющего сервера. Это ровно тот случай, когда «сайт переехал нормально, а письма перестали доходить», и причина не в почтовом сервере, а в забытой строке защиты, которую легко упустить в общей суете переключения.

Профилактика: как переезжать без DNS-боли

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

Помогает и стабильный провайдер с удобным управлением DNS и предсказуемым выделением IP. У MAATRIX VPS выдаются с чистыми IP в локациях RU, US и UK, оплата из России картой или криптой, а поднять новый сервер и подготовить его к переключению можно за минуты. Чем меньше суеты на этапе подготовки, тем спокойнее проходит момент смены записи — и тем быстрее вы забываете о том, что переезд вообще был.

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