Одна из главных опасений при смене хостинга — простой сайта. На самом деле, при правильной подготовке переключение DNS можно выполнить абсолютно незаметно для пользователей. Ключевой инструмент — грамотное управление TTL (Time To Live).

Что такое TTL и почему это важно

TTL (Time To Live) — время в секундах, в течение которого DNS-серверы кэшируют вашу запись. Если TTL = 86400 (1 сутки), то после смены A-записи часть пользователей будет попадать на старый сервер ещё до 24 часов.

TTL	Время распространения	Когда использовать
86400 (24 часа)	До 24 часов	Стабильная запись, без изменений
3600 (1 час)	До 1 часа	Стандартное значение
300 (5 минут)	5–15 минут	Подготовка к миграции
60 (1 минута)	1–5 минут	Аварийное переключение

Чеклист миграции DNS без простоя

За 24–48 часов до миграции: Снизить TTL до 300 секунд
Настроить новый сервер до переключения DNS
Тест через /etc/hosts — убедиться, что сайт работает
Синхронизировать контент — финальный rsync перед переключением
Сменить A-запись на IP нового сервера
Мониторинг — следить за ошибками в течение часа
Старый сервер — держать активным 48–72 часа

Тестирование нового сервера через /etc/hosts

># На вашем ПК (Linux/macOS)
sudo nano /etc/hosts

# Добавить строку:
NEW-SERVER-IP example.com www.example.com

# Теперь браузер откроет сайт с нового сервера
# (DNS записи при этом не меняются)

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

Финальная синхронизация перед переключением

# Синхронизировать файлы (только изменения)
rsync -avz --delete user@old-server:~/public_html/   root@new-server:/var/www/example.com/

# Синхронизировать БД
mysqldump -h old-server -u dbuser -p dbname |   ssh root@new-server "mysql -u newuser -p newdb"

Инструменты проверки DNS: Используйте dnschecker.org или whatsmydns.net для мониторинга распространения DNS по всему миру в реальном времени.

Проверка DNS из командной строки

># Проверить текущую A-запись
dig example.com A +short

# Проверить через конкретный DNS-сервер
dig @8.8.8.8 example.com A +short
dig @1.1.1.1 example.com A +short

# Автоматический мониторинг (опрос каждые 30 сек)
while true; do
  echo "$(date): $(dig @8.8.8.8 example.com A +short)"
  sleep 30
done

Перенос почты без прерывания

MX-записи управляют почтой отдельно от сайта. При миграции хостинга важно не сломать почту:

># Перенести почту ПЕРЕД сменой MX-записей
# Изменить MX только после переноса ящиков
# Сохранить старые MX-записи как резервные (приоритет 20)

# Пример:
# MX 10 mail.new-server.com  ← основной
# MX 20 mail.old-server.com  ← резервный (держать 72 часа)

Не удаляйте старый хостинг сразу! Оплатите старый хостинг ещё на 1 месяц после миграции. Это страховка на случай, если что-то пошло не так или пользователи с высоким TTL всё ещё попадают на старый сервер.

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

Три ошибки объясняют почти все жалобы «сайт не переключился» после миграции.

dig example.com NS +short
ns1.old-host.com
ns2.old-host.com

Самая частая причина, почему изменения в DNS-панели «не работают», — домен продолжает делегирован на NS-серверы старого хостинга, а правки вносятся в панели нового. Снижение TTL и смена A-записи там, куда реально никто не обращается, ничего не изменит. Сначала проверьте делегирование NS через регистратора, и только потом редактируйте записи в правильном месте.

curl -I https://example.com/ | grep -i "x-served-by\|server"

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

550 5.1.1 <user@example.com>: Recipient address rejected: User unknown

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

Стратегии миграции: сравнение

Параметр	Одномоментное переключение	Параллельная работа (dual-run)
Риск простоя	Выше	Минимальный
Сложность подготовки	Ниже	Выше (два живых окружения)
Стоимость периода миграции	Один тариф	Два тарифа одновременно
Подходит для	Небольшие сайты без критичной аудитории	Продакшн с высокой нагрузкой

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

Когда снижение TTL не поможет

Если домен подключён к Cloudflare с включённым проксированием (оранжевое облако), конечные пользователи видят anycast-адреса Cloudflare, а не IP вашего хостинга — TTL самой A-записи на них не влияет вообще, переключение происходит мгновенно на уровне прокси. TTL важен только для записей, которые резолвятся напрямую в IP сервера (серое облако), или для NS-делегирования при смене регистратора DNS. Некоторые резолверы интернет-провайдеров игнорируют TTL ниже 300–600 секунд и кэшируют дольше заявленного — рассчитывайте не только на технический TTL, но и на реальный запас в 24–48 часов.

Как проверить результат

Пока не переключили трафик реальных пользователей, сравните оба сервера напрямую:

# Прямой запрос к новому серверу в обход DNS, для сравнения ответа
curl -I --resolve example.com:443:NEW_SERVER_IP https://example.com/

# Прямой запрос к старому серверу — должен пока отвечать
curl -I --resolve example.com:443:OLD_SERVER_IP https://example.com/

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