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

DNS_PROBE_FINISHED_NXDOMAIN появляется в Chrome и браузерах на Chromium, когда браузер не смог найти IP-адрес для указанного доменного имени. Проще: вы ввели адрес сайта, браузер пошёл в DNS, но получил ответ «такого домена нет» или не смог корректно разрешить имя.

Чаще всего проблема локальная: кэш DNS, неправильный DNS-сервер, VPN, прокси, сбой роутера или опечатка в домене. Но для владельца сайта такая ошибка может означать серьёзную проблему: истёк домен, слетели NS-записи, удалена DNS-зона, неправильно настроен A, AAAA или CNAME.

Разберём, что означает ошибка DNS_PROBE_FINISHED_NXDOMAIN, как быстро отличить локальный сбой от проблемы на стороне домена и что делать пользователю, разработчику или владельцу сайта.

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

DNS_PROBE_FINISHED_NXDOMAIN состоит из двух важных частей.

1) DNS_PROBE_FINISHED — браузер завершил DNS-проверку. Перед тем как открыть сайт, браузеру нужно получить IP-адрес сервера. Для этого он обращается к DNS-резолверу: провайдера, корпоративной сети, роутера, публичному DNS вроде 1.1.1.1 или 8.8.8.8.

2) NXDOMAIN — ответ DNS означает Non-Existent Domain, то есть «домен не существует». Это не HTTP-ошибка вроде 404 или 502: браузер даже не дошёл до веб-сервера. Соединение по HTTP/HTTPS ещё не началось, потому что не найден адрес, куда подключаться.

Например, если DNS-запись работает, цепочка выглядит так:

example.com → DNS → 93.184.216.34 → TCP/TLS → HTTP-запрос → страница сайта.

При NXDOMAIN цепочка обрывается раньше:

example.com → DNS → «имя не найдено» → браузер показывает ошибку.

Поэтому очистка cookie, перезагрузка веб-приложения или проверка Nginx не всегда помогут. Сначала нужно понять, где именно ломается разрешение имени: в браузере, ОС, роутере, у провайдера, у публичных DNS или в авторитетной DNS-зоне домена.

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

Быстрая диагностика: локальная проблема или домен сломан для всех

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

1) Проверьте адрес на опечатки — банально, но это частая причина. Ошибка в одной букве, лишний дефис, неправильная зона .ru вместо .com, кириллическая буква вместо латинской — и DNS честно вернёт NXDOMAIN.

2) Откройте сайт с другого устройства — например, с телефона через мобильный интернет, не через тот же Wi-Fi. Если сайт открывается, проблема почти наверняка в локальной сети, DNS-кэше, браузере, VPN или настройках конкретного устройства.

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

4) Проверьте и корневой домен, и поддомен — example.com и www.example.com могут быть настроены по-разному. Частый сценарий: корневой домен открывается, а www возвращает NXDOMAIN, потому что для него забыли создать CNAME или A-запись.

5) Посмотрите, не истёк ли домен — если домен не продлён, регистратор может снять делегирование или заменить DNS-записи. Для пользователей это часто выглядит как внезапный DNS_PROBE_FINISHED_NXDOMAIN.

Если кроме этой ошибки сайт периодически отдаёт ещё и HTTP-коды 500, 502, 503 или просто не открывается, диагностику стоит расширить. Для общего сценария есть пошаговый материал что делать, если не открывается сайт.

Частые причины ошибки

У DNS_PROBE_FINISHED_NXDOMAIN несколько типичных источников. Они отличаются тем, кто может исправить проблему: пользователь, системный администратор, владелец домена или DNS-провайдер.

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

2) Устаревший DNS-кэш — браузер, операционная система, роутер и DNS-резолверы кэшируют ответы. Кэш ускоряет работу, но после изменений в DNS может временно хранить старое состояние, включая отрицательный ответ NXDOMAIN (это называется negative caching). Подробнее о таких задержках — в статье как работает DNS caching.

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

4) Неправильные настройки DNS-зоны — у домена могут отсутствовать A, AAAA, CNAME, NS или другие записи. Иногда зона удалена у DNS-хостинга, но домен всё ещё делегирован на эти NS-серверы.

5) Ошибка в делегировании домена — у регистратора указаны неправильные NS-серверы, NS не отвечают, DNS-хостинг отключён, домен перенесли, но старые записи остались в кэше.

6) Проблемы с VPN, прокси или корпоративным DNS — в корпоративных сетях часто используется split DNS: внутренние домены доступны только через внутренний резолвер. Если VPN отключён или DNS маршрутизируется неправильно, браузер получает NXDOMAIN.

7) Повреждённые сетевые настройки ОС — после установки VPN-клиента, антивируса, сетевого фильтра или обновлений могут сломаться параметры DNS, Winsock, IPv6 или прокси.

