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

Коротко: DNS_PROBE_FINISHED_NXDOMAIN значит, что Chrome не смог получить IP-адрес сайта по его имени, а дополнительная проверка показала, что сам ваш DNS-сервер работает. Значит, дело в этом конкретном имени: опечатка, незарегистрированный или просроченный домен, имя без DNS-записи или фильтр, который его блокирует. NXDOMAIN расшифровывается как Non-Existent Domain, «несуществующий домен».

В русском Chrome страница озаглавлена Не удается получить доступ к сайту и предлагает Проверьте, нет ли опечаток в имени хоста example.com. (в английском интерфейсе — This site can’t be reached). ERR_NAME_NOT_RESOLVED со строкой Не удалось найти IP-адрес сервера example.com. (…’s server IP address could not be found) — та же ошибка, просто Chrome не провёл эту проверку или не получил от неё ясного ответа.

Сюда попадают читатели двух типов. Не открывается чужой сайт? Переходите к решениям для посетителей, они идут от самого вероятного к менее вероятному. Ошибку выдаёт ваш собственный домен? Вам в раздел для владельцев сайтов: он начинается с одной команды dig и таблицы, которая объясняет, что значит её ответ.

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

NXDOMAIN — это код ответа DNS «такого имени не существует». Ошибка Chrome шире своего названия. Его резолвер сообщает о любой неудачной попытке разрешить имя одной и той же ошибкой, ERR_NAME_NOT_RESOLVED: не существует ли имя, отказал ли сервер или истекло время ожидания. Затем Chrome запускает проверку (probe): разрешает google.com один раз через текущие настройки DNS и один раз через Google Public DNS (8.8.8.8 и 8.8.4.4) и по двум результатам выбирает страницу ошибки. Пока проверка идёт, на странице может мелькнуть Не удается найти DNS-адрес сайта example.com. Выполняется диагностика. Логику выбора мы прочитали в исходном коде Chromium (dns_probe_service_factory.cc):

Для владельцев сайтов отсюда важное следствие: страница не доказывает, что DNS ответил именно NXDOMAIN. Домен со сломанным DNSSEC возвращает SERVFAIL, проверка всё равно находит ваш резолвер исправным, и Chrome показывает ту же страницу NXDOMAIN. Edge, Opera и Яндекс Браузер построены на Chromium и выдают те же коды ошибок. Firefox пишет Хмм. Нам не удаётся найти этот сайт. (в английской версии — Hmm. We’re having trouble finding that site.).

Что делать посетителю: сначала самое вероятное

1. 1Проверьте адрес, потом попробуйте другую сеть

   Чаще всего имя набрано с ошибкой или потеряно www. Затем откройте тот же адрес на телефоне через мобильный интернет, а не по Wi-Fi. Если не открывается и там, а наш DNS Lookup (англ.), который опрашивает наш резолвер в Амстердаме, тоже не находит для имени записей A или AAAA, сломан или исчез сам домен. На вашем компьютере это не исправить: починить может только владелец.

2. 2Спросите публичный резолвер напрямую

   Так вы узнаете, не в вашем ли резолвере дело. Команда одинаково работает в cmd и PowerShell в Windows, в Терминале macOS и в Linux, где на минимальных установках сначала нужен пакет bind9-dnsutils или bind-utils. Замените www.example.com адресом, который не открывается:

   nslookup www.example.com 1.1.1.1

   Если в ответе есть адреса, а браузер всё равно выдаёт ошибку, имя существует, и прячет его что-то на вашей стороне: кеш, фильтр или резолвер, которым пользуется устройство. Ответ ** server can't find …: NXDOMAIN от 1.1.1.1 (в Windows: Non-existent domain; в русской Windows начало строки переведено — *** … не удалось найти …: Non-existent domain) значит, что имя действительно нигде не разрешается. Если домен ваш, переходите к разделу для владельцев.

3. 3Очистите собственный DNS-кеш Chrome

   У Chrome есть свой кеш имён. Откройте chrome://net-internals/#dns и нажмите Clear host cache, затем на chrome://net-internals/#sockets нажмите Flush socket pools и перезагрузите страницу. Эти служебные страницы не переведены, поэтому кнопки и в русском Chrome называются по-английски. На странице DNS есть и поле для запроса: оно показывает, что разрешает сам Chrome, а это может отличаться от ответа nslookup, если включён безопасный DNS (шаг 7).

4. 4Очистите DNS-кеш операционной системы

   ipconfig /flushdns

   sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

   sudo resolvectl flush-caches

   Русская Windows ответит Кэш сопоставителя DNS успешно очищен. Чистая установка Debian 12 или 13 не держит локального DNS-кеша, так что очищать нечего, если вы сами не поставили nscd, dnsmasq или unbound; если resolvectl status отвечает, значит, systemd-resolved запущен и команда выше подходит. Старые инструкции советуют перезапустить службу DNS-клиента командой net stop dnscache; современные Windows 10 и 11 не дают остановить эту службу, а очистка кеша делает ту же работу. Если устройство использует роутер как DNS-сервер, роутер тоже кеширует ответы: перезагрузите его или обойдите, как в шаге 5.

