ERR_ADDRESS_UNREACHABLE — ошибка Chrome и других Chromium-браузеров, означающая, что браузер уже получил IP геолокацию сайта, но операционная система не нашла сетевого маршрута к этому адресу. DNS отработал успешно — недостижим сам IP. Чаще всего виноваты роутер, VPN, отсутствие IPv6-связности при наличии AAAA-записи или приватный IP в DNS.
В этой статье разбираем, что именно значит код net::ERR_ADDRESS_UNREACHABLE, чем он отличается от ERR_NAME_NOT_RESOLVED и ERR_CONNECTION_TIMED_OUT, какие причины встречаются на стороне пользователя, локальной сети и владельца сайта, как провести диагностику командами ping, tracert, curl и dig и как устранить проблему за 10–15 минут. Материал подходит и обычным пользователям, и администраторам сайтов.
Что значит ошибка ERR_ADDRESS_UNREACHABLE
В внутреннем списке сетевых ошибок Chromium код ERR_ADDRESS_UNREACHABLE имеет номер -109 и описывается как «The IP address is unreachable» — IP-адрес недостижим. Ключевой момент: к моменту появления этой ошибки DNS-резолвинг уже завершился успешно. Браузер точно знает, на какой IP идти, отправляет системный вызов connect() — и получает от операционной системы ответ EHOSTUNREACH или ENETUNREACH: «маршрута к хосту нет». Пакет физически некуда отправить: ни один интерфейс и ни один шлюз не знает пути к этому адресу.
Это принципиально отличает ошибку от соседних кодов. При ERR_NAME_NOT_RESOLVED проблема на шаг раньше: DNS вообще не вернул IP-адрес, и браузеру некуда подключаться. При ERR_CONNECTION_TIMED_OUT — на шаг позже: маршрут существует, пакеты уходят, но ответ не приходит в отведённое время. ERR_ADDRESS_UNREACHABLE сидит ровно посередине: имя разрешилось, а дороги к адресу нет.
Короткое правило: NAME_NOT_RESOLVED — «не знаю, куда идти», ADDRESS_UNREACHABLE — «знаю куда, но дороги нет», CONNECTION_TIMED_OUT — «дорога есть, но никто не отвечает».
Почему возникает ERR_ADDRESS_UNREACHABLE: основные причины
Проблемы роутера и локальной сети
Самая частая бытовая причина. Роутер завис, потерял WAN-соединение или раздаёт клиентам некорректный шлюз по DHCP — устройство получает IP, но пакеты за пределы локальной сети не уходят. Похожая картина возникает при вручную прописанном статическом IP с неправильным адресом шлюза или маской подсети: система честно сообщает, что маршрута к внешнему адресу нет.
VPN или прокси перехватил маршрут
VPN-клиенты добавляют в таблицу маршрутизации собственные записи и заворачивают трафик в туннель. Если туннель упал, а маршруты остались, либо split-tunneling настроен с ошибкой, часть адресов оказывается «в никуда»: система пытается отправить пакет через несуществующий интерфейс. То же относится к корпоративным прокси и антивирусам с функцией «защиты трафика» — они встраиваются в сетевой стек и после сбоя оставляют битые маршруты.
IPv6-паралич: AAAA-запись есть, а IPv6-связности нет
Классический сценарий для владельцев сайтов. В DNS-зоне опубликована AAAA-запись (IPv6-адрес), браузер пользователя предпочитает IPv6 и пытается подключиться по нему — но либо у провайдера пользователя нет IPv6-маршрутизации, либо на самом сервере IPv6-адрес назначен, а сервис на нём не слушает. Механизм Happy Eyeballs (RFC 8305) обычно откатывается на IPv4, но срабатывает он не всегда и не во всех приложениях, поэтому часть посетителей видит ERR_ADDRESS_UNREACHABLE, а часть — нет.
Приватный IP-адрес в DNS-записи
Если A-запись домена указывает на приватный адрес (192.168.x.x, 10.x.x.x, 172.16–31.x.x), сайт откроется только внутри той сети, где этот адрес существует. Для всех остальных пользователей интернета маршрута к приватному диапазону нет — ошибка гарантирована. Такое случается после копирования конфигурации с тестового стенда, при split-horizon DNS с перепутанными зонами или когда в панель DNS вписали внутренний IP сервера вместо публичного.
Файрвол и фильтрация у мобильных операторов
Агрессивный файрвол на компьютере или шлюзе может отбрасывать пакеты к конкретным подсетям, а некоторые мобильные операторы и публичные Wi-Fi-сети фильтруют диапазоны адресов или полностью блокируют IPv6-трафик. Симптом узнаваем: через мобильный интернет сайт не открывается, через домашний Wi-Fi — работает, или наоборот.
Причины, диагностика и исправление: сводная таблица
| Причина | Сторона | Как диагностировать | Как исправить |
|---|---|---|---|
| Роутер завис или потерял WAN | Клиент / сеть | Не открывается ни один сайт; ping 8.8.8.8 не проходит | Перезагрузить роутер, проверить кабель и статус WAN |
| VPN/прокси оставил битые маршруты | Клиент | Ошибка появилась после работы VPN; tracert обрывается на первом хопе | Отключить VPN/прокси, перезагрузить систему, сбросить сеть |
| IPv6-паралич (AAAA без связности) | Клиент + владелец | curl -6 -v падает, curl -4 -v работает | Пользователю — отключить IPv6; владельцу — убрать AAAA или поднять IPv6 |
| Приватный IP в A-записи | Владелец | dig A domain +short возвращает 192.168.x.x / 10.x.x.x | Заменить запись на публичный IP сервера |
| Неверный статический IP или шлюз | Клиент | ipconfig /all: шлюз пуст или из другой подсети | Включить DHCP или исправить адрес шлюза |
| Файрвол блокирует подсеть | Клиент / сеть | Ошибка только на части сайтов; в другой сети всё работает | Проверить правила файрвола и антивируса |
| Оператор фильтрует адреса или IPv6 | Сеть | Через другого провайдера или мобильную сеть сайт открывается | Сменить сеть, сообщить провайдеру, использовать IPv4 |
Как диагностировать ошибку: ping, tracert, curl и dig
Шаг 1. Проверьте достижимость адреса через ping
Сначала убедитесь, что интернет в принципе работает, затем проверьте конкретный сайт по IPv4 и IPv6 отдельно:
ping 8.8.8.8
ping example.com
ping -4 example.com
ping -6 example.comЕсли ping 8.8.8.8 не проходит — проблема в вашей сети или роутере, сайт ни при чём. Если IPv4-Ping инструмент работает, а IPv6 возвращает «General failure» или «Network is unreachable» — перед вами IPv6-паралич.
Шаг 2. Найдите место обрыва маршрута через tracert
# Windows
tracert example.com
# macOS / Linux
traceroute example.comОбрыв на первом хопе означает, что пакеты не доходят даже до роутера — ищите проблему в VPN, файрволе или настройках адаптера. Обрыв на втором-третьем хопе указывает на роутер или провайдера. Если трасса доходит почти до цели и обрывается в сети хостинга — проблема на стороне сервера, и это повод для анализа потерь пакетов и высокого пинга.
Шаг 3. Сравните IPv4 и IPv6 через curl
Это ключевой тест для выявления IPv6-паралича — принудительно выполните запрос по каждой версии протокола:
curl -4 -v https://example.com/
curl -6 -v https://example.com/Если curl -4 возвращает страницу, а curl -6 завершается ошибкой «Network is unreachable» — сайт публикует AAAA-запись, до которой часть клиентов дотянуться не может. Подробнее о различиях протоколов — в статье IPv4 vs IPv6.
Шаг 4. Проверьте DNS-записи через dig
dig A example.com +short
dig AAAA example.com +shortУбедитесь, что A-запись содержит публичный IP, а AAAA-запись — только если сервер реально доступен по IPv6. Любой адрес из диапазонов 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 в публичной зоне — ошибка конфигурации.
Как исправить ERR_ADDRESS_UNREACHABLE пользователю
- Перезагрузите роутер и устройство. Выключите роутер на 30 секунд, включите, дождитесь восстановления WAN-соединения. Это устраняет зависшие сессии и обновляет DHCP-аренду.
- Отключите VPN, прокси и «защиту трафика» антивируса. Проверьте сайт снова. Если ошибка ушла — переустановите VPN-клиент или обновите его: он оставлял битые маршруты.
- Сбросьте сетевой стек. В Windows выполните команды от администратора и перезагрузитесь:
netsh winsock reset
netsh int ip reset
ipconfig /release
ipconfig /renew
ipconfig /flushdns- Проверьте настройки адаптера. Если IP прописан вручную — включите автоматическое получение адреса (DHCP) или проверьте, что шлюз указан верно и находится в вашей подсети.
- Временно отключите IPv6. Если
curl -6падает, аcurl -4работает, отключите IPv6 в свойствах сетевого адаптера — это обходной путь, пока провайдер или владелец сайта не исправят связность. - Смените сеть. Откройте сайт через мобильный интернет или другой Wi-Fi. Если через другую сеть всё работает — проблема у вашего провайдера или в локальной сети, а не на сайте.
Что делать владельцу сайта
- Проверьте AAAA-записи. Если у сервера нет рабочего IPv6 (адрес не назначен, файрвол закрыт, веб-сервер не слушает на IPv6-интерфейсе) — удалите AAAA-запись из зоны. Публиковать AAAA «на будущее» нельзя: часть посетителей будет упираться в недостижимый адрес.
- Не публикуйте приватные IP. A- и AAAA-записи публичной зоны должны содержать только публичные адреса. Внутренние адреса выносите в отдельную внутреннюю зону (split-horizon DNS).
- Тестируйте с разных сетей и протоколов. Проверяйте сайт по IPv4 и IPv6, с мобильного оператора и из другого региона — ошибка часто воспроизводится только у части аудитории.
- Настройте мониторинг сайтов доступности. Регулярные проверки из нескольких регионов поймают проблему маршрутизации раньше, чем о ней напишут пользователи.
Как проверить сайт онлайн
Быстро проверить достижимость сайта извне можно инструментами Enterno: Ping-чекер покажет, отвечает ли сервер по ICMP и открыты ли TCP-порты с внешней точки наблюдения, а DNS-проверка выведет все A- и AAAA-записи домена — сразу видно и приватные адреса, и «осиротевшие» AAAA-записи без реальной IPv6-связности. Если извне сайт доступен, а у вас нет — проблема локальная.
Частые вопросы
Чем ERR_ADDRESS_UNREACHABLE отличается от ERR_NAME_NOT_RESOLVED?
При ERR_NAME_NOT_RESOLVED сбой происходит на этапе DNS: браузер не смог превратить доменное имя в IP-адрес и подключаться ему некуда. При ERR_ADDRESS_UNREACHABLE DNS отработал успешно, IP известен, но операционная система не нашла сетевого маршрута к этому адресу. Первая ошибка — про имена, вторая — про маршрутизацию пакетов.
Почему сайт открывается с телефона, но не с компьютера?
Телефон в мобильной сети использует другого провайдера, другие маршруты и часто другую версию IP-протокола. Если на компьютере ошибку вызывают VPN, файрвол, битые маршруты или отсутствие IPv6-связности у домашнего провайдера, мобильная сеть этих проблем не имеет. Это надёжный признак того, что сам сайт жив, а причина локальная.
Может ли VPN вызывать ERR_ADDRESS_UNREACHABLE?
Да, это одна из самых частых причин. VPN-клиент добавляет собственные записи в таблицу маршрутизации, и после обрыва туннеля или некорректного отключения они могут остаться: система пытается отправить пакеты через уже несуществующий интерфейс. Отключите VPN, перезагрузите компьютер и при повторении проблемы переустановите клиент.
Что такое IPv6-паралич и как его обнаружить?
Это ситуация, когда у домена есть AAAA-запись, браузер предпочитает IPv6, но реальной IPv6-связности между клиентом и сервером нет. Обнаруживается сравнением curl -4 -v и curl -6 -v: если IPv4-запрос проходит, а IPv6 падает с «Network is unreachable» — диагноз подтверждён. Лечится удалением AAAA или настройкой IPv6 на сервере.
Ошибка возникает только у части пользователей сайта. Что проверить владельцу?
Сначала выполните dig A и dig AAAA для домена: убедитесь, что в зоне нет приватных адресов и «мёртвых» AAAA-записей. Затем проверьте сайт по обоим протоколам с разных сетей и регионов. Частичная недоступность почти всегда означает проблему с IPv6 или гео-зависимой маршрутизацией, а не с самим веб-сервером.
Источники: список сетевых ошибок Chromium net_error_list.h и документация MDN Web Docs по HTTP и сетевому стеку.