ERR_NAME_NOT_RESOLVED: что делать с ошибкой резолва имени

ERR_NAME_NOT_RESOLVED — браузерная ошибка: браузер не смог преобразовать доменное имя в IP-адрес. Проще говоря, вы ввели example.com, но система не поняла, на какой сервер идти. До HTTP-запроса, TLS-рукопожатия и ответа приложения дело обычно даже не доходит.

Чаще всего эту ошибку видят в Chrome, Edge и других Chromium-браузерах. Технически проблема почти всегда находится в DNS: локальный кэш, DNS-сервер провайдера, записи домена, делегирование, VPN, прокси, корпоративный фильтр или недавно изменённые настройки зоны.

Для разработчика и владельца сайта эта ошибка неприятна тем, что выглядит как «сайт упал», хотя веб-сервер может быть полностью исправен. Поэтому диагностику стоит начинать не с Nginx и логов приложения, а с цепочки резолва имени.

Что означает ERR_NAME_NOT_RESOLVED

Когда браузер открывает сайт, он не подключается к домену напрямую. Ему нужен IP-адрес: например, 93.184.216.34 для IPv4 или адрес формата 2001:db8::... для IPv6. Получение IP по имени называется DNS-резолвом.

Ошибка ERR_NAME_NOT_RESOLVED появляется, когда этот резолв не удался. Возможные варианты:

1) Домен не существует — DNS-серверы вернули NXDOMAIN: такого имени нет. Это может быть опечатка в адресе, удалённый домен или неправильная запись.

2) Домен существует, но нужной записи нет — например, для www.example.com нет A или AAAA, хотя корневой example.com настроен.

3) DNS-сервер недоступен или не отвечает корректно — проблема у провайдера, в корпоративной сети, на VPN, в локальном роутере или на выбранном публичном резолвере.

4) Локальная система использует устаревший кэш — запись уже исправили, но браузер, ОС или промежуточный DNS-кэш всё ещё помнит старый ответ.

5) Резолв ломает фильтрация — антивирус, родительский контроль, корпоративный DNS, DNS-over-HTTPS, прокси или VPN могут подменять ответы.

Важно отличать эту ошибку от похожих. ERR_CONNECTION_REFUSED значит, что IP уже найден, но соединение отклонено. ERR_CONNECTION_TIMED_OUT — IP найден, но соединение не установилось за отведённое время. ERR_SSL_PROTOCOL_ERROR относится к TLS. А ERR_NAME_NOT_RESOLVED возникает раньше всех этих стадий: имя не превратилось в адрес.

Если нужно освежить базовую механику DNS, полезно отдельно разобрать материал как работает DNS: от запроса до IP-адреса.

Как браузер доходит до ошибки резолва имени

Ошибка кажется мгновенной, но перед ней проходит несколько проверок. Понимание порядка помогает быстрее найти источник.

1) Проверка синтаксиса адреса — браузер разбирает URL: схему https://, хост, порт, путь. Если вы ввели https://ex ample.com или домен с лишним символом, DNS-запрос может не сформироваться корректно.

2) Кэш браузера — Chrome хранит собственный DNS-кэш. Даже если ОС уже получила новый ответ, браузер может некоторое время использовать старый результат.

3) Кэш операционной системы — Windows, macOS и Linux могут кэшировать DNS-ответы на уровне системного резолвера. Иногда это systemd-resolved, иногда локальный DNS-клиент, иногда служба провайдера сети.

4) Файл hosts — запись в hosts имеет приоритет над DNS. Если там указано неправильное соответствие домена и IP, браузер даже не спросит внешние DNS-серверы.

Пути к файлу:

• Windows: C:\Windows\System32\drivers\etc\hosts
• Linux и macOS: /etc/hosts

5) Настроенный DNS-резолвер — это может быть DNS провайдера, роутера, корпоративного шлюза, публичный резолвер вроде 1.1.1.1 или 8.8.8.8, либо DNS-over-HTTPS в браузере.

6) Авторитетные DNS-серверы домена — если промежуточный резолвер не знает ответ, он доходит до NS-серверов домена. Именно там хранятся записи A, AAAA, CNAME, MX, TXT и другие.

Сбой возможен на любом участке. Поэтому фраза «у меня сайт не открывается» не всегда означает проблему с сервером — иногда сервер даже не получает попыток подключения.

Основные причины ERR_NAME_NOT_RESOLVED

Причины делятся на клиентские, сетевые и доменные: сначала стоит проверять то, что меняется за минуту, и только потом переходить к зоне DNS и делегированию.