8) Неверная запись в hosts — файл hosts обычно не даёт NXDOMAIN, потому что он подменяет DNS, но неправильная запись может направлять домен не туда. При диагностике его всё равно стоит проверить.

Как исправить ошибку пользователю

Начинайте с простых действий. Они безопасны и закрывают большую часть локальных причин.

1) Перезагрузите страницу и браузер — если это разовый сбой резолвера или временная проблема сети, повторный запрос может пройти успешно. Закройте браузер полностью, особенно если он долго работает в фоне.

2) Отключите VPN и прокси — VPN-клиенты часто подменяют DNS-серверы. Если ошибка исчезла после отключения VPN, проверьте настройки DNS внутри VPN-клиента или split tunneling. В Chrome также проверьте системный прокси: chrome://settings/system.

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

4) Смените DNS-серверы — вместо DNS провайдера можно временно указать публичные резолверы:

• Cloudflare: 1.1.1.1 и 1.0.0.1;
• Google Public DNS: 8.8.8.8 и 8.8.4.4;
• Quad9: 9.9.9.9.

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

5) Очистите DNS-кэш — браузер и ОС могут хранить старый отрицательный ответ. Команды для Windows, macOS и Linux приведены ниже.

6) Проверьте файл hosts — на Windows он находится в C:\Windows\System32\drivers\etc\hosts, на Linux и macOS — в /etc/hosts. Убедитесь, что там нет строки с проблемным доменом. Если строка есть и вы не понимаете, зачем она нужна, закомментируйте её символом # и повторите проверку.

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

8) Проверьте дату и время — неверные дата и часовой пояс чаще вызывают TLS-ошибки, но в сочетании с корпоративными агентами безопасности и VPN могут ломать сетевую проверку. Лучше исключить и этот фактор.

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

Команды для Windows, macOS и Linux

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

1) Windows — откройте cmd или PowerShell от имени администратора и выполните:

ipconfig /flushdns
netsh winsock reset
netsh int ip reset

После этого перезагрузите компьютер. Для проверки домена используйте:

nslookup example.com
nslookup example.com 1.1.1.1
nslookup example.com 8.8.8.8

Если системный DNS возвращает Non-existent domain, а 1.1.1.1 возвращает IP-адрес, проблема в текущем DNS-резолвере.

2) macOS — откройте Terminal и выполните:

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

Команды не выводят подробный результат при успехе. После выполнения закройте и снова откройте браузер.

Проверка DNS:

dig example.com A
dig @1.1.1.1 example.com A

3) Linux с systemd-resolved — на многих современных дистрибутивах работает resolvectl:

sudo resolvectl flush-caches
resolvectl query example.com
resolvectl dns

Если используется nscd, dnsmasq или локальный кэширующий резолвер, очистка зависит от сервиса:

sudo systemctl restart nscd
sudo systemctl restart dnsmasq

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

dig example.com A
dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A

4) Chrome и Chromium-браузеры — у браузера есть собственный DNS-кэш. Откройте:

chrome://net-internals/#dns

Нажмите Clear host cache. Затем откройте:

chrome://net-internals/#sockets

Нажмите Flush socket pools. После этого перезапустите браузер.

В новых версиях Chrome интерфейс может меняться, но смысл остаётся тем же: очистить кэш резолвера браузера и существующие сетевые соединения.

Что делать владельцу сайта или домена

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

1) Проверьте регистрацию домена — зайдите в панель регистратора и убедитесь, что домен активен, не истёк и не находится в статусах вроде clientHold, serverHold, pendingDelete. При hold-статусах домен может перестать делегироваться.

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

3) Проверьте DNS-зону у хостинга — зона должна существовать и содержать нужные записи. Для сайта обычно нужны:

• A для IPv4;
• AAAA для IPv6, если он реально настроен;
• CNAME для www, если www.example.com должен вести на корневой домен или другой хост;
• NS и SOA для самой зоны.

4) Не создавайте CNAME там, где он конфликтует — для одного имени нельзя одновременно использовать CNAME и другие записи вроде A или MX. На корневом домене example.com обычный CNAME часто запрещён стандартной DNS-моделью; некоторые DNS-провайдеры предлагают ALIAS или ANAME.

5) Проверьте www отдельно — example.com и www.example.com — разные имена. Если пользователи заходят по www, для него должна быть отдельная запись. Частая ошибка после миграции: настроили только apex-домен, а www забыли.

6) Проверьте DNSSEC — некорректные DS-записи у регистратора или сломанная подпись зоны чаще приводят к SERVFAIL, но для пользователя это всё равно выглядит как DNS-сбой. Если недавно включали или отключали DNSSEC, проверьте цепочку валидации.

