Что делать если сайт перестал открываться после смены 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 изменения и не вносите новые до ответа поддержки. Иначе вы сами себе мешаете увидеть, где именно оборвалась цепочка.
