ERR_ADDRESS_UNREACHABLE, No route to host и Network is unreachable: когда до сервера нет маршрута

Chrome пишет ERR_ADDRESS_UNREACHABLE, curl и ssh — «No route to host» или «Network is unreachable», ping — «Destination Host Unreachable». Это одна ситуация с тремя именами: пакет либо некуда отправить, либо его вернул узел с запретом. Разбираем, откуда берётся каждое сообщение, почему firewalld отдаёт «No route to host» вместо «Connection refused» и какими командами найти виновника.

ERR_ADDRESS_UNREACHABLE (код -109 в Chromium), «No route to host» (EHOSTUNREACH, errno 113 в Linux) и «Network is unreachable» (ENETUNREACH, errno 101) — три формы одной ошибки: у отправителя нет маршрута до адреса назначения, либо пакет по пути упёрся в узел, который вернул ICMP Destination Unreachable. Браузер показывает первое, ядро возвращает второе или третье, а причина сидит на одном из трёх уровней: в таблице маршрутизации клиента, у промежуточного маршрутизатора или в файрволе самого сервера, отвечающем ICMP-запретом. В отличие от ERR_CONNECTION_REFUSED сервер ничего не отклонял на уровне TCP, в отличие от ERR_CONNECTION_TIMED_OUT ошибка приходит сразу, а не через десятки секунд.

Чем отличаются три сообщения: браузер, ядро и ICMP

«Network is unreachable» ядро возвращает до отправки пакета: в таблице маршрутизации нет ни одной записи под адрес назначения. «No route to host» приходит после: маршрут был, пакет ушёл, но сосед не ответил на ARP или вернулся ICMP «host unreachable» либо «administratively prohibited». Chromium, по данным файла net_errors_posix.cc, сворачивает EHOSTUNREACH, EHOSTDOWN, ENETUNREACH и EAFNOSUPPORT в один код -109, а на Windows туда же попадают WSAEHOSTUNREACH и WSAENETUNREACH. Сводка на сентябрь 2026:

Как ICMP Destination Unreachable превращается в errno

Маршрутизатор, который не может доставить пакет, возвращает отправителю ICMP тип 3 с кодом причины — так устроен RFC 792, а RFC 1812 уточняет правила для маршрутизаторов. Ядро Linux находит по этому пакету сокет и переводит код в errno по таблице icmp_err_convert из net/ipv4/icmp.c; для сокета в состоянии SYN_SENT вызов connect() завершается сразу, без повторных SYN.

Практический вывод: «No route to host» в Linux — это и код 1 (хоста нет), и коды 10 и 13 (хост есть, файрвол запретил). Различить их можно по дампу или по выводу ping: код 13 печатается как «Packet filtered», код 10 — как «Destination Host Prohibited». По IPv6 запрет выглядит иначе — «Permission denied», потому что ICMPv6 код 1 ядро переводит в EACCES.

Что проверить на своём компьютере за две минуты

Первая команда — ip route get с адресом сайта: она отвечает, знает ли ядро, куда слать пакет, и через какой интерфейс. Вторая — тот же запрос через curl -4 и curl -6 по отдельности: половина «необъяснимых» ERR_ADDRESS_UNREACHABLE — это IPv6, который у клиента есть на бумаге, но не работает.

$ ip route get 203.0.113.10
# пример вывода: маршрут есть, пойдёт через шлюз 192.168.1.1
203.0.113.10 via 192.168.1.1 dev wlan0 src 192.168.1.23 uid 1000

$ ip route get 203.0.113.10
# пример вывода: маршрута нет вообще — default route пропал
RTNETLINK answers: Network is unreachable

$ ip route show default
# пусто — DHCP не выдал шлюз или его снёс VPN-клиент

$ ip -6 route show default
# пусто при наличии глобального IPv6-адреса — IPv6 «полуживой»

Сценарий с IPv6 — самый частый дома и в офисах после смены роутера: сайт публикует AAAA-запись, у клиента есть глобальный IPv6-адрес от router advertisement, но выхода в IPv6-интернет нет. Браузеры реализуют Happy Eyeballs (RFC 8305): предпочитают IPv6, при неудаче переключаются на IPv4 с рекомендуемой задержкой 250 мс. Если IPv6-попытка падает мгновенно с ENETUNREACH, переключение почти незаметно; если пакеты уходят в никуда — страница открывается с задержкой; в программах без Happy Eyeballs (curl без флагов, скрипты) ошибка вылезает наружу.

$ curl -6 -sv https://example.com/ -o /dev/null
# пример вывода: по IPv6 маршрута нет
*   Trying [2001:db8::10]:443...
* Immediate connect fail for 2001:db8::10: Network is unreachable
curl: (7) Failed to connect to example.com port 443