1) Опечатка в домене — банально, но часто встречается. Лишняя точка, похожие символы, неправильная зона .ru вместо .com, перепутанный поддомен api/app — и браузер покажет ошибку резолва.

2) Нет записи для поддомена — сайт может открываться как example.com, но не открываться как www.example.com, или наоборот. Для браузера это разные имена, и каждое должно резолвиться отдельно.

3) Неправильный CNAME — поддомен указывает на другое имя, а то имя не существует или тоже настроено неверно. В итоге цепочка CNAME обрывается.

4) Удалили или не создали A/AAAA — после миграции хостинга, переезда на CDN или изменения панели DNS запись могла исчезнуть. Особенно часто это происходит при переносе домена между регистраторами и DNS-провайдерами.

5) Ошибка в NS-серверах — домен делегирован на одни NS, а записи редактируются в другой панели. Владелец меняет зону, но интернет смотрит в старое место.

6) Задержка распространения DNS — после изменения записей часть резолверов уже видит новый IP, часть — старый ответ или отсутствие записи. Это связано с TTL и кэшированием. Подробнее о таких задержках — в статье про DNS caching и странные задержки.

7) Проблема DNS у провайдера или роутера — интернет работает, мессенджеры открываются, но часть сайтов не резолвится. Часто помогает временно сменить DNS на публичный.

8) VPN, прокси, антивирус или корпоративная сеть — такие инструменты могут перехватывать DNS-запросы. Иногда они блокируют домен, иногда ломают DNS-over-HTTPS, иногда возвращают внутренние адреса, недоступные вне сети.

9) DNSSEC или регистраторские ограничения — если DNSSEC настроен неправильно, валидирующие резолверы могут отказывать в ответе. Если домен просрочен, заблокирован или находится в переходном состоянии, делегирование тоже может нарушиться.

10) Локальный hosts или кэш — старая запись в hosts, некорректный локальный DNS-кэш, тестовый домен после разработки — типичный источник «работает у всех, кроме меня».

Быстрые действия для пользователя

Если ошибка появилась у вас как у пользователя, не начинайте со сложных команд — сначала исключите локальные и сетевые причины.

1) Проверьте адрес — скопируйте домен без пути и параметров: example.com. Попробуйте варианты с www и без него. Если ошибка возникает только на одном варианте, вероятно, не настроен нужный поддомен.

2) Откройте сайт в другом браузере — если в Chrome ошибка есть, а в Firefox сайт открывается, проблема может быть в DNS-кэше браузера или настройках DNS-over-HTTPS.

3) Проверьте другое устройство и сеть — откройте сайт с телефона через мобильный интернет. Если там всё работает, причина, скорее всего, в вашем роутере, провайдере, VPN или локальном кэше.

4) Отключите VPN и прокси — особенно если проблема касается корпоративных или регионально ограниченных ресурсов. VPN может отправлять DNS-запросы на свои резолверы.

5) Временно смените DNS — можно указать публичные DNS-серверы, например 1.1.1.1 и 1.0.0.1 или 8.8.8.8 и 8.8.4.4. После смены лучше очистить кэш DNS.

6) Очистите DNS-кэш — команды зависят от ОС.

Windows:

ipconfig /flushdns

macOS:

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

Linux с systemd-resolved:

sudo resolvectl flush-caches

Chrome также имеет внутреннюю страницу chrome://net-internals/#dns, где можно очистить host cache. В новых версиях интерфейс может меняться, но идея та же: сбросить DNS-кэш браузера.

7) Перезагрузите роутер — домашний роутер часто выступает локальным DNS-прокси. Если он закэшировал неправильный ответ или завис, перезагрузка может решить проблему.

Если не открывается не один сайт, а сразу многие, это уже не частный сбой домена. Для такого сценария подходит отдельный разбор: интернет работает, а сайты не открываются.

Как диагностировать ошибку через командную строку

Для разработчика или администратора главный инструмент — сравнить ответы разных резолверов и понять, где именно ломается цепочка.

1) Проверить системный резолв — начните с того, что видит ваша ОС.

nslookup example.com

или:

dig example.com

Если команда возвращает IP, а браузер всё равно показывает ERR_NAME_NOT_RESOLVED, смотрите кэш браузера, DNS-over-HTTPS, прокси и расширения.

2) Сравнить ответы публичных DNS — полезно проверить несколько независимых резолверов:

dig example.com @1.1.1.1
dig example.com @8.8.8.8
dig example.com @9.9.9.9

Если один резолвер видит запись, а другой — нет, вероятны кэширование, задержка распространения DNS или проблемы в делегировании.

