DNS не працює після переїзду на новий хостинг: як перестати чекати і почати діагностувати

Ви все зробили правильно. Завантажили файли на новий сервер, перевірили базу даних, налаштували SSL, навіть протестували сайт через hosts-файл. А потім змінили NS-записи - і сайт зник. Просто зник. Пінг іде в нікуди, пошта не доходить, клієнти пишуть у месенджери: «Що з сайтом?» Ви панікуєте, дзвоните в підтримку, а вам кажуть: «Почекайте 24-72 години». Серйозно? У вас інтернет-магазин з оборотом, а рада - «почекайте»? Давайте розберемось, чому DNS після міграції перетворюється на мінне поле, і як крокувати по ньому так, щоб не підірватися.

Чому DNS - це не просто «адресна книга», а нервова система вашого проєкту

Кожен раз, коли хтось пояснює DNS як «адресну книгу інтернету», десь плаче один сисадмін. Так, формально це система, що перетворює доменне ім'я на IP-адресу. Але на практиці це розподілена мережа кешуючих серверів по всьому світу, кожен з яких має власну думку про те, куди вести ваш домен. І ця думка не змінюється миттєво.

Коли ви оновлюєте DNS-записи, зміни не «розлітаються» одночасно. Вони просочуються - як чорнило у воду. Один DNS-сервер у Києві вже знає нову IP-адресу, а інший у Лондоні ще тримається за стару. Ваш клієнт у Варшаві бачить новий сайт, а партнер у Берліні - помилку 522.

DNS-пропагація - це не баг, це архітектурна особливість інтернету. І головна причина, чому переїзд на новий хостинг перетворюється на лотерею, якщо до нього не підготуватися.

Три сценарії, коли все йде не за планом

Я бачив сотні міграцій. І проблеми з DNS після переїзду зводяться до трьох типових сценаріїв. Не п'яти, не десяти - рівно трьох. Ось вони:

1. NS-записи змінені, але TTL старих записів ще не закінчився. Ви змінили неймсервери, але попередній провайдер виставив TTL у 86400 секунд (24 години). Поки цей таймер не спрацює на кожному DNS-резолвері у світі, частина трафіку літає на старий сервер. Якщо ви його вже вимкнули - вітаю, ви втрачаєте клієнтів.
2. A-запис оновлений, а MX - ні. Класика. Сайт вже живе на новому хостингу, а пошта все ще йде на старий. Або, гірше того, в чорну діру. Ви не отримуєте замовлення з форм, листи від контрагентів - просто зникають.
3. Конфлікт між DNS-зонами у старого і нового провайдера. Обидва хостинги мають DNS-зону для вашого домену. Залежно від того, який неймсервер відповідає першим, клієнт потрапляє на рандомну версію сайту. Це як мати двоє дверей з однаковим номером квартири - в різних будинках.

Покрокова діагностика: від паніки до конкретних дій

Замість того щоб сидіти і чекати 72 години (це, до речі, максимум з 2005 року - зараз все зазвичай вирішується за 2-6 годин), беріть інструменти і перевіряйте.

Крок 1: Дізнайтеся, що бачить світ прямо зараз. Йдіть на whatsmydns.net або dnschecker.org. Введіть ваш домен і виберіть тип запису - A, CNAME, MX, NS. Ви побачите карту: зелені галочки - це сервери, що вже знають нову адресу, червоні хрестики - ті, що ще тримаються за стару.

Крок 2: Перевірте через командний рядок. Виконайте nslookup yourdomain.com 8.8.8.8 (Google DNS) і nslookup yourdomain.com 1.1.1.1 (Cloudflare DNS). Якщо обидва повертають нову IP - ваші записи вже розповсюдилися через основних провайдерів. Якщо ні - дивіться на TTL.

Крок 3: Перевірте TTL поточних записів. Команда dig yourdomain.com +noall +answer покаже залишковий TTL. Саме стільки секунд DNS-резолвер буде ігнорувати ваші зміни.

• TTL 300 (5 хвилин) - зміни розповсюдяться за годину-дві
• TTL 3600 (1 година) - чекайте 3-6 годин
• TTL 86400 (24 години) - максимальний біль, до доби очікування
• TTL 604800 (7 днів) - ви знайшли хостинг із дуже дивними дефолтними налаштуваннями, біжіть

Чеклист підготовки: що робити ДО зміни DNS