5. 5Переключитесь на публичный резолвер

   Если на шаге 2 1.1.1.1 ответил, а ваш резолвер по умолчанию — нет, пропишите на устройстве два публичных резолвера без фильтрации от разных операторов. В PowerShell от имени администратора замените Ethernet на имя подключения из вывода Get-NetAdapter:

   Set-DnsClientServerAddress -InterfaceAlias 'Ethernet' -ServerAddresses ('1.1.1.1','8.8.8.8')

   networksetup -setdnsservers Wi-Fi 1.1.1.1 8.8.8.8

   В macOS команда networksetup -listallnetworkservices покажет названия служб, если ваша называется не Wi-Fi. Чтобы вернуть серверы, которые раздаёт DHCP, выполните Set-DnsClientServerAddress -InterfaceAlias 'Ethernet' -ResetServerAddresses в Windows или networksetup -setdnsservers Wi-Fi empty в macOS. Вместо одного из этих двух подойдёт и Яндекс DNS в базовом режиме (77.88.8.8 или 77.88.8.1); режимы «Безопасный» и «Семейный» фильтруют сайты, поэтому для проверки не годятся. В Linux место настройки зависит от дистрибутива; статья Temporary failure in name resolution (англ.) разбирает systemd-resolved, netplan и /etc/resolv.conf.

6. 6Отключите VPN, блокировщик рекламы или фильтрующий DNS

   DNS-фильтры отвечают на заблокированное имя либо NXDOMAIN, либо нулевым адресом. Pi-hole делает первое в режиме блокировки NXDOMAIN, а 9.9.9.9 от Quad9 — для доменов из своих списков угроз. В заблокированном ответе обычно нет записи SOA в секции authority, а резолверы с поддержкой Extended DNS Errors (RFC 8914) добавляют код с причиной. Так Quad9 отвечает на собственный тестовый домен:

   ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 16136
   ;; flags: qr rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
   ; EDE: 17 (Filtered)

   У имени, которого действительно нет, в секции authority стоит SOA зоны (см. раздел для владельцев). Полностью отключите VPN, поставьте блокировщик на паузу или для сравнения спросите резолвер без фильтрации, например 9.9.9.10.

7. 7Проверьте безопасный DNS в Chrome и Яндекс Браузере

   В разделе Настройки → Конфиденциальность и безопасность → Безопасность → Использовать безопасный DNS-сервер (в английском интерфейсе Settings → Privacy and security → Security → Use secure DNS) Chrome может отправлять запросы выбранному поставщику по HTTPS в обход системного резолвера. Тогда nslookup может отвечать, а Chrome — нет, или наоборот. Выберите вариант Использовать поставщика по умолчанию (если задан на уровне ОС) или выключите переключатель и перезагрузите страницу. В управляемом браузере, например на рабочем компьютере, настройка заблокирована. В Яндекс Браузере справка советует то же: на странице browser://protect отключить «Использовать безопасный DNS-сервер», а если не поможет — включить снова и выбрать другой сервер.

8. 8На телефоне проверьте частный DNS и профили

   Настройка Android «Частный DNS-сервер» (Настройки → Сеть и интернет; в справке Google встречается и название «Персональный DNS-сервер») и DNS- или VPN-профили в iOS («Настройки» → «Основные» → «VPN и управление устройством») подменяют резолвер сети, и некоторые из них фильтруют. Отключите настройку на время проверки или удалите профиль, включите и выключите авиарежим и перезагрузите страницу.

Ошибку выдаёт ваш домен: проверки для владельца сайта

Проверяйте снаружи, в обход своей сети и своих кешей. Спросите публичный резолвер о точном имени, которое набирают посетители, и о домене без www. Замените example.com своим доменом:

dig @1.1.1.1 www.example.com
dig @1.1.1.1 example.com

В Windows то же самое делает Resolve-DnsName www.example.com -Server 1.1.1.1. Нет dig? Наш DNS Lookup (англ.) покажет статус и записи от нашего резолвера. Смотрите на две части ответа: status в заголовке и AUTHORITY SECTION. Запись SOA там называет зону, которая ответила «нет».

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 31239
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;no-such-host.vmheaven.io.      IN      A

;; AUTHORITY SECTION:
vmheaven.io.    1800    IN      SOA     aisha.ns.cloudflare.com. dns.cloudflare.com. 2415933946 10000 2400 604800 1800