$ curl -4 -sv https://example.com/ -o /dev/null
# пример вывода: по IPv4 всё в порядке
*   Trying 203.0.113.10:443...
* Connected to example.com (203.0.113.10) port 443

Разница между «-6 не работает, -4 работает» и «оба не работают» определяет всё дальнейшее: в первом случае чините IPv6 у себя, во втором — идёте по таблице причин. Полезно прогнать и ping: по формулировке ответа видно, кто именно отказал.

$ ping -c 3 203.0.113.10
# пример вывода 1: маршрута нет — пакет не отправлен
ping: connect: Network is unreachable

# пример вывода 2: маршрут в локалку есть, но хост не отвечает на ARP.
# «From» — ваш собственный адрес: ядро сдалось после ~3 с
From 192.168.1.23 icmp_seq=1 Destination Host Unreachable

# пример вывода 3: отказал промежуточный маршрутизатор 10.20.0.1
From 10.20.0.1 icmp_seq=1 Destination Net Unreachable

# пример вывода 4: ICMP код 13 — файрвол на 203.0.113.10 или перед ним
From 203.0.113.10 icmp_seq=1 Packet filtered

$ ip neigh show 192.168.1.1
# пример вывода: шлюз не отвечает на ARP — проблема в локальной сети
192.168.1.1 dev wlan0  FAILED

Причины на клиенте, в сети и на сервере

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

Где обрывается путь, показывает трассировка: в mtr и traceroute пропавший маршрут выглядит как узел с пометкой !N (net unreachable), !H (host unreachable) или !X (admin prohibited), после которого хопов нет. Как читать mtr и WinMTR целиком — в статье про mtr и WinMTR, база — в разборе трассировки маршрута.

$ mtr -rwzc 20 203.0.113.10
# пример вывода: 4-й хоп у провайдера возвращает net unreachable —
# дальше префикс сервера никому не известен
HOST: laptop            Loss%  Snt  Last  Avg  Best  Wrst StDev
  1. AS???  192.168.1.1  0.0%   20   1.1  1.2   0.9   2.4   0.3
  2. AS64500 100.64.0.1  0.0%   20   4.8  5.1   4.2   9.7   1.1
  3. AS64500 10.20.0.1   0.0%   20   6.3  6.9   5.8  12.0   1.4
  4. AS64500 10.20.0.9 !N 0.0%  20   6.5  6.7   6.0   8.1   0.5

Почему firewalld отвечает No route to host вместо Connection refused

Потому что firewalld по умолчанию отклоняет пакеты не TCP-сбросом и не ICMP port unreachable, а ICMP «host prohibited». В исходниках firewalld (файл ipXtables.py) плейсхолдер %%REJECT%% раскрывается в REJECT --reject-with icmp-host-prohibited для IPv4 и icmp6-adm-prohibited для IPv6; бэкенд nftables использует reject with icmpx type admin-prohibited. Оба варианта ядро клиента переводит в EHOSTUNREACH, и администратор, только что поднявший nginx на CentOS Stream, Rocky, AlmaLinux или Fedora, видит «No route to host» при живом сервере и рабочей сети.

# На сервере: что открыто в активной зоне
$ sudo firewall-cmd --list-all
# пример вывода: 443 не открыт — всё, кроме ssh и dhcpv6, отбивается
public (active)
  target: default
  interfaces: eth0
  services: cockpit dhcpv6-client ssh
  ports:

# Как это выглядит в правилах (бэкенд iptables)
$ sudo iptables -L INPUT -n | tail -2
# пример вывода
ACCEPT  tcp  --  0.0.0.0/0  0.0.0.0/0  tcp dpt:22 ctstate NEW
REJECT  all  --  0.0.0.0/0  0.0.0.0/0  reject-with icmp-host-prohibited

# Бэкенд nftables (по умолчанию начиная с firewalld 0.6)
$ sudo nft list chain inet firewalld filter_IN_public | tail -2
# пример вывода
    reject with icmpx admin-prohibited

# Исправление
$ sudo firewall-cmd --permanent --add-service=https
$ sudo firewall-cmd --reload

Обратная ситуация тоже встречается: REJECT без параметра отправляет icmp-port-unreachable, и клиент получает «Connection refused», хотя порт слушается — админ ищет упавший сервис, а виноват файрвол. Чем refused отличается от unreachable в деталях — в статье про ERR_CONNECTION_REFUSED.

REJECT, DROP и ICMP-prohibited: один файрвол — три разные ошибки

Одно и то же запрещающее правило показывает клиенту REFUSED, TIMED_OUT или «No route to host» в зависимости от того, что файрвол отправляет в ответ. Это единственная причина, по которой три разные ошибки Chrome могут иметь одно исправление — открыть порт.

