Одне з головних побоювань під час зміни хостингу — простій сайту. Насправді за правильної підготовки перемикання 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.