Зона vmheaven.io ответила сама за себя: домен работает, а у этого имени хоста записей нет. Сравните с доменом, который вообще не зарегистрирован. Здесь отвечает реестр .com:

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 14341
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; AUTHORITY SECTION:
com.            900     IN      SOA     a.gtld-servers.net. nstld.verisign-grs.com. 1791728479 1800 900 604800 900

Для незарегистрированного домена в зоне .ru ответ выглядит так же, только «нет» говорит зона ru:

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 11849
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; AUTHORITY SECTION:
ru.                     3600    IN      SOA     a.dns.ripn.net. hostmaster.ripn.net. 4070696 86400 14400 2592000 3600

Домен не зарегистрирован, просрочен или без DNS-серверов

SOA зоны верхнего уровня значит, что в реестре нет делегирования вашего домена. Проверьте регистрацию через WHOIS Lookup (англ.), который спрашивает реестр по RDAP, или командой whois:

whois example.com | grep -iE 'expiry date|domain status|name server|dnssec'

   Registry Expiry Date: 2027-08-13T04:00:00Z
   Domain Status: clientDeleteProhibited https://icann.org/epp#clientDeleteProhibited
   Name Server: ELLIOTT.NS.CLOUDFLARE.COM
   Name Server: HERA.NS.CLOUDFLARE.COM
   DNSSEC: signedDelegation

По списку статусов EPP от ICANN три статуса убирают домен из DNS: clientHold (ставит регистратор, например после пропущенного продления или неподтверждённого e-mail владельца), serverHold (ставит реестр) и inactive (к домену не привязаны DNS-серверы). No match for domain значит, что домен не зарегистрирован вовсе. Продлите его, подтвердите e-mail или укажите DNS-серверы у регистратора. Некоторых национальных зон, среди них .io, .de, .ru и .рф, нет в каталоге RDAP у IANA, поэтому их проверяйте командой whois или на сайте реестра.

У доменов .ru, .рф и .su статусов EPP в выводе нет, вместо них строка state. Так выглядит работающий домен:

whois example.ru | grep -iE 'state|paid-till|free-date|nserver'

nserver:       ns1.yandex.ru. 213.180.193.1, 2a02:6b8::1
nserver:       ns2.yandex.ru. 93.158.134.1, 2a02:6b8:0:1::1
state:         REGISTERED, DELEGATED, VERIFIED
paid-till:     2027-09-30T21:00:00Z
free-date:     2027-11-01

DELEGATED значит, что для домена указаны DNS-серверы и он есть в зоне. NOT DELEGATED — домен зарегистрирован, но в DNS его нет: серверы не указаны или делегирование приостановлено. Так бывает и после даты paid-till: когда срок регистрации заканчивается, сайт и почта перестают работать, а продлить домен его администратор может ещё 30 дней, до free-date. На незарегистрированный домен whois ответит No entries found for the selected source(s).

DNS-серверы не обслуживают вашу зону

Записи действуют только у того провайдера, на которого делегирован домен. Если вы правите записи у провайдера A, а у регистратора по-прежнему указаны DNS-серверы провайдера B, этих записей никто не увидит. dig +trace проходит по цепочке делегирования от корня вниз и показывает, какой сервер отвечает на каждом шаге:

dig +short NS example.com @1.1.1.1
dig +trace +nodnssec www.example.com

io.             172800  IN      NS      a0.nic.io.
io.             172800  IN      NS      b0.nic.io.
;; Received 301 bytes from 198.41.0.4#53(a.root-servers.net) in 15 ms

vmheaven.io.    3600    IN      NS      dimitris.ns.cloudflare.com.
vmheaven.io.    3600    IN      NS      aisha.ns.cloudflare.com.
;; Received 113 bytes from 65.22.161.17#53(b0.nic.io) in 7 ms

vmheaven.io.    1800    IN      SOA     aisha.ns.cloudflare.com. dns.cloudflare.com. 2415933946 10000 2400 604800 1800
;; Received 116 bytes from 108.162.195.6#53(dimitris.ns.cloudflare.com) in 55 ms

Строку со статусом +trace не выводит. Последний шаг, на котором пришла только запись SOA, и есть отрицательный ответ, а строка под ним называет сервер, который его дал. Затем спросите каждый DNS-сервер напрямую, без рекурсии. Замените NS1.YOUR-DNS-PROVIDER.TLD именем из ответа NS:

dig +norec www.example.com @NS1.YOUR-DNS-PROVIDER.TLD

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

;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 40905
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
; EDE: 20 (Not Authoritative)

Публичные резолверы превращают такой отказ в SERVFAIL для ваших посетителей. Исправляйте на той стороне, где ошибка: укажите у регистратора DNS-серверы провайдера, у которого лежат ваши записи, или создайте зону у провайдера, которого назвал регистратор. Некоторые сети не выпускают DNS-запросы никуда, кроме своего резолвера, и тогда +trace зависнет по таймауту. Ключ +tcp помогает, если фильтруется только UDP; в остальных случаях проверяйте снаружи через DNS Lookup (англ.).