3) Проверить конкретный тип записи — для сайта обычно нужны A и/или AAAA.

dig A example.com
dig AAAA example.com
dig CNAME www.example.com

Если IPv4 есть, а IPv6-запись AAAA указывает неверно, часть клиентов может получать ошибку или зависание при подключении. Не всегда это проявляется именно как ERR_NAME_NOT_RESOLVED, но проверять стоит.

4) Посмотреть авторитетные NS-серверы:

dig NS example.com

Затем спросите один из NS напрямую:

dig example.com @ns1.example-dns.com

Так вы поймёте, что реально хранится в авторитетной зоне, без влияния кэша провайдера.

5) Проверить трассировку DNS:

dig +trace example.com

Команда показывает путь от корневых серверов к зоне верхнего уровня и дальше к авторитетным NS. Это помогает найти сломанную делегацию, неправильные NS или отсутствие ответа на одном из уровней.

6) Проверить DNSSEC — если домен использует DNSSEC, ошибки подписи могут приводить к отказу у валидирующих резолверов:

dig example.com +dnssec

Если один валидирующий DNS возвращает ошибку, а невалидирующий отвечает, стоит проверить DS-записи у регистратора и подписи зоны.

Подробнее работу с dig, типами записей и интерпретацией ответов мы разбирали в материале «Утилита dig: как проверить DNS-записи и отладить домен».

Что делать владельцу сайта или DevOps-инженеру

Если пользователи жалуются на ERR_NAME_NOT_RESOLVED, а у вас сайт открывается, не закрывайте инцидент фразой «у меня работает». DNS-проблемы часто проявляются неравномерно: по регионам, провайдерам, резолверам и типам клиентов.

1) Проверьте домен и поддомены — отдельно проверьте:

• example.com
• www.example.com
• api.example.com
• cdn.example.com
• домены внешних ресурсов, если страница зависит от них

Ошибка на api.example.com может ломать приложение, даже если главная страница открывается.

2) Сравните авторитетную зону и панель управления — убедитесь, что вы редактируете DNS именно там, куда делегирован домен. Частая ситуация: домен делегирован на Cloudflare, а записи меняют в панели регистратора. Изменения выглядят сохранёнными, но не применяются в интернете.

3) Проверьте A, AAAA и CNAME — для корневого домена обычно нужна A-запись. Для www часто используют CNAME на корневой домен или на адрес CDN. Следите, чтобы CNAME не указывал на несуществующее имя.

4) Не ставьте слишком маленький TTL без причины — низкий TTL полезен перед миграцией, но постоянное значение в несколько секунд увеличивает нагрузку на DNS и делает поведение менее предсказуемым при сбоях. Перед переездом на новый IP уменьшите TTL заранее, после стабилизации верните разумное значение.

5) Проверяйте оба стека: IPv4 и IPv6 — если добавили AAAA, убедитесь, что сервер действительно доступен по IPv6. Некорректная IPv6-настройка может создавать странные ошибки у части клиентов.

6) Следите за сроком домена — просроченный домен может уйти на парковочные NS, перестать резолвиться или начать отдавать чужие записи. Это уже не проблема веб-сервера, но для пользователя выглядит как недоступность сайта.

7) Осторожно включайте DNSSEC — ошибка в DS-записи или подписи зоны может сделать домен недоступным для части резолверов. Проверяйте DNSSEC сразу после изменения у регистратора.

8) Учитывайте CDN и внешние DNS-провайдеры — при использовании CDN ошибка может быть не в вашем сервере, а в записи, указывающей на CDN, или в зоне, которой управляет CDN. Проверьте статус внешнего провайдера и актуальность целевых хостов.

9) Проверьте split-horizon DNS — в компаниях один и тот же домен может резолвиться по-разному внутри VPN и снаружи. Если внешний пользователь видит ERR_NAME_NOT_RESOLVED, а внутри офиса всё работает, проверьте публичную зону отдельно.

10) Зафиксируйте результат из разных точек — сохраняйте вывод dig, время проверки, резолвер, регион пользователя и точный домен. Это ускоряет разбор и помогает отличить реальный сбой от локального кэша.

Для общей диагностики недоступности полезен чеклист «Не открывается сайт»: там проблема рассматривается шире — от DNS до HTTP-ответов и сетевых ошибок.

Чем ERR_NAME_NOT_RESOLVED отличается от DNS_PROBE_FINISHED_NXDOMAIN

Ошибки похожи, но не всегда означают одно и то же.

