ERR_NAME_NOT_RESOLVED: что означает и как исправить

2026-09-19

ERR_NAME_NOT_RESOLVED означает, что браузер запросил у DNS-резолвера IP-адрес сайта и не получил в ответ ничего пригодного. Это может означать, что резолвер вернул пустоту, истек по таймауту, либо вернул ответ, который браузер отклонил, - это более широкое условие, чем просто "этого домена не существует".

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

Прежде чем браузер сможет к чему-либо подключиться, он превращает имя хоста в IP-адрес через DNS. ERR_NAME_NOT_RESOLVED - это универсальная ошибка Chrome для провала такого поиска каким-либо способом, отличным от подтвержденного "имя не существует": резолвер не ответил вовремя, вернул пустой или некорректный ответ, либо собственный сетевой стек браузера вообще не смог дозвониться ни до какого резолвера.

Это легко перепутать с DNS_PROBE_FINISHED_NXDOMAIN, которая является более узким, конкретным случаем. NXDOMAIN означает, что резолвер дал четкий ответ: этого имени не существует в зоне. ERR_NAME_NOT_RESOLVED означает, что сам поиск провалился либо вернулся вообще ни с чем пригодным, что включает сломанный резолвер, таймаут, сеть без какого-либо доступа к DNS вообще, либо неудачно сработавшую локальную подмену DNS. Если вы уже знаете, что домен раньше работал и в самом домене ничего не менялось, ERR_NAME_NOT_RESOLVED скорее указывает на путь разрешения, чем на собственные записи домена.

Как проявляется ошибка

Chrome и Edge показывают "This site can't be reached - example.com's server IP address could not be found. Try running Windows Network Diagnostics." с кодом ERR_NAME_NOT_RESOLVED. Firefox показывает "Hmm. We're having trouble finding that site" с сообщением "we can't connect to the server at example.com".

dig показывает, что возвращает конкретный резолвер, а +trace проходит всю цепочку от корня вниз:

dig example.com A
;; ANSWER SECTION:
example.com.  300  IN  A  203.0.113.10

dig +trace example.com
; <<>> DiG 9.18 <<>> +trace example.com
.  518400  IN  NS  a.root-servers.net.
...
com.  172800  IN  NS  a.gtld-servers.net.
...
example.com.  300  IN  A  203.0.113.10

nslookup - более быстрая проверка на здравый смысл, когда нужен просто ответ да или нет:

nslookup example.com
Server:   8.8.8.8
Address:  8.8.8.8#53

Name:     example.com
Address:  203.0.113.10

Если любая из этих команд выходит по таймауту, возвращает SERVFAIL либо ничего не возвращает в ANSWER SECTION, поиск действительно провалился - в отличие от ответа NXDOMAIN, который прямо сказал бы "такого имени нет".

Что вызывает ERR_NAME_NOT_RESOLVED

Отсутствующая запись A или AAAA. Домен разрешается для других типов записей, либо зона существует, но для запрашиваемого имени хоста не опубликовано записи адреса (включая отсутствующую запись для конкретного поддомена, даже когда корневой домен работает).
Истекшая регистрация домена. После истечения срока действия домена его серверы имен обычно вообще перестают отвечать за него, что дает именно этот сбой, а не чистый NXDOMAIN.
Сбой или неверная настройка сервера имен. Если авторитетные серверы имен домена недоступны или возвращают некорректные ответы, каждый резолвер, пытающийся ответить за этот домен, проваливается одинаково.
Провал проверки DNSSEC. Валидирующий резолвер, который не может проверить подпись DNSSEC (истекшая подпись, сломанная цепочка доверия), вообще отказывается возвращать ответ, вместо того чтобы вернуть тот, которому не может доверять.
Собственный резолвер посетителя недоступен или не отвечает, что часто случается при сломанном VPN, captive-портале Wi-Fi либо неправильно настроенном маршрутизаторе, указывающем на DNS-сервер, которого больше не существует.
Поврежденный локальный кэш DNS на машине посетителя, хранящий устаревшую или сломанную запись со времен до того, как домен был настроен правильно.

Как понять, кто виноват