7) Учитывайте TTL — после исправления записи результат не всегда виден мгновенно: резолверы хранят старые ответы до истечения TTL, а отрицательные ответы — согласно настройкам SOA. Поэтому часть пользователей уже видит исправление, а часть ещё получает ошибку.

8) Проверьте CDN и DNS-провайдера — если домен обслуживается через Cloudflare, Route 53, Selectel, REG.RU, Timeweb Cloud или другой сервис, ошибка может быть связана с отключённой зоной, неоплаченным тарифом, удалённой записью или неверным режимом проксирования.

Для продакшен-сайтов полезно держать внешний мониторинг доступности: если DNS перестал разрешаться, проверка из внешней сети покажет сбой раньше, чем о нём напишут пользователи. Statuser проверяет сайт с заданным интервалом и присылает уведомление о сбое; это не заменяет DNS-мониторинг на уровне провайдера, но помогает быстро увидеть, что сайт недоступен снаружи.

Как проверить DNS-записи через dig и DNS lookup

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

Базовые команды:

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

Проверка через конкретный резолвер:

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

Если разные резолверы дают разные ответы, смотрите на TTL, недавние изменения DNS и возможные проблемы кэша.

Проверка полного пути делегирования:

dig +trace example.com

+trace показывает, как запрос проходит от корневых серверов к зоне верхнего уровня и дальше к авторитетным NS домена. Это полезно, когда нужно понять, где именно ломается цепочка: у регистратора, на уровне TLD, у DNS-хостинга или в самой зоне.

На что смотреть в выводе dig:

1) status: NXDOMAIN — DNS-система считает, что такого имени нет. Если это ваш домен или поддомен, проверьте зону и делегирование.

2) status: NOERROR, но нет ANSWER SECTION — домен существует, но записи нужного типа нет. Например, есть A, но нет AAAA, или есть зона, но нет записи для конкретного поддомена.

3) status: SERVFAIL — резолвер не смог получить корректный ответ. Частые причины: DNSSEC, недоступные NS, сбой авторитетного DNS.

4) status: REFUSED — сервер отказался отвечать. Возможно, вы обращаетесь не к тому DNS-серверу или он не обслуживает эту зону.

5) ANSWER SECTION содержит IP — DNS-разрешение работает. Если браузер всё равно показывает ошибку, очищайте кэш браузера/ОС или ищите проблему в конкретной сети.

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

Как предотвратить повторение ошибки

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

1) Продлевайте домен заранее — включите автопродление и следите за актуальностью платёжных данных. Истёкший домен — одна из самых неприятных причин DNS_PROBE_FINISHED_NXDOMAIN, потому что сайт может стать недоступен сразу для всех.

2) Храните DNS как конфигурацию — для проектов с инфраструктурой лучше описывать DNS-записи в Terraform, Ansible или другой системе управления конфигурацией. Это снижает риск случайного удаления записи через веб-панель.

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

4) Проверяйте apex и www после каждого изменения — тестируйте оба варианта, а также важные поддомены: api, admin, static, cdn, mail, если они используются.

5) Следите за DNSSEC — включайте его только если понимаете процесс ротации ключей и связь с DS-записями у регистратора: сломанная цепочка может сделать домен недоступным для валидирующих резолверов.

6) Используйте внешний мониторинг — внутренний health check может показывать, что приложение живо, но пользователи не смогут открыть сайт, если домен не разрешается. Внешний uptime monitoring проверяет сайт так, как его видит пользователь из сети. Подробнее о подходе — в статье что такое uptime monitoring и как он работает.

7) Настройте разумные уведомления — алерты должны приходить быстро, но не превращаться в шум. Для DNS и доступности сайта обычно лучше несколько независимых проверок и понятная эскалация, чем десятки однотипных сообщений. Если проверка падает из-за DNS, в уведомлении стоит видеть не только факт недоступности, но и ошибку разрешения имени.

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

FAQ

Почему Chrome показывает DNS_PROBE_FINISHED_NXDOMAIN, а в другом браузере сайт открывается?

Скорее всего, в Chrome остался собственный DNS-кэш или включён Secure DNS с другим резолвером. Очистите кэш через chrome://net-internals/#dns, отключите расширения и проверьте настройки Use secure DNS.

Это ошибка сайта или моего компьютера?

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

Сколько ждать после изменения DNS-записей?

Зависит от TTL и кэшей резолверов. Иногда изменения видны за минуты, иногда старые ответы сохраняются дольше. Отрицательные ответы NXDOMAIN тоже могут кэшироваться.

Может ли DNS_PROBE_FINISHED_NXDOMAIN быть из-за SSL-сертификата?

Обычно нет. При этой ошибке браузер не дошёл до TLS-рукопожатия, потому что не получил IP-адрес. Проблемы SSL проявляются другими сообщениями, например ошибками сертификата или TLS-соединения.