DNS_PROBE_FINISHED_NXDOMAIN обычно указывает на более конкретный результат: DNS-запрос завершился ответом NXDOMAIN, то есть имя не найдено. Например, домен не зарегистрирован, поддомен не создан или есть опечатка.

ERR_NAME_NOT_RESOLVED — более общий сигнал. Он может появиться не только при NXDOMAIN, но и при сбое резолвера, проблеме кэша, блокировке, настройках браузера, VPN или DNS-over-HTTPS. В интерфейсе браузера пользователь видит примерно одно и то же: сайт не открывается, имя не удалось разрешить.

На практике это означает следующее:

1) Если dig возвращает NXDOMAIN — ищите проблему в домене, поддомене, зоне DNS или делегировании.

2) Если dig возвращает IP, а браузер показывает ошибку — вероятнее локальный кэш, DoH, прокси, расширение, антивирус или профиль браузера.

3) Если разные DNS дают разные ответы — смотрите TTL, недавние изменения зоны, DNSSEC, NS-серверы и кэширование.

4) Если ошибка только в одной сети — проверьте DNS провайдера, роутер, корпоративные фильтры, VPN и локальные политики безопасности.

Отдельно про NXDOMAIN и типовые способы исправления есть материал DNS_PROBE_FINISHED_NXDOMAIN: как исправить.

Как предотвратить повторение проблемы

DNS редко меняется каждый день, поэтому его легко забыть после первичной настройки. Но именно DNS становится критичной точкой при переезде сайта, подключении CDN, смене регистратора, выпуске новых поддоменов и настройке инфраструктуры.

1) Ведите DNS как инфраструктуру — храните список доменов, поддоменов, владельцев, назначение записей, TTL, DNS-провайдера и дату последнего изменения. Для больших проектов DNS-зону лучше описывать в IaC-инструментах, чтобы изменения проходили ревью.

2) Проверяйте DNS после деплоя — если новый сервис доступен как api.example.com, проверяйте не только HTTP health check, но и сам факт резолва имени. Иначе приложение может быть живым, но недоступным для клиентов.

3) Не смешивайте зоны без документации — регистратор, DNS-хостинг, CDN и облачный провайдер могут предлагать свои панели DNS. У команды должно быть чёткое понимание, где именно авторитетная зона.

4) Настройте мониторинг доступности — внешний мониторинг помогает поймать ситуацию, когда домен перестал резолвиться у независимой точки проверки. Statuser, например, проверяет сайт с заданным интервалом и присылает уведомление о сбое. Это не заменяет полноценный DNS-аудит, но сокращает время между проблемой и реакцией.

5) Мониторьте не только главную страницу — если критичны api, auth, cdn, static, проверяйте их отдельно. Ошибка резолва на API может быть не видна при простой проверке /, но сломает вход, оплату или загрузку интерфейса.

6) Снижайте шум в алертах — DNS-сбои могут быть кратковременными или локальными. Чтобы не получить alert fatigue, задавайте разумный интервал проверки, несколько попыток перед алертом и разные каналы уведомлений. В Statuser для таких сценариев удобно подбирать интервал под критичность сервиса: чем выше цена простоя, тем чаще проверка. Подробнее о подходе — в статье как выбрать интервал проверки сайта.

7) Делайте постмортем DNS-инцидентов — фиксируйте, что именно сломалось: запись, NS, DNSSEC, кэш, регистратор, CDN, человеческая ошибка. После этого добавляйте проверку в чеклист релиза или мониторинг.

DNS-проблемы часто выглядят мелкими, пока не затрагивают продакшен. Но для пользователя нет разницы, упал ли сервер, истёк сертификат или домен не резолвится: сайт недоступен. Поэтому DNS должен быть частью эксплуатационного контура, а не настройкой «один раз при запуске».

FAQ

Что значит ERR_NAME_NOT_RESOLVED?
Браузер не смог преобразовать доменное имя в IP-адрес. Обычно причина в DNS: записи домена, кэш, DNS-сервер, VPN, прокси или локальные настройки.

Почему сайт открывается у меня, но не открывается у пользователей?
DNS-ответы могут отличаться у разных провайдеров и резолверов. Также влияет кэш, регион, VPN, корпоративная сеть и время после изменения записей.

Как быстро проверить, проблема в DNS или в сервере?
Выполните dig example.com или nslookup example.com. Если IP не возвращается, разбирайте DNS. Если IP есть, проверяйте соединение, HTTP, TLS и сервер.

Поможет ли очистка кэша DNS?
Да, если проблема в устаревшем локальном ответе. Но если запись неверна на авторитетных DNS-серверах домена, очистка кэша не исправит саму причину.