DNS-сервер не отвечает в Windows: как найти причину

Сообщение «DNS-сервер не отвечает» означает, что проверка разрешения имени не получила ожидаемого ответа. Оно не доказывает поломку роутера, блокировку сайта или отсутствие интернета у провайдера. Чтобы исправить проблему, выясните, затронут один компьютер или вся сеть, какое DNS-соединение используется и работают ли следующие этапы: TCP, TLS и HTTPS.

Ниже — последовательность для домашнего компьютера с Windows 10/11. Начальные команды читают состояние и не меняют настройки. Для корпоративной сети с внутренними доменами сохраняйте DNS организации: случайный публичный сервер может перестать находить локальные ресурсы.

Быстрая проверка: один сайт, один компьютер или вся сеть

Откройте на компьютере несколько знакомых сайтов. Повторите проверку на телефоне, подключённом к тому же Wi-Fi, а затем через мобильную сеть. Не сравнивайте только одну страницу: у самого сайта может быть сбой. Запишите время и точный домен, на котором проблема повторяется.

Такое сравнение локализует проблему, но не называет виновника. Различие между Wi-Fi и мобильной сетью может возникать из-за DNS, маршрута, фильтра, выбранного CDN-адреса или конфигурации сервиса. Для вывода нужна следующая проверка.

Посмотрите адрес, шлюз и DNS активного соединения

Откройте именно Windows PowerShell, а не командную строку cmd. Начните с команд:

Get-NetIPConfiguration
Get-DnsClientServerAddress
ipconfig /all

В выводе найдите адаптер, которым вы сейчас пользуетесь: Wi-Fi или Ethernet. На компьютере также могут присутствовать виртуальные интерфейсы Hyper-V, VPN и отключённые сетевые карты. Наличие DNS в другом адаптере ещё не объясняет, какой сервер обслуживает ваше активное соединение.

Проверьте IPv4/IPv6-адреса, Default Gateway и DNS Servers. Адрес DNS часто совпадает с адресом роутера: тогда компьютер отправляет запрос домашнему шлюзу, а тот пересылает его дальше. Это нормальная схема. Если вместо ожидаемого адреса видны старые параметры VPN или вручную введённый сервер, сохраните их перед дальнейшими действиями.

Смысл полей и команд описан у Microsoft: Get-NetIPConfiguration и Get-DnsClientServerAddress. Команды показывают конфигурацию, но не доказывают, что каждый указанный сервер отвечает.

Проверьте разрешение имени напрямую

В следующих примерах используется домен v3trov.pro. При своей диагностике замените его точным доменом проблемного сайта, без https://, пути и параметров страницы.

Resolve-DnsName -Name v3trov.pro -Type A -DnsOnly
Resolve-DnsName -Name v3trov.pro -Type AAAA -DnsOnly
nslookup v3trov.pro

Запрос A проверяет IPv4, AAAA — IPv6. Отсутствие AAAA у домена само по себе нормально: сайт не обязан публиковать IPv6-адрес. Ответ с A-записью показывает, что в этом тесте имя удалось разрешить. Он ещё не подтверждает возможность подключиться к полученному адресу.

Timeout означает, что ожидаемый ответ не получен вовремя. NXDOMAIN сообщает, что сервер считает запрошенное имя несуществующим. SERVFAIL означает неудачу обработки запроса. Такие ответы нельзя объединять в одну причину «не работает интернет». Сначала убедитесь, что домен введён без опечатки, затем сравните серверы.

Для проверки конкретного DNS добавьте -Server. Ниже 1.1.1.1 — пример публичного резолвера для теста внешнего домена, а не предложение постоянно переводить на него сеть:

Resolve-DnsName -Name v3trov.pro -Type A -Server 1.1.1.1 -DnsOnly
nslookup v3trov.pro 1.1.1.1

При проверке домашнего DNS подставьте адрес из своего вывода ipconfig. Если он не отвечает, а публичный сервер отвечает, проблема ближе к выбранному DNS или пути до него. Если оба не отвечают, остаются локальное подключение, маршрут, правила сети и ограничения доступа к внешним резолверам. Сам факт успеха одного теста не гарантирует одинаковый ответ всем приложениям.

Синтаксис и параметры доступны в документации Resolve-DnsName. Сравнивайте один домен и один тип записи, иначе результаты могут описывать разные задачи.

Отделите DNS от подключения к сайту

Если имя разрешается, проверьте соединение с HTTPS-портом:

Test-NetConnection -ComputerName v3trov.pro -Port 443
curl.exe -I --connect-timeout 10 --max-time 20 https://v3trov.pro/

TcpTestSucceeded: True означает успех TCP-подключения к выбранному адресу и порту. PingSucceeded может быть False, даже если TCP работает: сервер не обязан отвечать на ICMP. Для HTTPS ещё нужны TLS и ответ HTTP. Поэтому результат ping не заменяет проверку сайта.

Используйте curl.exe с расширением: в Windows PowerShell имя curl может быть псевдонимом другой команды. Параметр -I отправляет HEAD-запрос. Некоторые сайты запрещают HEAD, поэтому HTTP 403/405 не следует автоматически трактовать как отсутствие соединения. Если нужно, повторите GET с сохранением заголовков:

curl.exe -sS -D - -o NUL --connect-timeout 10 --max-time 20 https://v3trov.pro/

Когда DNS работает, а TCP не соединяется, дальнейшая задача — доступность адреса и маршрута. Когда TCP работает, но TLS или HTTP завершается ошибкой, установка другого DNS не является универсальным исправлением. Подробная проверка DNS, TCP, TLS и HTTPS с правильным SNI объясняет эти этапы отдельно.

Очистите кэш только после проверки

Если прямой запрос DNS возвращает правильный адрес, а приложения продолжают использовать старое состояние, можно очистить локальный кэш резолвера. В терминале с нужными правами выполните:

ipconfig /flushdns

Затем повторите запрос и открытие страницы. Очистка не ремонтирует недоступный DNS-сервер и не меняет адреса сетевого адаптера. Она полезна для устаревшего локального ответа, в том числе закэшированного отрицательного результата. Команда и её назначение описаны в справочнике ipconfig.

Не запускайте длинную последовательность release, reset и reboot без понимания результата каждого шага. Она может оборвать удалённое соединение и затруднить сравнение. В большинстве домашних случаев сначала достаточно прочитать конфигурацию, проверить имя и выполнить один обоснованный шаг.

Проверьте браузер, VPN и домашний DNS

Браузер может использовать защищённый DNS независимо от системного резолвера. Поэтому ситуация «PowerShell разрешает имя, браузер не открывает» требует проверки браузерной настройки DoH, прокси и самого HTTPS-соединения. Сравните второй браузер, не меняя одновременно системный DNS и параметры первого.

Если подключён VPN, посмотрите, какие DNS и маршруты он назначил. Для проверки отключайте только знакомое домашнее подключение и учитывайте, что доступ к внутренним адресам через него исчезнет. Разные пути могут давать разные ответы; полезно записать состояние «с VPN» и «без VPN» как два отдельных теста.

При AdGuard Home или Pi-hole запрос может останавливаться в домашнем фильтре либо не доходить до его upstream-сервера. Проверьте журнал: запрос отсутствует, заблокирован правилом или заканчивается timeout? Если фильтр работает на OpenWrt, сопоставьте порт 53 и настройки dnsmasq. Для такого сценария есть настройка AdGuard Home без конфликта с dnsmasq.

Когда менять DNS и как вернуть настройки

Временно менять DNS имеет смысл, когда проверка показала сбой именно текущего резолвера, а выбранный альтернативный сервер доступен из вашей сети. Сначала сохраните параметры активного адаптера и отметьте, были они автоматическими или ручными. В интерфейсе Windows откройте свойства текущего соединения и параметры назначения DNS; названия пунктов немного различаются между Windows 10 и 11.

После изменения повторите те же запросы и проверку приложения. Если стало хуже, верните сохранённые адреса или автоматическое назначение, которое использовалось раньше. Не оставляйте ручное значение лишь потому, что оно присутствовало в интернет-инструкции. Для локальных имён, корпоративного домена и DNS через VPN нужен соответствующий сервер.

Если не работает вся домашняя сеть, убедитесь, что у роутера установлено WAN-соединение, затем проверьте его DNS и журналы. Перезапуск может восстановить зависшее состояние, но сброс к заводским настройкам — отдельная операция с потерей конфигурации. Начальная диагностика его не требует.

Какие данные передать в поддержку

Подготовьте время сбоя, домен, тип соединения, результаты системного и явно выбранного DNS, TCP 443 и HTTPS. Укажите, повторяется ли проблема на втором устройстве и через другую сеть. Удалите из публикуемого вывода приватные адреса и настройки, которые не нужны для объяснения проблемы.

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