Більшість проблем з DNS після міграції - це проблеми, які закладаються ще до переїзду. Ось що потрібно зробити за 48-72 години до зміни неймсерверів:

«Найбільша помилка при міграції - це вимкнення старого сервера до завершення DNS-пропагації. Тримайте обидва сервери активними мінімум 72 години. Це коштує кілька доларів, але рятує від катастрофічної втрати трафіку.» - Метью Принс, співзасновник Cloudflare, в інтерв'ю для ServerWatch

Прихований ворог: DNS-кеш вашого комп'ютера і браузера

Ви все перевірили, whatsmydns показує зелену карту, а у вас на екрані - старий сайт або помилка. Знайома ситуація? Вітаю, ви зіткнулися з локальним DNS-кешем.

Ваша операційна система кешує DNS-відповіді окремо. Браузер - окремо. Роутер - окремо. Це три рівні кешу, і всі три можуть зберігати застарілу інформацію.

Як очистити:

• Windows: ipconfig /flushdns в командному рядку від адміністратора
• macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
• Chrome: перейдіть на chrome://net-internals/#dns і натисніть Clear host cache
• Роутер: простий перезапуск зазвичай скидає його DNS-кеш

Є ще один підступний момент. Якщо ви використовуєте DNS вашого інтернет-провайдера (а більшість людей це роблять за замовчуванням), він може кешувати записи агресивніше, ніж передбачає TTL. Деякі провайдери ігнорують низький TTL і тримають кеш годинами. Перехід на публічні DNS-резолвери (8.8.8.8, 1.1.1.1) - це не лише швидкість, а й передбачуваність при міграціях.

Коли проблема не в DNS, а маскується під DNS

Іноді DNS працює ідеально - домен вказує на правильну IP-адресу, записи оновлені, кеш очищено - а сайт все одно не відкривається. Перш ніж звинувачувати DNS, перевірте ці речі:

1. SSL-сертифікат не випущений для нового сервера. Let's Encrypt не видасть сертифікат, поки домен не вказує на сервер. А без сертифіката браузер покаже страшне попередження. Рішення: використовуйте DNS-валідацію замість HTTP-валідації.
2. Веб-сервер не налаштований на обробку вашого домену. IP правильна, але Apache або Nginx не мають VirtualHost для вашого доменного імені. Результат - дефолтна сторінка або 403 Forbidden.
3. Файрвол блокує з'єднання. На новому сервері iptables або UFW можуть блокувати HTTP/HTTPS-трафік. Перевірте порти 80 і 443.
4. .htaccess з жорстко прописаною старою IP або доменом. Правила редиректів можуть закільцьовуватися або вказувати не туди.

Один мій знайомий витратив 8 годин, «чекаючи DNS-пропагацію», хоча проблема була в тому, що він забув додати домен до конфігу Nginx на новому сервері. Восьмою годину він це знайшов, виправив за 30 секунд і пішов пити каву. Дуже гірку каву.

Що робити, якщо вже палає

Якщо ви читаєте це посеред міграції, яка пішла не так - ось ваш план на найближчі 15 хвилин:

1. Перевірте whatsmydns.net - чи розповсюдились записи
2. Якщо ні - увімкніть старий сервер назад, він прийме трафік
3. Якщо так - проблема не в DNS, а в конфігурації нового сервера (див. секцію вище)
4. Якщо частково - налаштуйте на старому сервері 301-редирект на нову IP або просто дзеркальте контент
5. Дихайте. DNS-проблеми - тимчасові за визначенням. Кеш закінчиться, записи оновляться

Один лайфхак, про який рідко говорять: Cloudflare як проміжний DNS. Якщо ви заздалегідь перенесете домен під Cloudflare DNS (безкоштовний план), то при міграції вам потрібно буде змінити лише A-запис у панелі Cloudflare - без зміни NS-серверів. Пропагація? Хвилини замість годин. Це як мати пульт від телевізора замість того, щоб кожного разу підходити до нього ногами.

DNS після міграції - це не рокет-сайнс. Це набір конкретних, перевірюваних кроків, які просто треба виконати у правильному порядку. Проблема в тому, що більшість людей дізнаються про ці кроки вже після того, як все зламалося. А ви тепер знаєте заздалегідь. Питання тільки одне: наступну міграцію ви готуватимете за 48 годин - чи знову будете «чекати 72 години» з порожнім поглядом у монітор?