Windows и macOS: route print, netstat -rn и «Общий сбой»

На Windows аналог ip route — route print, на macOS — netstat -rn; в обоих ищут маршрут по умолчанию и шлюз рядом с ним. В русской Windows «General failure» показывается как «Общий сбой» (стеку нечем отправить пакет: нет маршрута или интерфейса, чаще по IPv6), а «Destination host unreachable» — как «Заданный узел недоступен».

C:\> route print -4 | findstr /C:"0.0.0.0"
# пример вывода: маршрут по умолчанию через 192.168.1.1, метрика 25
          0.0.0.0          0.0.0.0      192.168.1.1     192.168.1.23     25
# строки с 0.0.0.0 нет — шлюз не получен

C:\> ping 203.0.113.10
# пример вывода: ответ от собственного адреса — шлюз не отвечает на ARP
Ответ от 192.168.1.23: Заданный узел недоступен.

C:\> ping -6 example.com
# пример вывода: IPv6-адрес есть, маршрута нет
PING: сбой передачи. Общий сбой.

$ netstat -rn -f inet | head -4
# macOS, пример вывода: default через 192.168.1.1 на en0
Destination   Gateway        Flags   Netif
default       192.168.1.1    UGScg   en0

Симптом → команда → что увидите → вывод

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

Как понять, пропал маршрут у всех или только у части сети

Разовая проверка с одного компьютера не отличает файрвол на сервере (недоступен для всех), потерянный префикс у магистрали (недоступен для региона) и IPv6 у вас дома (недоступен только вам). Ответ даёт одновременная проверка из нескольких сетей: не отвечают отовсюду — ищите на сервере и у хостера; из части точек — у магистрального оператора или в регионе.

Пруфен выполняет проверку ping и проверку TCP-порта с интервалом от 2 минут из 20 точек мониторинга — 17 в России, а также Минск, Астана и Испания. Во вкладке «По локациям» видно, откуда маршрут пропал: красная строка по всем точкам — сервер или его аплинк, красные строки в двух-трёх городах одного оператора — сетевой инцидент, о котором нужно писать не хостеру, а провайдеру. Список точек и их адреса — на странице локаций мониторинга; адреса пригодятся, чтобы разрешить их в firewalld и не получить «Packet filtered» от собственного сервера.

Частые вопросы

Чем ERR_ADDRESS_UNREACHABLE отличается от ERR_CONNECTION_REFUSED?

REFUSED (-102) означает, что SYN дошёл до машины и она ответила RST или ICMP port unreachable: маршрут в порядке, закрыт порт. UNREACHABLE (-109) — пакет либо не был отправлен из-за отсутствия маршрута, либо вернулся с ICMP host/net unreachable или administratively prohibited. Файрвол может отправить любой из этих ответов, поэтому обе ошибки на свежем сервере начинают проверять с firewall-cmd --list-all.

Почему после включения firewalld появляется No route to host, хотя сервер пингуется?

Зона public по умолчанию пропускает ICMP echo, ssh и dhcpv6-client, а всё остальное отклоняет через REJECT --reject-with icmp-host-prohibited. Ping проходит, а на SYN к порту 443 сервер отвечает ICMP типа 3 с кодом 10 или 13, что ядро клиента переводит в EHOSTUNREACH. Добавьте сервис в зону: firewall-cmd --permanent --add-service=https, затем --reload. Это особенность именно firewalld: ufw в Debian и Ubuntu по умолчанию использует DROP, и то же самое правило там даст таймаут.

Ошибка только по IPv6 — что делать?

Как пользователь: проверьте ip -6 route show default; при пустом выводе и наличии глобального адреса роутер раздаёт префикс без аплинка — обновите прошивку, отключите IPv6 на роутере или временно на адаптере. Как владелец сервера: публикуйте AAAA-запись только при рабочем IPv6 (ping -6 и curl -6 с внешней машины) и откройте порт в ip6tables или firewalld отдельно — правила для двух семейств независимы. Сломанный IPv6 на сервере хуже отсутствующего: часть клиентов получит задержку в каждом соединении, а клиенты без Happy Eyeballs — ошибку.

Помогает ли перезагрузка роутера?

Помогает в трёх случаях: зависший роутер не отвечает на ARP, переполнена его таблица соседей или NAT, роутер раздал некорректный IPv6-префикс после переподключения к провайдеру. Не помогает, если маршрут потерян у провайдера, на сервере стоит firewalld без открытого порта или в hosts прописан неверный адрес. Проверка перед перезагрузкой занимает десять секунд: ping шлюза и ip neigh show — если шлюз отвечает и запись REACHABLE, роутер ни при чём.