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

Что такое DNS_PROBE_FINISHED_NXDOMAIN

DNS_PROBE_FINISHED_NXDOMAIN — это ошибка браузера на базе Chromium (Google Chrome, Microsoft Edge, Opera, Brave), которая появляется, когда браузер не смог сопоставить введённый адрес с IP-адресом сервера. Вместо страницы вы видите экран «Не удаётся получить доступ к сайту» с пояснением, что «не удалось найти IP-адрес сервера».

Разберём название ошибки по частям:

• DNS — система доменных имён, которая превращает понятный человеку адрес (например, uptimechecker.ru) в IP-адрес (например, 203.0.113.10).
• PROBE_FINISHED — браузер закончил попытку (probe) разрешить имя и получил ответ.
• NXDOMAIN — код ответа DNS-сервера, который буквально означает «Non-Existent Domain», то есть «домен не существует».

Ключевой момент: NXDOMAIN — это не сбой вашего компьютера и не поломка интернета. Это осмысленный ответ DNS-сервера, который сообщает браузеру: «в зоне, за которую я отвечаю, такого имени нет». Браузер лишь честно показывает вам то, что сказал сервер.

Важно отличать NXDOMAIN от похожих, но иных по смыслу ошибок:

Понимание этой разницы экономит много времени: если у вас NXDOMAIN, чинить надо DNS-записи и кеши, а не, скажем, фаервол или SSL.

Как работает резолвинг: почему браузер вообще спрашивает DNS

Чтобы понять, где именно возникает ошибка, нужно представлять цепочку, по которой браузер узнаёт IP-адрес. Она выглядит так:

1. Браузер получает от вас адрес example.com.
2. Браузер спрашивает кэш операционной системы — вдруг адрес уже резолвился недавно.
3. Если нет — ОС обращается к DNS-резолверу, указанному в настройках сети (обычно это роутер или публичный резолвер провайдера).
4. Резолвер, в свою очередь, опрашивает авторитативные DNS-серверы домена, начиная с корневых и двигаясь вниз по иерархии зон.
5. Авторитативный сервер зоны возвращает запись (например, A-запись с IP) — либо ответ NXDOMAIN, если имени в зоне нет.

Ошибка NXDOMAIN рождается ровно на шаге 5: авторитативный сервер зоны утвердительно ответил, что такого поддомена в его зоне не существует. Это не «таймаут», не «сервер недоступен», а конкретный отрицательный ответ.

Отсюда следует важный практический вывод: NXDOMAIN почти всегда указывает на проблему с самим именем — либо вы опечатались в адресе, либо запись ещё не создана, либо её удалили, либо вы смотрите на поддомен, которого никогда не было.

Причины появления ошибки и как их различать

Причин у NXDOMAIN немного, но они разные по своей природе. Разберём их по группам.

1. Опечатка в адресе

Самая частая и самая безобидная причина. example.com вместо exampel.com, лишняя буква, пропущенная точка, неверная доменная зона (ru вместо com). Браузер честно сообщает: такого имени нет.

Как проверить: перечитайте адресную строку посимвольно, попробуйте найти домен через поиск или воспользоваться проверкой DNS-записей UptimeChecker — инструмент покажет, резолвится ли имя вообще.

2. Запись ещё не создана или неверно прописана

Вы зарегистрировали домен или создали поддомен, но не добавили A-запись, либо прописали её с ошибкой (не тот IP, лишний пробел, неверное имя поддомена). Авторитативный сервер зоны про поддомен ничего не знает — и отвечает NXDOMAIN.

3. Запись удалена или изменена

Администратор удалил A-запись, или смена хостинга прошла некорректно: старый IP убрали, а новый не добавили. Пока в зоне нет записи, все пользователи будут получать NXDOMAIN.

4. Устаревший кэш резолвера

Вы только что добавили запись, но публичные резолверы и ваш локальный кэш ещё помнят прежний отрицательный ответ (NXDOMAIN тоже кешируется). Про кэш и TTL подробно говорится в статье про смену хостинга и пропагацию DNS, но коротко: отрицательный ответ может «жить» в кэше до истечения TTL зоны.

