Если браузер пишет ERR_NAME_NOT_RESOLVED, то он честно признается, что не смог превратить имя сайта в IP адрес. Интернет есть, вкладки крутятся, а нужная страница не открывается. Это не про сервер, который вас «послал» и не про медленную сеть. Это про DNS, ту самую «телефонную книгу» интернета, где у каждого доменного имени должен быть номер. Нет номера, нет разговора.
Обычно в таких случаях мы нервно обновляем страницу и ругаем провайдера. Но проблема часто куда банальнее. Опечатка в адресной строке, лишний пробел, странный символ вместо обычной буквы, локальная запись в файле hosts, капризный роутер с устаревшим кешем. Иногда виноват сам домен, он истек по сроку или у него пропали записи. Бывает и фильтрация трафика на стороне провайдера.
Важно понимать разницу между популярными ошибками. ERR_CONNECTION_REFUSED означает, что до сервера достучались, но тот не разговаривает на нужном порту. ERR_CONNECTION_TIMED_OUT намекает на сетевую задержку. ERR_NAME_NOT_RESOLVED говорит именно о сбое на этапе «найти IP по имени».
Хорошая новость в том, что это одна из тех проблем, которые часто решаются за пару минут. Ниже разбираем, почему она возникает и как действовать, чтобы вернуть интернет к жизни без шаманства.
Что означает ошибка и где она возникает
DNS работает как цепочка шагов. Сначала браузер спрашивает у системы, знает ли она IP для домена. Система заглядывает в собственный кеш и в файл hosts, затем обращается к резолверу на стороне провайдера или к публичному серверу. Если повезет, ответ уже есть в кеше. Если нет, резолвер идет по иерархии доменных серверов и собирает свежий ответ. На любом этапе может случиться затык.
Чаще всего вы видите ERR_NAME_NOT_RESOLVED, когда локальный резолвер не смог получить ответ или получил ответ NXDOMAIN. Это формальная запись «имя не существует». Такое бывает, если домен только что зарегистрирован и записи еще не разошлись по миру, если администратор удалил записи A или AAAA, если указаны неверные NS серверы.
Иногда проблема на вашей стороне. Роутер кэширует старый ответ и не спешит обновлять, система копит устаревшие записи, браузер держит собственный кеш. Также мешают VPN, блокировщики рекламы, корпоративные фильтры, детский режим на уровне провайдера. Любой из этих слоев может перехватить запрос и вернуть «пусто».
Есть еще фактор человек. Адрес, введенный с ошибкой, очень похож на настоящий, только одна буква заменена похожим символом. В русской и латинской раскладках много двойников, а у IDN доменов бывают омонимы. Браузер в таких случаях обычно показывает punycode, и это хороший повод еще раз присмотреться к строке адреса.
И наконец, сам сайт мог «сломаться» на уровне DNS. Истек домен, отключились NS серверы, не продлили услугу у регистратора, пропали glue записи у регистратора для собственных NS. Снаружи это выглядит как магия, но по факту у имени просто нет корректной привязки к IP.
Быстрая диагностика без паники
Начинаем с очевидного. Скопируйте адрес из закладки в чистую строку, уберите лишние пробелы и слэши, попробуйте открыть сайт через поиск. Если в выдаче есть официальная ссылка и описание, кликните по ней, а не по вашей старой закладке. Переход с поисковой страницы иногда помогает избежать невидимых символов в адресе.
Проверьте, воспроизводится ли ошибка на другом устройстве и в другой сети. Включите мобильный интернет и попробуйте там. Если на мобильной сети все открывается, значит проблема в домашнем резолвере или роутере. Если не открывается нигде, вероятно, дело в самом домене или в глобальной фильтрации.
Загляните в файл hosts. На Windows путь такой: C:WindowsSystem32driversetchosts. На macOS и Linux путь такой: /etc/hosts. Внутри не должно быть строк, которые подменяют IP для нужного домена. Комментарии начинаются с #, их трогать не нужно. Если увидите странные строки, временно закомментируйте их.
Сбросьте локальный DNS кеш и перезапустите сетевой стек. На Windows поможет последовательность команд в терминале с правами администратора:
ipconfig /flushdns
ipconfig /registerdns
netsh winsock reset
netsh int ip reset
На macOS выполните в Терминале:
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
На Linux проверяйте используемый резолвер. Для systemd подойдут команды:
resolvectl flush-caches
resolvectl status
Проверьте сам DNS ответ. На всех платформах подойдут nslookup и dig. Например:
nslookup example.com 1.1.1.1
dig +short A example.com @8.8.8.8
Если публичные резолверы возвращают IP, а ваша сеть упирается в ошибку, значит виноват локальный DNS. Если никто IP не возвращает, проблема у домена. В первом случае меняем DNS и чистим кеш. Во втором ждем исправлений у владельца сайта или пишем им в поддержку.
Чиним на практике
Самый быстрый способ обойти капризный резолвер это временно переключить DNS на публичные сервера. Ниже список популярных провайдеров и их адресов. Это официальные сервисы, они годятся как для теста, так и для постоянного использования. Если после переключения сайт оживает, значит вы нашли узкое место.
| Провайдер | Адреса IPv4 | Адреса IPv6 | Официальная страница |
|---|---|---|---|
| Google Public DNS | 8.8.8.8, 8.8.4.4 | 2001:4860:4860::8888, 2001:4860:4860::8844 | developers.google.com |
| Cloudflare | 1.1.1.1, 1.0.0.1 | 2606:4700:4700::1111, 2606:4700:4700::1001 | 1.1.1.1 |
| Quad9 | 9.9.9.9, 149.112.112.112 | 2620:fe::fe, 2620:fe::9 | quad9.net |
| OpenDNS Cisco | 208.67.222.222, 208.67.220.220 | 2620:0:ccc::2, 2620:0:ccd::2 | opendns.com |
Как переключить DNS на устройствах. На Windows зайдите в настройки сетевого адаптера, откройте свойства протокола IPv4, пропишите адреса из таблицы, затем при желании продублируйте для IPv6. После сохранения очистите кеш, перезапустите браузер. На macOS откройте Сеть, выберите активный интерфейс, нажмите Дополнительно, вкладка DNS, добавьте новые адреса, примените и переподключите сеть.
На Android можно включить Частный DNS и указать имя провайдера с поддержкой DoT. Для Cloudflare это 1dot1dot1dot1.cloudflare-dns.com, для Google это dns.google. В настройках Wi-Fi также можно прописать IPv4 адреса вручную для конкретной сети. На iOS меняется DNS на уровне конкретной Wi-Fi сети в ее параметрах, где есть поле DNS вручную. Если используете профиль VPN, проверьте, не подменяет ли он резолвер.
Хорошая привычка это обновить прошивку роутера и прописать на нем публичный DNS в разделе Интернет или WAN. Так вы сразу лечите все устройства дома. После изменения настроек перезагрузите роутер, чтобы сбросить кеш. Если в роутере включены семейные фильтры и категория «взрослых сайтов», они иногда срабатывают ложноположительно. Для диагностики лучше временно отключить.
Не забывайте про файл hosts. Если раньше вы «прибивали» домен к конкретному IP, а сайт переехал, браузер продолжит ходить по старому адресу. Уберите такую строку или закомментируйте. Это особенно часто встречается у разработчиков после тестов на локальном сервере.
Иногда помогает выключение «Безопасного DNS» в самом браузере или, наоборот, его включение. В Chrome это раздел «Использовать безопасный DNS», где можно выбрать провайдера. Для чистого эксперимента лучше синхронизировать выбор с системными настройками, чтобы не плодить неожиданные эффекты.
Редкие причины и как их распознать
Проблема может быть в доменной зоне. Если у домена включена DNSSEC, а подписи истекли, некоторые резолверы откажутся отвечать. Симптомы выглядят как обычный сбой, но публичные резолверы, которые строже к проверке, будут дружно возвращать пустоту. Здесь пользователь мало что сделает, остается ждать, пока владелец домена исправит подписи.
Смеcщение NS серверов у регистратора вызывает провал резолвинга. Когда NS указаны, но не делегированы правильно, часть мира видит домен, часть нет. Узнать такое можно, если сравнить ответы из разных регионов. Команды dig NS и dig @8.8.8.8 против @1.1.1.1 показывают картину. Обычно это чинится на стороне регистратора.
Есть еще задержки распространения записей. Администратор поменял A запись, но TTL был высоким, поэтому старые ответы задержались в кэше у провайдеров. В одной сети все уже открывается, в другой нет. Решение простое, подождать установленный TTL или перейти на другой резолвер на время.
Корпоративные сети часто используют split-DNS. Внутри компании домен имеет один IP, снаружи другой. Подключение к VPN отправляет запросы на внутренние серверы, отключение возвращает к внешним. Если в момент переключения что-то пошло не так, браузер видит ошибку. Переподключение к VPN и сброс кеша обычно возвращают все на место.
И наконец, то самое человеческое. Адрес может быть похожим на оригинал, но с заменой символов. Если видите в адресной строке странную запись в виде xn--, это punycode представление домена с национальными символами. Стоит вернуться на главную через поиск и убедиться, что вы на официальном сайте, а не на фишинговой копии. Подмена часто маскируется под ERR_NAME_NOT_RESOLVED, чтобы вы перешли по другой ссылке.
Профилактика и короткий чек-лист
Держите DNS под контролем. На домашнем роутере выберите надежного провайдера, обновляйте прошивку, периодически очищайте кеш через перезагрузку. На устройствах не смешивайте системный и браузерный безопасный DNS, иначе отлов проблем превращается в лотерею. Если работаете с сайтами и доменами, поддерживайте актуальные записи и следите за сроком регистрации.
Сохраняйте полезные инструменты под рукой. Команды nslookup и dig, проверка hosts, сброс кеша в системе, временная смена резолвера на публичный. Это простой набор, который закрывает 80 процентов случаев. Не злоупотребляйте десятью расширениями для блокировки рекламы и экспериментальными VPN, они тоже любят ломать разрешение имен.
Для родителей и корпоративных админов напоминание. Контент-фильтры способны резать честные домены вместе с сомнительными. Если пользователь жалуется на ERR_NAME_NOT_RESOLVED, а у вас включена категоризация, проверьте логи. Иногда достаточно переместить домен в белый список, и все заработает.
И напоследок. Если сайт важен, а доступ пропал везде, напишите владельцам через соцсети или почту из публичного профиля. У админа есть шанс не заметить проблему, пока об этом не скажут пользователи. Сообщение со скриншотом ошибки и парой выводов dig сильно ускоряет починку.
Сводка для тех, кто любит по делу. Проверяем адрес на опечатки, открываем в другой сети, чистим кеш, смотрим hosts, меняем DNS на публичный, тестируем nslookup. Если не помогло, вероятно, домен сломан на стороне владельца. В этом сценарии остается ждать или сообщить о сбое. Пугаться не нужно, проблема понятная и решаемая.
- Google Public DNS и Cloudflare подходят для быстрой проверки
- Файл hosts часто становится скрытой причиной
- VPN, фильтры и блокировщики рекламы влияют на разрешение имен
- TTL записей в DNS вызывает задержки распространения изменений
