Що робити, якщо сайт перестав відкриватися після зміни DNS
Що робити, якщо сайт перестав відкриватися після зміни DNS
Зміна DNS — річ підступна. Сайт, здається, вже перевели, а в браузері порожньо, помилка або стара адреса. І далі починається паніка: хостинг звинувачують першим, потім реєстратора, потім себе.
Нужен не шум, а перевірка по кроках. Часто проблема сидить в одній записі, одному NS або в кеші у провайдера, а не в самому сайті. Якщо вам потрібно зрозуміти, що робити, якщо сайт перестав відкриватися після зміни DNS, почніть з факту: що саме змінювали і в якій хвилині це зробили.
Перевірити, дійсно чи проблема пов'язана саме з DNS
Спочатку відокремте DNS-ефект від всього іншого. Якщо до зміни DNS сайт відкривався, а через 5 хвилин перестав, це ще не доказ. Співпадіння за часом оманливе.
Подивіться, як поводиться сайт з різними симптомами: не відкривається взагалі, переходить на інший домен, видає помилку SSL або просто крутить завантаження. Це вже 4 різні сценарії, і у кожного свій джерело. Іноді проблема виглядає як DNS, а насправді зламався редирект на https або закінчився сертифікат.
Є простий тест: спробуйте відкрити сайт за прямим IP, якщо він вам відомий, або через інший канал зв'язку, де вже збережена стара адреса. Якщо за IP сервер відповідає, а за доменом ні, DNS дійсно в списку підозрюваних. Якщо не відповідає ні за чим, тоді це вже не про DNS, а про сервер, віртуальний хост або саму площадку.
Перевіряйте і зовнішні фактори. Наприклад, якщо на сайті нещодавно змінювали SSL або редиректи, браузер може показати зовсім не ту помилку, яку ви очікуєте. Тут корисно дивитися не на здогадку, а на точне повідомлення. Один текст помилки іноді економить 30 хвилин зайвих пошуків.
Співвіднести новий DNS з тим, що має відкриватися
Після зміни DNS відкрийте список записів і порівняйте його з тим, що реально потрібно відкривати. Для кореня домену зазвичай перевіряють A-запис, для IPv6 — AAAA, для піддомену часто потрібен CNAME. Помилка в одній букві перетворює нормальний сайт у тупик.
Потрібно дивитися не тільки на сам домен, але й на піддомен. Наприклад, www може вести на один хост, а без www — на інший. І якщо одна з точок вказує на старий сервер, користувачі побачать різні результати в залежності від того, як вводять адресу.
Добре допомагає звірка з планом міграції. Якщо ви переносили сайт, то новий DNS має вказувати на ту адресу, де вже піднято сайт, а не на порожню тестову площадку. Помилка тут часто проста: запис створили, а ціль залишили стару.
Якщо потрібно перевірити зв'язок глибше, порівняйте поточні значення з тим, що має бути за завданням. Тут важливі 3 речі: ім'я запису, тип запису та адреса призначення. Один зайвий символ у CNAME або IP з чужої мережі — і сайт перестає відкриватися лише для частини запитів.
Перевірити, чи не зламаний перехід на нового провайдера DNS
Коли домен переводять на нового DNS-провайдера, потрібно впевнитися, що делегування пройшло повністю. У домена повинні стояти правильні NS, а зона — реально обслуговуватися новим сервером. Інакше в панелі все красиво, а в інтернеті по-прежньому живе стара конфігурація.
Перевірте, чи збігаються NS у реєстратора з тим, що ви прописали у нового провайдера. Якщо там залишився один старий адрес, домен може поводитися непередбачувано. Це особливо помітно, коли запис змінювали вночі, а вранці сайт вже «то відкривається, то ні».
Ще одна часта пастка — зона створена, але не активна. Новий DNS-провайдер може прийняти домен у панелі, але не обслуговувати записи. У такому випадку ви бачите налаштування, а зовнішній світ їх не бачить. Неприємно, так.
Хороший спосіб перевірити — подивитися відповідь на NS-запит з кількох джерел. Якщо частина відповідей йде на старого провайдера, перехід не завершено. І тут важливий не один скрін, а 2–3 незалежні перевірки.
Врахувати затримку оновлення по світу та у користувачів
Після зміни DNS частина людей буде бачити нову адресу, а частина — стару. Це нормально. У провайдера, роутера та пристрою є кеш, і він не обнуляється за вашим бажанням.
Затримка оновлення по світу може тривати по-різному, тому не робіть висновків за одним телефоном або одним офісом. Перевірте сайт через домашній інтернет, мобільну мережу та хоча б один зовнішній інструмент. Коли різні точки показують різне, це майже завжди слід кешу, а не поломка сайту.
Якщо домен нещодавно жив на старих налаштуваннях, деякі резолвери ще пам'ятатимуть їх. Тоді один користувач бачить новий сервер, інший — старий, а третій отримує помилку через невідповідність записів. Таке поводження особливо помітне при зміні A-запису на інший хост.
Тут допомагає проста дисципліна: не змінюйте DNS туди-сюди 5 разів підряд. Кожна нова правка збиває картину сильніше, а потім вже ніхто не розуміє, яка запис остання. Краще зафіксувати одне зміна і почекати, ніж метатися між трьома варіантами.
Перевірити конфлікт між IPv4 та IPv6
Іноді A-запис вже правильний, а AAAA вказує нікуди. Для частини пристроїв це не дрібниця, а повноцінний стоп-сигнал. Сучасні браузери і мережі люблять IPv6, і якщо він зламаний, сайт може здаватися недоступним навіть при робочому IPv4.
Перевіряйте обидві записи окремо. Якщо домен має працювати тільки на IPv4, AAAA краще не залишати випадково. Пустий або старий IPv6-адрес часто створює дивну картину: з одного інтернету сайт відкривається, з іншого — ні.
Буває і навпаки. IPv6 вже піднято, а A-запис веде на старий сервер. Тоді одні користувачі заходять без проблем, а інші ловлять таймаут. Зовні це виглядає як хаос, але причина зазвичай одна: дві записи дивляться в різні сторони.
Якщо у вас є доступ до налаштувань DNS, порівняйте обидва адреси з адресою робочої площадки. Тут не потрібно гадати. Потрібні 2 числа: IPv4 та IPv6. І обидва повинні вести туди, де сайт дійсно відповідає.
Переконатися, що сайт відповідає за адресою призначення
Навіть ідеальний DNS не врятує, якщо сервер на іншій стороні мовчить. Після зміни запису потрібно перевірити, чи живий хост, піднятий чи веб-сервер і не втрачена чи прив'язка до потрібного домену. Іноді сайт стоїть на місці, але віртуальний хост налаштований на старе ім'я.
Якщо на сервері кілька сайтів, правильний віртуальний хост вирішує все. Один і той же IP може обслуговувати 10 доменів, і без точної прив'язки сервер віддасть не той проект або помилку. Це особливо помітно після перенесення на нову площадку, коли конфігурацію, здавалося б, скопіювали, а ім'я домену забули.
Перевірте і саму відповідь сервера: 200, 301, 302, 404 або 500. Ці коди говорять більше, ніж будь-який чат з підтримкою. Якщо за адресою призначення приходить 404, значить DNS вже дійшов, але сайт на хості не відповідає очікуванням.
Іноді корисно відкрити не головну сторінку, а конкретний шлях, наприклад /login або /admin. Так можна побачити, чи працює сайт цілком, чи тільки стартова сторінка. Коли йдеться про перенесення, дрібна перевірка краща за велике самовпевнене «ніби відкривається».
До слова, якщо потрібна розважальна пауза між перевірками, можна глянути анекдоти про студентів. Анекдоти безкоштовно. Короткі — це 1–2 хвилини, не більше. Іноді така пауза допомагає не переплутати старий сервер з новим.
Перевірити HTTPS та сертифікат після зміни запису
DNS може вже вести на правильний хост, а браузер все одно нарікає на HTTPS. Тоді проблема в сертифікаті, HSTS або редиректі. Дуже поширена історія після перенесення на новий IP.
Перевірте, чи видано сертифікат саме на цей домен і піддомен. Якщо нова адреса веде на сервер, де сертифікат видано на інше ім'я, браузер не пустить користувача далі. І тут не допоможе ні кеш, ні перезавантаження.
HSTS додає жорсткості. Якщо сайт раніше працював по HTTPS і в браузері закріплено правило, спроба відкрити його за старою або кривою конфігурацією призведе до блокування одразу. Це не баг браузера, а його пам'ять, і вона тримається довше, ніж хотілося б.
Ще одна дрібниця — редирект з http на https. Якщо він вказує на старий домен, новий DNS виглядає справним, але сайт все одно йде не туди. Перевіряйте кінцеву адресу після редиректу, а не тільки стартову точку.
Якщо після всіх кроків все ще незрозуміло, відкривається чи сайт у інших, має сенс звірити питання з матеріалом як перевірити сайт на шахрайство. Іноді люди сприймають помилку сертифіката за спробу підміни, хоча це просто несумісність записів і домену.
Підготувати, що передати в підтримку хостингу або DNS
Коли свої перевірки закінчені, зберіть короткий пакет для підтримки. Потрібні домен, нові NS, точний час зміни, скрін помилки та список того, що вже перевірили. Це 5 пунктів, і вони економлять більше часу, ніж довгий лист «у нас нічого не працює».
Не забудьте вказати, з якого пристрою та мережі видна проблема. Для підтримки це не формальність, а корисна деталь: один і той же домен може відкриватися з мобільної мережі і падати з домашньої. Ще корисно додати поточні записи A, AAAA та CNAME, якщо вони змінювалися.
Якщо змінювали провайдера DNS, напишіть, у кого був домен раніше і у кого він зараз. Іноді допомога впирається в те, що зона вже делегована, але старий сервер ще віддає відповідь в частині резолверів. Чим точніше ви опишете маршрут, тим менше кіл буде у відповіді.
Хороший тон — одразу прикласти результат перевірки з 2–3 джерел, а не один скрін з браузера. Підтримці простіше побачити, де розходиться картина: в зоні, у реєстратора чи на сервері. І чим менше здогадок, тим швидше знаходять вузьке місце.
Якщо хочеться трохи розвантажити голову після технічної рутини, можна відволіктися на найжорстокіші експерименти психологів — матеріал непростий, але він добре збиває відчуття, що один зламаний DNS тримає світ на місці. А потім вже повертайтеся до логів і NS-записів.
Що ще перевірити, якщо проблема плаває
Якщо сайт відкривається тільки у частини користувачів, дивіться не на один фактор, а на зв'язку з 3 речей: DNS, кеш і сервер. Коли всі три врознобій, симптоми змінюються кожну годину. Це якраз той випадок, коли один і той же домен поводиться по-різному вранці та ввечері.
Іноді допомагає перевірка через зовнішній сервіс резолва і окремий тест у браузері без збережених даних. Не тому, що це магія, а тому, що ви відокремлюєте локальну картину від загальної. Якщо локально погано, а зовні нормально, проблема сидить ближче до пристрою або провайдера.
Якщо після переносу ви ще й змінювали структуру сайту, не забувайте про старі посилання. Користувач може потрапити на неіснуючу сторінку і вирішити, що домен зламаний повністю. На практиці ламається лише 1 шлях з 20.
І так, іноді корисно дивитися на проблему як на ланцюг. DNS веде на сервер, сервер віддає сайт, сертифікат підтверджує домен, а браузер приймає рішення пустити користувача чи ні. Якщо один з 4 елементів випав, сайт вже не відкривається як треба.
Коли все перевірено, а доступ все ще стрибає, зафіксуйте останні 2 зміни і не вносьте нові до відповіді підтримки. Інакше ви самі собі заважаєте побачити, де саме обірвалася ланцюг.