5. Проблемы с делегированием зоны

Домен зарегистрирован, но на NS-серверы регистратора указаны неверные или ещё не прописанные серверы. В этом случае зона фактически не обслуживается — и запросы к ней возвращают NXDOMAIN.

6. DNS-сервер провайдера подменяет ответы

Некоторые провайдеры и публичные Wi-Fi-сети перехватывают NXDOMAIN и подсовывают свою «поисковую» страницу или блокировку. Симптом тот же — сайт не открывается, — но корень в резолвере, а не в домене. Смена резолвера на нейтральный (например, публичный) сразу снимает вопрос.

Сведём всё в таблицу «симптом → вероятная причина → решение»:

Самопроверка: dig и nslookup

Прежде чем менять что-либо, стоит выяснить, что именно отвечает DNS на самом деле. Для этого есть два базовых инструмента — dig и nslookup. Они есть в macOS и Linux из коробки, а на Windows — встроенный nslookup (для dig потребуется установить BIND Tools отдельно).

Проверка через dig

Откроем терминал и выполним запрос к публичному резолверу Google, чтобы исключить влияние кэша провайдера:

dig example.com @8.8.8.8

Типичный ответ при ошибке NXDOMAIN выглядит так:

; <<>> DiG 9.10.6 <<>> example.com @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 54321
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;example.com.                   IN      A

;; AUTHORITY SECTION:
example.com.            1800    IN      SOA     ns1.registrar.example. hostmaster.registrar.example. 2024010101 7200 3600 1209600 1800

;; Query time: 23 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Jan 01 12:00:00 UTC 2024
;; MSG SIZE  rcvd: 90

Разберём вывод построчно:

• status: NXDOMAIN — это главное. Резолвер получил от авторитативного сервера зоны утвердительный ответ «такого имени нет».
• ANSWER: 0 — в ответе ноль записей; IP-адрес не найден.
• QUESTION SECTION — что именно спрашивали: запись A для example.com.
• AUTHORITY SECTION — сервер зоны, который ответил, и его SOA-запись. Наличие SOA здесь означает: зона существует и обслуживается, но в ней нет запрошенного имени. Это важный нюанс — значит, проблема не в делегировании зоны, а в отсутствии конкретной записи.
• Query time: 23 msec — запрос выполнен быстро, то есть сеть и резолвер работают исправно.

Теперь сравним с ответом для существующего домена:

dig uptimechecker.ru @8.8.8.8 +short

Если домен жив, команда с флагом +short выведет только IP-адреса, например:

203.0.113.10

Здесь видно сразу: есть A-запись, есть IP — значит, резолвинг работает, и NXDOMAIN у вас появился бы только из-за опечатки или локального кэша.

Проверка через nslookup

На Windows и в случаях, когда dig недоступен, используйте nslookup:

nslookup example.com 8.8.8.8

Ответ при ошибке будет таким:

Server:  dns.google
Address:  8.8.8.8

*** dns.google can't find example.com: Non-existent domain

Разбор:

• Server: dns.google и Address: 8.8.8.8 — к какому резолверу обращались.
• *** ... can't find example.com: Non-existent domain — тот самый NXDOMAIN, переданный словами. Имени нет.

Если бы имя существовало, вывод был бы иным:

Server:  dns.google
Address:  8.8.8.8

Name:    uptimechecker.ru
Address: 203.0.113.10

Наличие блока Name: и Address: подтверждает успешный резолвинг.

Что проверять в первую очередь

Сравнение ответов на разных резолверах быстро локализует проблему:

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

Как исправить ошибку: пошагово

Порядок действий зависит от того, на чьей стороне проблема. Идём от простого к сложному.

Шаг 1. Проверьте написание адреса

Убедитесь, что в адресной строке нет опечатки, лишних точек или пробелов. Проверьте, что вы не перепутали зону (ru / com / net). Часто проблема исчезает после исправления одной буквы.

Шаг 2. Сбросьте локальный кэш DNS

