DNS_PROBE_FINISHED_NXDOMAIN и ERR_NAME_NOT_RESOLVED: не найден адрес сайта
DNS_PROBE_FINISHED_NXDOMAIN и ERR_NAME_NOT_RESOLVED сообщают о проблеме с определением адреса сайта по его имени. Браузер не может продолжить обычную загрузку нужного ресурса и показывает «Не найден DNS-адрес сайта», «Не удаётся найти IP-адрес сервера» или похожий текст. Начните с проверки написания домена, затем сравните тот же адрес в другом браузере и через другую разрешённую сеть.
Посетителю важно понять, связан ли сбой с его условиями подключения. Владельцу — проверить, что нужное имя действительно опубликовано на используемых DNS-серверах. Простая перезагрузка веб-сервера, очистка cookies или ожидание до завтра не исправят отсутствующую DNS-запись. Ниже — порядок действий с объяснением того, какие результаты подтверждают причину, а какие только сужают поиск.
Что означают DNS_PROBE_FINISHED_NXDOMAIN и ERR_NAME_NOT_RESOLVED
DNS связывает доменные имена с необходимыми для подключения данными. Браузер использует механизм разрешения имён, чтобы найти адрес нужного узла. Если этот этап не завершился успешно, дальнейшее подключение к нему не состоится. При этом сам компьютер с веб-сервером может продолжать работать: ошибка поиска имени и остановка сервера — разные ситуации.
В перечне ошибок Chromium NAME_NOT_RESOLVED, номер −105, означает, что имя хоста не удалось разрешить. Это браузерный сетевой код. NXDOMAIN — обозначение результата DNS-запроса, указывающего на несуществующее имя. Эти понятия связаны, но их нельзя считать двумя названиями одного протокольного ответа.
Сообщение DNS_PROBE_FINISHED_NXDOMAIN показывает результат диагностики браузера. В логике Chromium такой вывод может быть предположением по результатам контрольной проверки DNS-конфигурации. Надпись не является дословной копией ответа на запрос проблемного имени. Чтобы выяснить фактический результат, посмотрите DNS-ответ отдельно. Различия описаны в терминологии DNS в RFC 9499:
| Результат проверки | Что он означает | Что проверять |
|---|---|---|
| NXDOMAIN | В данном ответе имя признано несуществующим | Написание, нужную зону, источник ответа и возможную цель CNAME |
| NODATA: подтверждено отсутствие записей нужного типа при NOERROR | Имя существует, но записей запрошенного типа нет | Тип записи и ожидаемую конфигурацию |
| SERVFAIL | Разрешение завершилось с ошибкой | Делегирование, доступность DNS-серверов, DNSSEC и подробности ответа |
| Таймаут | Ответ не получен за время ожидания | Доступность DNS-сервера и путь к нему |
Пустая строка в упрощённой проверке ещё не различает эти случаи. Например, отсутствие AAAA-записи не делает домен несуществующим: сайт может использовать IPv4 через A-запись. А NXDOMAIN для отдельного поддомена не доказывает, что основной домен не зарегистрирован или просрочен. Проверяйте конкретное полное имя, которое не открывается.
С чего начать, если не найден DNS-адрес сайта
Скопируйте адрес из строки браузера и выделите имя хоста: например, в https://shop.example.com/catalog это shop.example.com. Для DNS-проверки не нужны протокол, путь каталога и параметры после вопросительного знака. Если ошибка появилась после перехода или переадресации, сохраните конечный адрес: он может отличаться от исходного.
Сравните имя с официальной ссылкой или рабочей закладкой. Проверьте пропущенную букву, лишний дефис, доменную зону и поддомен. Адреса example.com и www.example.com требуют соответствующей конфигурации; работоспособность одного не гарантирует работоспособность другого. Для кириллического имени особенно полезно копирование из доверенного источника, чтобы исключить похожие символы.
Затем откройте несколько независимых сайтов. Если ошибка относится к одному имени, сосредоточьтесь на нём. Если не находятся многие разные адреса, вероятнее общая проблема разрешения имён или подключения. Это уже другая ветка диагностики, и исправлять DNS-зону одного сайта в такой ситуации преждевременно.
Как исправить ошибку посетителю сайта
Сравните устройство, браузер и сеть
Откройте тот же адрес в другом браузере на том же устройстве. Затем, если возможно, проверьте его с другого устройства в исходной сети и через мобильный интернет. Меняйте по одному условию и записывайте результат. Так вы поймёте, связано ли различие с конкретным браузером, устройством или используемой сетью.
Если телефон открывает страницу через мобильную сеть, а ноутбук через Wi-Fi — нет, это ещё не доказывает ошибку провайдера. Могли различаться DNS-серверы, кэш, VPN и корпоративные правила. Повторите сравнение близко по времени: временное восстановление сайта легко принять за эффект переключения сети.
На телефоне отдельно сравните встроенный браузер приложения и обычный браузер. Если ошибка встречается только в мессенджере, сохраните фактическую ссылку и проверьте её отдельно. Когда одинаково не работает несколько устройств, переустановка одного приложения обычно мало помогает установить причину.
Уточните, какой DNS использует браузер
В Chrome может быть включён защищённый DNS с выбранным поставщиком. В этом случае проверка из командной строки и браузерная загрузка не обязательно используют один источник ответа. В справке Chrome объясняются автоматический режим и выбор отдельного поставщика DNS. Посмотрите текущую настройку перед тем, как менять её.
Если проблему вызвало ваше недавнее изменение поставщика, вернитесь к известной рабочей конфигурации и сравните результат. Для рабочего устройства согласуйте проверку с администратором. Внутреннее имя компании может существовать только в её DNS и быть доступным через обязательный VPN. Переключение на публичный резолвер в таком случае способно убрать доступ к рабочим ресурсам.
Не нужно одновременно заменять DNS в роутере, системе и браузере. Вы потеряете понимание того, какое изменение повлияло на результат. Кроме того, сторонний DNS-поставщик получает запросы, которые вы ему отправляете; выбирайте его осознанно и с учётом правил своей сети.
Проверьте локальное сохранённое состояние
После исправления записи на стороне сайта устройство может продолжать использовать сохранённый отрицательный результат. Если есть основания подозревать именно локальный DNS-кэш Windows, сначала можно посмотреть его содержимое, а затем очистить:
ipconfig /displaydns
ipconfig /flushdnsЕсли Windows сообщает о недостаточных правах, откройте командную строку от имени администратора, как показано в инструкции Microsoft. На рабочем устройстве обратитесь к администратору.
Документация Microsoft указывает, что /flushdns очищает кэш клиентского разрешения имён, включая динамически сохранённые отрицательные результаты. Команда не добавляет отсутствующую запись в DNS-зону и не очищает кэши всех внешних серверов. После неё повторите проверку в тех же условиях.
Это не то же самое, что удаление cookies: cookies относятся к состоянию веб-сайта, а не к публикации DNS-имени. У браузера или выбранного DNS-поставщика также может оставаться своё состояние. Поэтому успешное выполнение команды не гарантирует, что браузер немедленно увидит новый ответ.
Передайте владельцу наблюдения
Если проблема устойчиво повторяется для одного публичного имени, отправьте поддержке домен, точный код ошибки, время с часовым поясом и результаты сравнения сетей. Укажите, работают ли основной домен и вариант с www. Если использовался VPN или отдельный защищённый DNS, отметьте это: такой контекст помогает повторить проверку.
Не стоит часами очищать разные кэши, если имя не разрешается и из независимых сетей. Дальнейшее исправление может требовать доступа к регистратору или DNS-провайдеру. Посетитель не сможет восстановить отсутствующую запись изменением настроек браузера.
Как проверить DNS-ответ через nslookup и dig
В Windows для первоначальной проверки подходит nslookup. В примере замените www.example.com полным именем нужного публичного узла. Точка в конце указывает на полное DNS-имя и помогает избежать добавления локального поискового суффикса:
nslookup -type=A www.example.com.
nslookup -type=AAAA www.example.com.По руководству Microsoft, без второго адреса команда использует DNS-сервер по умолчанию. Сохраните его адрес, запрошенное имя и итог проверки. Сообщения Nonexistent domain, No records и Server failure обозначают разные результаты. Не ограничивайтесь фразой «nslookup ничего не нашёл».
Для сравнения публичного имени можно выполнить отдельный запрос к согласованному публичному резолверу, например Google Public DNS. Это не меняет системные настройки:
nslookup -type=A www.example.com. 8.8.8.8Различающиеся ответы — повод сравнить источник данных, кэш и настройки, а не автоматически объявлять первый DNS-сервер неисправным. В некоторых сетях обращения к внешним DNS ограничиваются или перенаправляются. И не отправляйте внутренние имена компании публичному серверу ради такой проверки: для них нужен предусмотренный корпоративный путь.
Если установлен dig, подробный ответ удобнее читать по полям:
dig www.example.com. A
dig www.example.com. AAAAВ строке status находится код ответа. В ANSWER SECTION — возвращённые данные, если они есть; в AUTHORITY SECTION при отрицательном ответе может присутствовать SOA. Поле SERVER показывает, откуда получен ответ. Для расследования сохраняйте весь относящийся к запросу вывод: режим +short скрывает сведения, которые помогают отличить NXDOMAIN, NODATA и ошибку сервера.
У NODATA нет отдельного значения в поле status. Пустой ANSWER при NOERROR также может встречаться в ответе, направляющем к другим DNS-серверам, — referral. Поэтому смотрите AUTHORITY SECTION: отрицательный ответ обычно содержит SOA, а NS без SOA может указывать на делегирование. Различие описано в RFC 2308. Особенно это важно при прямом запросе к авторитетному серверу без рекурсии.
Синтаксис утилиты описан в документации BIND. Наличие адреса в ответе завершает только проверку разрешения имени. Оно ещё не подтверждает доступность HTTPS, правильность сертификата или работоспособность страницы. Если код браузера после исправления изменился, переходите к диагностике нового этапа.
Что проверить владельцу домена и сайта
Регистрацию, делегирование и место редактирования
Откройте кабинет регистратора: проверьте срок регистрации, состояние домена и назначенные серверы имён. Затем сравните их с DNS-провайдером, в панели которого вы редактируете записи. Типичная организационная ошибка после переноса — менять старую зону, хотя домен уже делегирован другим серверам. Красиво заполненная таблица в неиспользуемой панели не меняет публичный ответ.
Владелец может сверить список NS через DNS-проверку, но при расхождении нужно разобраться и с делегированием у регистратора. Сам NXDOMAIN не заменяет проверку регистрации: отсутствие отдельного поддомена и потеря делегирования всего домена имеют разные причины и исправления.
Точное имя и цепочку CNAME
Проверьте основной домен и каждый используемый поддомен отдельно. При переносе часто копируют запись для главной страницы, но пропускают www, кабинет или магазин. После подключения Cloudflare его официальная инструкция по NXDOMAIN также рекомендует проверить корневое имя и нужные поддомены. Создавайте только записи, предусмотренные реальной схемой сайта.
Если имя ссылается через CNAME на другое имя, проверьте и цель. Например, www может существовать как псевдоним, но вести на уже удалённый адрес прежнего сервиса. В RFC 2308 показано, что ответ NXDOMAIN может содержать CNAME: несуществующей в таком случае оказывается цель цепочки. Поэтому наличие строки CNAME в панели ещё не подтверждает работоспособность разрешения.
У платформ с преобразованием CNAME в конечные адреса внешний ответ может выглядеть иначе. Проверяйте настройки используемого провайдера и фактический результат, а не ожидайте обязательного буквального CNAME в каждом публичном ответе. Исправление должно восстановить правильную цель и необходимые адресные данные.
Ответы действующих авторитетных серверов
Авторитетные DNS-серверы обслуживают данные зоны; рекурсивный резолвер получает их для клиента и может хранить ответ в кэше. Если рекурсивные серверы отвечают по-разному, полезно проверить первоисточник. Подставьте в команду реальный авторитетный сервер своей зоны вместо условного ns1.example.net:
dig @ns1.example.net www.example.com. A +norecurseУбедитесь, что обращаетесь к серверу именно нужной зоны. Флаг aa в заголовке dig означает авторитетный ответ; одно лишь имя сервера в команде не доказывает, что он обслуживает проверяемую зону. Если поддомен делегирован отдельно, его данные находятся у соответствующих серверов. Для важного имени сравните ответы всех объявленных авторитетных серверов: рассогласование может давать разные результаты разным посетителям.
Ответ с правильной записью у одного сервера помогает подтвердить исправление, но не гарантирует согласованности всей конфигурации. Если получен отказ или ошибка, сначала уточните, должен ли выбранный сервер обслуживать эту зону. Не добавляйте одинаковые записи во все доступные панели без понимания делегирования.
Если вместо NXDOMAIN обнаружен SERVFAIL
Переключите диагностику на фактический результат. Например, после смены DNS-провайдера DNSSEC может остаться несогласованным: данные проверки у родительской зоны и ключи новой зоны не соответствуют друг другу. Проверяющий резолвер тогда может вернуть SERVFAIL. Это не равно отсутствию доменного имени.
Руководство Google Public DNS для владельцев доменов описывает проверки DNSSEC, делегирования и доступности авторитетных серверов. При такой неисправности исправляют согласованность конфигурации вместе с DNS-провайдером и регистратором. Отключение проверки у посетителей не устраняет причину публичного сбоя.
Почему NXDOMAIN остаётся после добавления записи
DNS сохраняет не только найденные адреса, но и отрицательные ответы. Если имя запросили до его создания, рекурсивный сервер мог запомнить, что оно не существует. После исправления авторитетный сервер уже отдаёт запись, а часть пользователей ещё получает сохранённый отрицательный ответ.
Время такого хранения связано с SOA и правилами отрицательного кэширования, а не просто с TTL только что созданной A-записи. Документация Cloudflare по DNS отдельно разбирает этот случай. Уменьшение TTL новой записи не заставляет внешний резолвер немедленно удалить уже сохранённый NXDOMAIN.
Практический порядок следующий: подтвердить правильный ответ у авторитетных серверов, сравнить ответ используемого резолвера и посмотреть доступный оставшийся TTL отрицательного ответа. Затем повторить проверку после соответствующего интервала или использовать штатную очистку кэша конкретного поставщика, если она доступна владельцу.
Обещание «подождите 24 часа, всё заработает» слишком грубое. Ошибка может исчезнуть раньше, а неверное делегирование или отсутствующая цель CNAME не исправятся ожиданием. Очистка локального кэша влияет только на локальный уровень; она не удаляет сохранённый ответ у провайдера или всех остальных пользователей.
Пример: после переноса открывается главная, но не www
Представим, что компания перенесла DNS к новому поставщику. Адрес example.com работает, а посетители, пришедшие по старым ссылкам на www.example.com, видят DNS_PROBE_FINISHED_NXDOMAIN. Это условный пример диагностики, а не описание проверки конкретной компании.
- Администратор фиксирует точное проблемное имя и подтверждает NXDOMAIN запросом DNS.
- Сверяет делегирование: используются новые серверы имён, поэтому исправлять нужно новую зону.
- Проверяет её содержимое и обнаруживает, что запись для www не перенесли.
- Восстанавливает предусмотренную схемой запись и проверяет результат на всех действующих авторитетных серверах.
- Сравнивает ответы рекурсивных серверов. Там, где ещё действует отрицательный кэш, учитывает его срок и повторяет проверку.
- После разрешения имени открывает HTTPS-адрес и проверяет нужную страницу, сертификат и ожидаемый переход между вариантами домена.
Настройка HTTP-редиректа сама по себе не помогла бы посетителю, который не может разрешить исходное имя. Сначала нужно обеспечить возможность подключения к этому имени. Затем уже проверяется поведение веб-сервера. Такой порядок отделяет найденную DNS-ошибку от последующих настроек сайта.
Как подтвердить исправление и раньше замечать повторение
Проверьте исходное имя в тех же условиях, где возникала ошибка, и дополнительно — через независимую разрешённую сеть. Сохраните время, использованный DNS-сервер и результат. Убедитесь, что восстановилась загрузка ожидаемой страницы. Появившаяся вместо NXDOMAIN ошибка сертификата означает продвижение по этапам, но ещё не полное восстановление.
При выборе регулярного контроля включите в требования важные домены и поддомены, историю сбоев и уведомления ответственному. Перейдите на SiteGuard, чтобы изучить актуальное предложение и уточнить доступность нужных проверок. Отдельно организуйте контроль обязанностей и сроков у регистратора. История внешних проверок даёт временные ориентиры, но одна проверка URL не определяет виновный DNS-узел и не повторяет настройки DNS каждого посетителя.
После переноса проверяйте заранее составленный список используемых имён, а не только главную страницу. Зафиксируйте, где находится действующая DNS-зона и кто отвечает за изменения. Это сокращает поиск при следующем сбое и помогает не потерять поддомены при очередной смене инфраструктуры.
Частые вопросы
NXDOMAIN означает, что домен свободен для регистрации?
Нет. Ответ может относиться к отдельному поддомену, цели CNAME или выбранному источнику DNS-данных. Наличие и состояние регистрации проверяют у регистратора. Браузерная ошибка не является проверкой доступности доменного имени для покупки.
Поможет ли очистка cookies?
Она не создаст отсутствующую DNS-запись. Если проблема действительно связана с разрешением имени, проверяйте DNS, его источник и кэш. Удаление всех данных браузера может вывести из аккаунтов, не изменив результат DNS-запроса.
Почему в одном браузере сайт работает, а в другом — нет?
У них могут различаться защищённый DNS, сохранённое состояние и настройки подключения. Сравните эти условия и точное имя в адресной строке. Работа одного браузера не доказывает, что все DNS-серверы уже отвечают одинаково.
Не найден адрес сайта — это блокировка?
Одного сообщения недостаточно для такого вывода. Возможны опечатка, ошибка зоны, кэш и особенности используемого DNS. Если предполагается фильтрация, нужны подтверждения от администратора сети или поставщика услуги, а не только английское название ошибки.
Как понять, кому писать: хостингу или регистратору?
Передайте запрос тому, кто управляет неисправным участком. Регистрация и назначение NS обычно находятся у регистратора, содержимое действующей зоны — у DNS-провайдера, настройки устройства — у его администратора. Если роли совмещены, достаточно одной поддержки, но приложите точное имя, время и полученный DNS-ответ.