У этого имени нет записи (www и домен без www)

Автоматического www в DNS нет. example.com и www.example.com — разные имена, и каждому нужна своя запись:

dig +short A example.com @1.1.1.1
dig +short A www.example.com @1.1.1.1
dig +short AAAA www.example.com @1.1.1.1

Пустая строка для одного из них и есть ответ. Дайте каждому имени запись A с IPv4-адресом сервера, запись AAAA, если у сервера есть IPv6, или сделайте www записью CNAME на домен без www; набор записей есть в статье Point a domain to your VPS (англ.). Следите за «висячими» CNAME: если www указывает на имя, которого больше нет, например на приложение, удалённое на какой-нибудь платформе, ответ покажет CNAME и всё равно закончится NXDOMAIN, потому что статус всегда описывает конец цепочки (RFC 6604).

Запись добавлена, а NXDOMAIN не уходит

Резолверы кешируют и «не существует». По RFC 2308 резолвер может хранить NXDOMAIN столько, сколько меньшее из двух чисел в пришедшей с ним записи SOA: её TTL и последнее поле, minimum. В выводе для vmheaven.io выше оба равны 1800, так что резолвер, который спросил до создания записи, может повторять «не существует» до 30 минут. Для только что зарегистрированного домена .com действует значение реестра, 900 секунд, для .ru — 3600 секунд, то есть час: столько сейчас стоит в SOA зоны ru (вывод выше).

• Убедитесь, что запись уже есть на авторитетном сервере, командой dig +norec выше. Если есть, остались только кеши.
• Наш DNS Propagation Checker (англ.) опрашивает двенадцать публичных резолверов и ваш DNS-сервер сразу, и видно, кто из них ещё держит старый ответ.
• Cloudflare (one.one.one.one/purge-cache) и Google (dns.google/cache) позволяют любому сбросить из кеша одно имя. Свой компьютер очистите, как в шаге 4.
• В следующий раз создавайте записи до того, как откроете имя в браузере, тогда ни одному резолверу не придётся запоминать «нет».

SERVFAIL вместо NXDOMAIN: проверьте DNSSEC

Если dig говорит SERVFAIL, резолвер не смог получить ответ, которому доверяет. Когда включён DNSSEC, причина обычно в записи DS у регистратора, которая больше не совпадает с ключами зоны, чаще всего после переезда DNS к новому провайдеру. Тестовый домен dnssec-failed.org сломан так нарочно:

;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 2594
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
; EDE: 9 (DNSKEY Missing): (no SEP matching the DS found for dnssec-failed.org.)

Повторите запрос с dig +cd: этот ключ отключает проверку для одного запроса. Если теперь пришёл адрес, причина в DNSSEC. Исправляется это у регистратора: удалите старую запись DS или замените её той, которую показывает ваш нынешний DNS-провайдер. Строка DNSSEC в выводе whois выше показывает, опубликована ли запись DS вообще.

Как проверить сервер, пока DNS не работает

Чтобы узнать, готов ли сам сервер, рабочий DNS не нужен. curl можно указать, какой IP-адрес использовать для имени. Замените www.example.com своим именем, а 203.0.113.10 — IP-адресом сервера:

curl -sI --resolve www.example.com:443:203.0.113.10 https://www.example.com/

В Windows пишите curl.exe вместо curl: в Windows PowerShell curl — это псевдоним Invoke-WebRequest. Если пришли заголовки ответа, nginx или ваше приложение отвечают и не хватает только DNS. Если curl не может подключиться, работы хватит и на сервере: отказ в соединении, который русский Chrome показывает как Сайт example.com не позволяет установить соединение. с кодом ERR_CONNECTION_REFUSED, значит, что на порту никто не слушает или его отклоняет файрвол, а таймаут — что пакеты теряются по дороге.

Если домен должен указывать на сервер VMHeaven

Записи A и AAAA домена хранятся у регистратора или DNS-провайдера, а не на сервере и не в нашей панели. Каждый Standard KVM VPS получает собственный IPv4-адрес, а также IPv6-префикс, если он есть в пуле локации. Скопируйте IPv4-адрес из личного кабинета в запись A. Запись AAAA добавляйте только для IPv6-адреса, который действительно настроен на сервере и на котором сервер отвечает: Windows, например, не настраивает IPv6 сама. Поле «Обратный DNS (rDNS)» в личном кабинете задаёт PTR-запись, которая сопоставляет IP-адресу имя. Её проверяют почтовые серверы, но не браузеры, и прямой записи, которая нужна посетителю, она не создаёт.

Частые вопросы