Запросите публичный резолвер напрямую, например dig example.com @8.8.8.8, минуя то, что настроено использовать в локальной сети. Если это тоже проваливается, проблема - в собственной настройке DNS домена, а не в сети посетителя. DNS-поиск, запущенный из нескольких мест, сразу проясняет это: стабильный сбой повсюду указывает на серверы имен или регистрацию домена, тогда как сбой только из одного места или резолвера указывает на что-то локальное для именно этой точки обзора.

Как исправить ERR_NAME_NOT_RESOLVED

Если вы посетитель

Сбросьте локальный кэш DNS. В Windows: ipconfig /flushdns. В macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. В Linux с systemd-resolved: sudo resolvectl flush-caches.
Переключитесь на публичный DNS-резолвер, такой как 8.8.8.8 или 1.1.1.1, в настройках сети, временно заменив то, что по умолчанию предоставляет ваш провайдер или маршрутизатор.
Проверьте файл hosts (/etc/hosts в macOS/Linux, C:\Windows\System32\drivers\etc\hosts в Windows) на предмет устаревшей ручной записи, переопределяющей домен.
Отключитесь от VPN и повторите попытку; некоторые VPN-клиенты направляют DNS через резолвер, который сам недоступен или неправильно настроен.
Перезапустите маршрутизатор, если разрешение проваливается для каждого сайта в сети, а не только для одного.

Если вы администрируете сайт

Убедитесь, что запись A/AAAA существует для точного имени хоста, которое используют посетители, включая любой поддомен: dig www.example.com A и dig example.com A - это два отдельных поиска.
Проверьте статус регистрации домена и срок ее действия у своего регистратора; неожиданно истекший домен - частая и легко упускаемая из виду причина.
Убедитесь, что серверы имен, указанные у регистратора, совпадают с теми, что действительно обслуживают зону, и что они отвечают: dig NS example.com, а затем прямой запрос к каждому возвращенному серверу имен.
Если используется DNSSEC, проверьте цепочку командой dig +dnssec example.com и проверьте, не истекла ли запись RRSIG, - частая и самостоятельно вызванная причина сбоев разрешения.
Запустите dig +trace, чтобы увидеть точно, в каком месте цепочки от корня до авторитетного сервера ломается разрешение, вместо того чтобы гадать.

Как предотвратить ERR_NAME_NOT_RESOLVED

Сбои DNS легко упустить изнутри, поскольку стабильная офисная сеть с ее закэшированными записями может продолжать работать еще долго после того, как посетители в других местах начинают получать сбой. DNS-проверка, запускаемая из 300+ контрольных точек в 158 городах, ловит сбой сервера имен, истекающую регистрацию или сломанную запись в момент, когда это начинает влиять на разрешение, а не после того, как заполнится ящик поддержки. HostTracker мониторит сайты с 2004 года и оповещает по email, SMS, голосовым звонком, через Slack, Telegram и другие каналы.

Часто задаваемые вопросы

В чем разница между ERR_NAME_NOT_RESOLVED и DNS_PROBE_FINISHED_NXDOMAIN?

NXDOMAIN - это однозначный ответ: резолвер проверил, и имени не существует в зоне. ERR_NAME_NOT_RESOLVED шире и охватывает поиск, который провалился, вышел по таймауту либо вернул вообще ничего пригодного, включая случаи, когда домен на самом деле существует, но его серверы имен недоступны.

Может ли истекший домен вызвать эту ошибку?

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

Почему сайт работает на мобильном интернете моего телефона, но не в домашнем Wi-Fi?

Это указывает на резолвер, который использует ваша домашняя сеть, - либо настроенный DNS-сервер маршрутизатора, либо резолвер провайдера. Переключение на публичный резолвер вроде 1.1.1.1 в затронутой сети обычно и подтверждает, и исправляет проблему.

Я только что добавил новый поддомен, и он не разрешается. Почему?

Новая запись должна распространиться по кэшам DNS после создания, а также должна на самом деле существовать: сначала убедитесь командой dig subdomain.example.com A напрямую к авторитетному серверу имен, прежде чем предполагать, что дело только в задержке распространения.

Может ли DNSSEC вообще вызвать эту ошибку на домене, который в остальном в порядке?

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