Если домен точно существует, но браузер продолжает показывать NXDOMAIN, очистите кэш резолвера на своём устройстве.

На macOS выполните в терминале:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

На Windows — в командной строке от имени администратора:

ipconfig /flushdns

На Linux (systemd-resolved):

sudo systemd-resolve --flush-caches

После очистки откройте сайт в режиме инкогнито или новом профиле браузера, чтобы исключить и его собственный внутренний кэш.

Шаг 3. Смените DNS-резолвер

Если провайдер перехватывает NXDOMAIN или его резолвер устарел, временно укажите публичный резолвер в настройках сетевого адаптера. Подойдут 8.8.8.8 (Google) или 1.1.1.1 (Cloudflare). После смены повторите проверку через dig — если имя резолвится, проблема была в резолвере.

Шаг 4. Проверьте записи в панели регистратора или хостинга

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

• для домена (или поддомена www) существует A-запись с корректным IP-адресом;
• запись CNAME (если используется) указывает на существующее имя;
• NS-серверы домена прописаны и совпадают с серверами, на которых реально лежит зона.

Воспользуйтесь проверкой DNS-записей UptimeChecker — она покажет, какие записи видит внешний наблюдатель прямо сейчас, без привязки к вашему кэшу.

Шаг 5. Дождитесь пропагации

Если запись только что создали или изменили, распространение по резолверам занимает время — обычно от нескольких минут до суток, в зависимости от TTL. Если при этом предыдущий ответ был NXDOMAIN, он тоже какое-то время остаётся в кэше. Подробнее механика описана в статье о пропагации DNS после смены хостинга.

Шаг 6. Проверьте делегирование домена

Если зона не делегирована вовсе, запросы не доходят до авторитативного сервера. Проверка домена через RDAP/WHOIS покажет текущее состояние регистрации и список NS-серверов. Сверьте их с теми, что указаны у вас в панели.

Типичные сценарии и разбор ошибок

Несколько частых ситуаций с готовым планом действий.

Сценарий А: «Вчера работало, сегодня NXDOMAIN у всех»

Домен старый, трафик был. Внезапно — NXDOMAIN у всех пользователей. Причина почти всегда в зоне: запись удалили, зону «отвязали», либо домен не продлили и регистратор приостановил делегирование.

Что делать: проверить срок регистрации через проверку домена, зайти в панель DNS и убедиться, что A-запись на месте. Если запись есть, но NXDOMAIN сохраняется — проверить NS-серверы.

Сценарий Б: «Создал поддомен, но он не открывается»

Создали поддомен blog.example.com, добавили запись, но браузер выдаёт NXDOMAIN. Вероятные причины: запись добавили не в ту зону, TTL ещё не истёк и отрицательный ответ кешируется, либо вы смотрите на www.blog.example.com, для которого записи нет.

Что делать: сверить имя записи в панели, подождать истечения TTL, проверить через dig blog.example.com @8.8.8.8.

Сценарий В: «Ошибка только на моём ноутбуке»

На телефоне сайт открывается, на ноутбуке — NXDOMAIN. Классика: локальный кэш или специфичный резолвер (VPN, корпоративный DNS).

Что делать: шаг 2 и 3 выше — сбросить кэш и сменить резолвер. Если включён VPN — отключить и проверить снова.

Коротко: чек-лист при DNS_PROBE_FINISHED_NXDOMAIN

1. Перечитайте адрес — нет ли опечатки.
2. Проверьте резолвинг снаружи: dig example.com @8.8.8.8 +short.
3. Сбросьте локальный кэш DNS на своём устройстве.
4. Смените резолвер на публичный и повторите проверку.
5. Проверьте A/CNAME/NS-записи в панели DNS.
6. Убедитесь, что домен продлён и делегирование активно.
7. Дождитесь истечения TTL, если записи меняли недавно.

Если после всех шагов dig стабильно возвращает IP, а сайт всё равно недоступен — значит, проблема перешла из плоскости DNS в плоскость сервера: стоит проверить доступность сайта и порт, на котором отвечает веб-сервер.

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