Артём Савельев 
DNS_PROBE_FINISHED_NO_INTERNET: что значит и как исправить на Windows, macOS, Android и роутере
Chrome пишет «Нет подключения к интернету», хотя Wi-Fi подключён, а мессенджер работает. Разбираем, как браузер приходит к этому вердикту, чем NO_INTERNET отличается от NXDOMAIN и BAD_CONFIG, где искать причину и какие команды чинят её на Windows, macOS, Linux, Android и роутере. Плюс Linux-аналог — «Temporary failure in name resolution».
DNS_PROBE_FINISHED_NO_INTERNET — вердикт диагностики Chrome: браузер не смог получить IP-адрес сайта у своего DNS-резолвера и затем не дождался ответа от публичного резолвера Google. Это ошибка между вашим устройством и его DNS-сервером, а не на сайте. Сайт при этом может работать для всех остальных: с вашего устройства DNS-запросы никуда не доходят — из-за настроек адаптера, роутера, VPN, антивируса или сбоя у провайдера.
Как Chrome приходит к вердикту NO_INTERNET
Сначала происходит обычная ошибка резолвинга, потом — проба. Любая внутренняя DNS-ошибка Chromium (таймаут -803 ERR_DNS_TIMED_OUT, испорченный ответ -800 ERR_DNS_MALFORMED_RESPONSE, SERVFAIL -817 ERR_DNS_SERVER_FAILURE, REFUSED -819) сводится функцией HostResolver::SquashErrorCode к одному коду -105 ERR_NAME_NOT_RESOLVED. Именно на -105, и только на него, страница ошибки запускает DNS-пробу (net_error_tab_helper.cc). Код -106 ERR_INTERNET_DISCONNECTED пробу не запускает: это сигнал ОС «сети нет», и Chrome сразу показывает динозавра.
Проба, по данным dns_probe_service_factory.cc и dns_probe_runner.cc на сентябрь 2026: Chrome параллельно резолвит A-запись google.com через текущую DNS-конфигурацию системы и напрямую через 8.8.8.8 и 8.8.4.4 по UDP/53 с выключенным Secure DNS. Одна попытка, без кеша, ожидание 1 секунда, результат кешируется 5 секунд. Два исхода сводятся в вердикт:
| Код на странице ошибки | Что показала проба | Что это значит | Чья сторона |
|---|---|---|---|
| DNS_PROBE_FINISHED_NO_INTERNET | Свой резолвер не помог, 8.8.8.8 не ответил вовсе | DNS-запросы не выходят из вашей сети | Устройство, роутер, провайдер, VPN |
| DNS_PROBE_FINISHED_NXDOMAIN | Свой резолвер отдал IP для google.com | DNS работает, проблема в самом домене | Сайт или опечатка в адресе |
| DNS_PROBE_FINISHED_BAD_CONFIG | Свой резолвер не помог, 8.8.8.8 ответил корректно | Интернет есть, сломан прописанный DNS-сервер | Настройки устройства или роутера |
| DNS_PROBE_FINISHED_BAD_SECURE_CONFIG | То же при Secure DNS «только выбранный провайдер» | Недоступен DoH-сервер из настроек Chrome | Настройки Chrome |
| DNS_PROBE_FINISHED_INCONCLUSIVE | 8.8.8.8 ответил, но с ошибкой или пустым ответом | DNS перехватывают: captive portal, файрвол | Сеть, в которой вы находитесь |
| DNS_PROBE_STARTED | Проба ещё идёт | Через секунды сменится одним из FINISHED | — |
| ERR_NAME_NOT_RESOLVED | Проба не запускалась | Отключена политикой AlternateErrorPagesEnabled или ошибка не в главной вкладке | Любая |
Два вывода. Первый: NO_INTERNET появляется и при живом интернете, если сеть не пропускает UDP на 8.8.8.8 — так ведут себя корпоративные файрволы, разрешающие только внутренний DNS. Второй: если упали NS-серверы сайта, посетители увидят не NO_INTERNET, а DNS_PROBE_FINISHED_NXDOMAIN — их собственный резолвер исправен и google.com отдаёт. NO_INTERNET массово «от сайта» не бывает.
Где живёт причина: устройство, роутер, провайдер или VPN
Причина почти всегда в первых метрах пути DNS-запроса: адаптер, роутер и его DHCP, туннель VPN. Сайт в списке последний, и его вина проявляется другим кодом.
| Где причина | Как часто | Типичный сценарий | Как проверить |
|---|---|---|---|
| Устройство | Очень часто | Прописан DNS, которого больше нет; сбитый Winsock; DNS-фильтр антивируса; Private DNS на Android с недоступным хостом | Другое устройство в той же сети открывает сайт |
| VPN, прокси, антивирус | Часто | Туннель упал, а DNS остался внутри него; kill-switch; фильтр перехватывает порт 53 | Отключить VPN и защиту, повторить |
| Wi-Fi / роутер | Часто | Роутер завис как DNS-прокси; DHCP выдал старый адрес; captive portal гостевой сети | Все устройства в сети без DNS, с мобильного интернета всё открывается |
| Провайдер | Иногда | Упали резолверы оператора; авария на канале при живом Wi-Fi | ping 8.8.8.8 и dig @1.1.1.1: отвечают — канал жив, лежит только DNS провайдера |
| Сайт | Практически никогда | Отказ NS домена даёт NXDOMAIN или SERVFAIL, а не NO_INTERNET | dig @8.8.8.8 домен; dig @ns1 домена |
Как за две минуты понять, проблема у меня или у всех
Три проверки: другой резолвер, другое устройство, другая сеть. Открывается с телефона через мобильный интернет — причина в вашей сети или устройстве; не открывается ниоткуда с кодом NO_INTERNET — оба устройства за одним неисправным роутером или VPN.
# 1. Жив ли канал вообще (по IP, без DNS) ping -c 3 8.8.8.8 # 2. Отвечает ли системный резолвер и публичный dig example.com +short dig @1.1.1.1 example.com +short dig @77.88.8.8 example.com +short # пример вывода: системный резолвер молчит — это и есть NO_INTERNET ;; communications error to 192.168.1.1#53: timed out ;; no servers could be reached # пример вывода: публичный отвечает — канал жив, сломан только DNS $ dig @1.1.1.1 example.com +short 93.184.215.14
Ping до 8.8.8.8 проходит, а dig без сервера падает по таймауту — интернет есть, DNS нет. Ping не проходит — проблема ниже DNS: роутер, кабель, провайдер. Оба dig отвечают, а Chrome ругается — смотрите Secure DNS или DNS-фильтр антивируса: dig ходит мимо них. На Windows вместо dig — nslookup example.com 1.1.1.1; «DNS request timed out. timeout was 2 seconds» — тот же таймаут.
Как исправить на Windows
Порядок: сброс кеша DNS, переполучение адреса по DHCP, сброс Winsock и стека IP, затем явные публичные DNS на адаптере. Первые три шага обратимы; смена DNS помогает, когда сломан резолвер провайдера или роутера. PowerShell — от имени администратора.
# Шаг 1. Кеш DNS и аренда DHCP
ipconfig /flushdns
ipconfig /release
ipconfig /renew
# Шаг 2. Сброс Winsock и IP-стека (после — перезагрузка)
netsh winsock reset
netsh int ip reset
# Шаг 3. Какие DNS сейчас прописаны
Get-DnsClientServerAddress -AddressFamily IPv4
# Шаг 4. Явные публичные DNS на адаптере (имя — из шага 3)
Set-DnsClientServerAddress -InterfaceAlias "Wi-Fi" `
-ServerAddresses ("8.8.8.8","1.1.1.1")
# Вернуть получение DNS по DHCP
Set-DnsClientServerAddress -InterfaceAlias "Wi-Fi" -ResetServerAddresses
# Проверка
nslookup example.com 8.8.8.8
Если после сброса Winsock ошибка вернулась через день — ищите программу, которая снова встраивает в стек свой фильтр: антивирус, родительский контроль, VPN-клиент с защитой DNS. В Windows 11 проверьте и «Шифрование DNS» в свойствах адаптера: режим «только зашифрованный» с недоступным DoH-сервером даёт ту же картину.
Как исправить на macOS
На macOS резолвингом занимается mDNSResponder, действующую конфигурацию показывает scutil, DNS сервиса меняет networksetup — без перезагрузки.
# Какие DNS реально использует система scutil --dns | grep nameserver # Сброс кеша резолвера sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder # Текущие DNS сервиса Wi-Fi и замена на публичные networksetup -getdnsservers Wi-Fi sudo networksetup -setdnsservers Wi-Fi 8.8.8.8 1.1.1.1 # Вернуть DNS от DHCP (слово Empty — буквально) sudo networksetup -setdnsservers Wi-Fi Empty # Проверка мимо системного резолвера и через него dig @8.8.8.8 example.com +short dig example.com +short
Если scutil показывает nameserver 10.x или 100.64.x, которого нет в настройках, — это DNS от VPN-профиля: отключите VPN или удалите профиль.
Как исправить на Android, iPhone и роутере
На мобильных два характерных источника: Private DNS (Android 9 и новее) с недоступным хостом и сохранённая Wi-Fi-сеть с устаревшими параметрами. На роутере — зависший DNS-прокси или DNS провайдера, полученные по DHCP и переставшие отвечать. В гостевом Wi-Fi до авторизации в captive portal DNS перехватывается — откройте любой http://-сайт и пройдите вход.
| Платформа | Что проверить | Как исправить |
|---|---|---|
| Android | Настройки → Сеть и интернет → Частный DNS: режим «Имя хоста провайдера» с неотвечающим хостом ломает весь DNS | Переключить на «Автоматически» или «Выкл.»; в Chrome проверить «Использовать безопасный DNS»; «Сброс настроек сети» как последний шаг |
| iPhone / iPad | Настройки → Wi-Fi → (i) → Настройка DNS; профили VPN и DNS в разделе «VPN и управление устройством» | «Забыть эту сеть»; DNS вручную 8.8.8.8, 1.1.1.1 или 77.88.8.8; удалить профиль DNS от удалённого приложения |
| Роутер | Раздел WAN: какие DNS получены от провайдера; раздел LAN/DHCP: какой DNS выдаётся клиентам (обычно адрес самого роутера) | Перезагрузить; в WAN прописать 8.8.8.8 и 1.1.1.1 (или 77.88.8.8 и 77.88.8.1); обновить прошивку, если DNS-прокси зависает регулярно |
Роутер проверяйте, когда ошибка на всех устройствах сразу, а с мобильного интернета всё открывается: смена DNS в разделе WAN чинит всех клиентов сети.
Linux: «Temporary failure in name resolution» — та же ошибка другими словами
«Temporary failure in name resolution» — строка glibc для кода EAI_AGAIN функции getaddrinfo: резолвер не ответил или вернул временную ошибку. Это ровно NO_INTERNET/BAD_CONFIG из Chrome: домен не «не существует», а спросить было не у кого. По тексту сообщения видно, что случилось:
| Сообщение | Код glibc | Что произошло | Аналог в Chrome |
|---|---|---|---|
| Temporary failure in name resolution | EAI_AGAIN | Резолвер недоступен, таймаут или SERVFAIL; resolv.conf пуст или указывает в никуда | NO_INTERNET / BAD_CONFIG |
| Name or service not known | EAI_NONAME | Резолвер ответил: такого имени нет (NXDOMAIN) | NXDOMAIN |
| No address associated with hostname | EAI_NODATA | Имя есть, но A/AAAA-записи нет | ERR_NAME_NOT_RESOLVED |
Сначала выясните, кто отвечает за DNS на машине: ls -l /etc/resolv.conf. Симлинк на /run/systemd/resolve/stub-resolv.conf означает systemd-resolved со stub-адресом 127.0.0.53, обычный файл — что его пишет NetworkManager, dhclient, cloud-init или никто.
$ ping -c 1 example.com
ping: example.com: Temporary failure in name resolution
# Кто управляет resolv.conf и что в нём
ls -l /etc/resolv.conf
cat /etc/resolv.conf
# systemd-resolved: upstream-серверы по интерфейсам
resolvectl status
resolvectl query example.com
# пример вывода: интерфейс без DNS-серверов — причина найдена
Link 2 (eth0)
Current Scopes: none
Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS
# Быстрое лечение: назначить DNS интерфейсу и сбросить кеш
sudo resolvectl dns eth0 1.1.1.1 8.8.8.8
sudo resolvectl flush-caches
# Постоянно (Ubuntu с netplan): nameservers в /etc/netplan/*.yaml
# nameservers:
# addresses: [1.1.1.1, 8.8.8.8]
sudo netplan apply
# Проверка через системный резолвер
getent hosts example.com
Типовые причины на VPS: после миграции или смены IP resolv.conf ссылается на резолверы прежнего дата-центра; cloud-init перезаписал файл пустым; удалён симлинк, и systemd-resolved больше не обновляет файл; исходящий UDP/53 закрыт файрволом (sudo iptables -S OUTPUT). Таймауты glibc по resolv.conf(5) — 5 секунд на попытку и 2 попытки: при мёртвом первом nameserver каждое обращение к имени висит 10 секунд, прежде чем перейти ко второму.
Docker: контейнер без DNS при работающем хосте
Контейнер не видит DNS хоста, если хост резолвит через 127.0.0.53: внутри контейнера этот адрес указывает на сам контейнер. По документации Docker, контейнеры в сети bridge получают копию resolv.conf хоста, в пользовательских сетях — встроенный DNS 127.0.0.11, пересылающий запросы серверам хоста. Если единственный nameserver хоста — 127.0.0.53, Docker берёт /run/systemd/resolve/resolv.conf; если после фильтрации loopback серверов не осталось — подставляет 8.8.8.8 и 8.8.4.4. Схема ломается, когда и этот файл пуст или файрвол хоста режет трафик из docker0 наружу.
# Что видит контейнер
docker run --rm alpine cat /etc/resolv.conf
# Разовый обход: явный DNS для контейнера
docker run --rm --dns 1.1.1.1 --dns 8.8.8.8 alpine nslookup example.com
# Постоянно для всех контейнеров: /etc/docker/daemon.json
{
"dns": ["1.1.1.1", "8.8.8.8"]
}
sudo systemctl restart docker
Когда «виноват сайт» и что делать его владельцу
Сайт не может вызвать NO_INTERNET у посетителя: проба Chrome проверяет DNS через google.com, сайт в ней не участвует. Один посетитель со скриншотом — у него сломан DNS. Пишут многие от одного оператора — упал резолвер оператора, это тоже вне вашего контроля.
Иное дело, когда в жалобах NXDOMAIN или сайт не открывается ни у кого. Тогда проверяйте зону: не истёк ли домен, отвечают ли авторитативные NS, совпадает ли A-запись с адресом сервера. Два запроса: к публичному резолверу и напрямую к своему NS.
# Кто авторитативен за домен и что отвечает публичный резолвер dig NS example.com +short dig @8.8.8.8 example.com A # Напрямую к своему NS, без рекурсии dig @ns1.example.com example.com A +norecurse # пример вывода: NS не отвечает — посетители получат SERVFAIL/NXDOMAIN ;; communications error to 198.51.100.53#53: timed out ;; no servers could be reached # пример вывода: NS жив, зона в порядке (флаг aa — авторитативный ответ) ;; flags: qr aa; QUERY: 1, ANSWER: 1 example.com. 3600 IN A 203.0.113.10
Разовый dig показывает один резолвер в один момент. Чтобы отличить «лежит NS домена» от «лежит DNS у части операторов», нужны запросы из разных сетей: проверка DNS в Пруфене опрашивает записи домена с внешних точек мониторинга (их 20 — в России, Беларуси, Казахстане и Испании, список на странице локаций) и фиксирует, отвечают ли авторитетные серверы домена и совпадают ли записи с ожидаемыми. Как устроена цепочка резолвинга — в статье «Как работает DNS»; почему после исправления записей часть посетителей ещё видит старый ответ — в материале про кеш DNS.
Пруфен держит для домена две независимые проверки: HTTP-доступность с интервалом от 2 минут и DNS-проверку, которая показывает, отвечают ли NS домена и какие записи они отдают. Если посетители пишут про ошибку резолвинга, по вкладке «По локациям» видно, отвечает ли зона из всех точек (тогда проблема у пользователей) или не отвечает ниоткуда. Уведомление приходит в Email, Telegram или Макс, когда проверка перестала проходить, и второе — когда всё восстановилось; если ресурс так и не поднялся, подключается голосовой звонок. Бесплатный план включает 5 проверок.
Частые вопросы
Виноват ли сайт, если я вижу DNS_PROBE_FINISHED_NO_INTERNET?
Нет. Вердикт означает, что с вашего устройства не ответил даже публичный резолвер Google на запрос google.com; адрес сайта в проверке не участвует. Неисправность сайта или его NS Chrome показывает как DNS_PROBE_FINISHED_NXDOMAIN или ERR_NAME_NOT_RESOLVED. Проверьте другое устройство и мобильный интернет: ошибка исчезнет там, где другой DNS.
Помогает ли смена DNS на 8.8.8.8 или 1.1.1.1?
Помогает, когда сломан именно резолвер — провайдера, роутера или оставленный VPN, — а канал жив: ping 8.8.8.8 проходит и dig @8.8.8.8 отвечает, хотя без указания сервера всё висит. Если не проходит и ping по IP, смена DNS ничего не изменит. Прописанный вручную DNS переживёт смену провайдера и сам станет проблемой, если адрес перестанет отвечать.
Почему ошибка только по Wi-Fi, а по кабелю или через телефон всё открывается?
DNS настраивается на каждый интерфейс отдельно. У Wi-Fi-адаптера может быть свой статический DNS, устаревший профиль сети или DNS-прокси роутера, зависший только для беспроводных клиентов. Смотрите настройки именно этого адаптера (Get-DnsClientServerAddress, networksetup -getdnsservers Wi-Fi, resolvectl status) и сравните с интерфейсом, через который всё работает.
Что такое Secure DNS в Chrome и может ли он мешать?
Secure DNS — DNS-over-HTTPS, встроенный в Chrome с версии 83 (май 2020). В режиме «с текущим провайдером» браузер шифрует запросы, только если резолвер есть в списке поддерживающих DoH, и при сбое откатывается на обычный DNS — мешать он не может. В режиме «с другим провайдером» отката нет: если DoH-сервер недоступен из вашей сети, Chrome покажет DNS_PROBE_FINISHED_BAD_SECURE_CONFIG, а остальные программы будут работать. Настройка — в разделе Конфиденциальность и безопасность → Безопасность; на управляемых устройствах и при родительском контроле Chrome отключает её сам.