Diagnosticando "No route to host"

2026-06-05 Tempo de leitura: Cerca de 11 min Dificuldade: Intermediario

O que significa "No route to host"?

Conclusao: Nao ha caminho utilizavel para entregar pacotes ao host. O kernel — ou um dispositivo no caminho — decidiu que o destino e inalcancavel, e EHOSTUNREACH e retornado. Assim como refused, falha imediatamente.

No route to host aparece quando algo no caminho ate o destino decide que nao pode entregar o pacote. No nivel de chamada de sistema, connect() retorna EHOSTUNREACH, que as aplicacoes exibem como "No route to host".

$ ssh user@192.0.2.10
ssh: connect to host 192.0.2.10 port 22: No route to host

$ curl http://192.0.2.10/
curl: (7) Failed to connect to 192.0.2.10 port 80 after 2 ms: No route to host

O veredito pode vir de tres lugares: (1) o kernel local decide que nao ha nenhuma rota, (2) um host no mesmo segmento nao responde ao ARP, ou (3) um roteador ou firewall no caminho retorna um ICMP host-unreachable / host-prohibited. Em todos os casos, a resposta retorna em poucos milissegundos, o que torna seu comportamento muito diferente de um timeout silencioso.

Pre-requisitos

SO: Ubuntu / um Linux tipico (comando ip = iproute2)
Destino: qualquer host que voce deseja alcancar por IP
Assumimos que voce pode ler as tabelas de roteamento e ARP sem sudo

Como e diferente de refused e timeout?

Conclusao: Refused significa "chegou mas foi rejeitado na porta", timeout significa "nenhuma resposta", e No route to host significa "nao ha caminho para entregar / o host nao pode ser alcancado". Mesma conexao falhada, ponto de partida completamente diferente.

Erros de conexao se dividem em tres familias que falham em camadas diferentes. Identifique qual voce tem primeiro.

Erro	O que retorna	Camada da causa
Connection refused	TCP RST (instantaneo)	Servico / porta (L4, aplicacao)
Connection timed out	Sem resposta (longa espera)	DROP / caminho silencioso (L3-L4)
No route to host	ICMP unreachable (instantaneo)	Rota / ARP / REJECT (L2-L3)

$ time curl -sS http://192.0.2.10/

curl: (7) Failed to connect to 192.0.2.10 port 80 after 2 ms: No route to host

real    0m0.012s

Se No route to host retorna em 0.0xx segundos, voce esta sendo parado antes do host de destino, em algum lugar no caminho. Para um servico parado ou porta fechada veja Connection refused; para uma longa espera silenciosa veja Conectividade de Portas. Este artigo cobre No route to host.

Refused e "o host esta vivo mas a porta me rejeitou"; No route to host e "nao ha estrada ate o host / ele nao pode ser alcancado". A diferenca e decisiva: este e um problema de L2-L3 (caminho e alcancabilidade), nao de L4 (porta).

Por que "No route to host" acontece?

Conclusao: A causa se reduz a quatro coisas — (1) rota local ausente, (2) resolucao ARP falha no mesmo segmento, (3) um roteador no caminho rejeitando com ICMP, ou (4) um REJECT com icmp-host-prohibited do firewall. Trabalhe da camada mais proxima (seu proprio host) para fora.

Os caminhos que produzem EHOSTUNREACH, organizados por causa:

Causa	Quando acontece	Onde comecar
Sem rota local	Sem gateway padrao / rota deletada / interface inativa	`ip route get`
Resolucao ARP falha	Host no mesmo segmento inativo / IP duplicado / problema L2	`ip neigh`
Um roteador no caminho rejeita	Roteador retorna ICMP host/network-unreachable	`traceroute`
REJECT do firewall	Uma regra `reject-with icmp-host-prohibited` esta presente	`nft list ruleset`

Faca a triagem da camada mais proxima do seu host para fora. Primeiro verifique se sua tabela de roteamento tem uma rota, depois se voce consegue alcancar um host no mesmo segmento via L2, e finalmente se algo no caminho esta rejeitando voce.

Um primo proximo e Network is unreachable (ENETUNREACH), que aparece quando nao ha rota para a rede de destino (por exemplo, sem rota padrao). No route to host (EHOSTUNREACH) tende a significar "a rede e alcancavel, mas o host alem dela nao e". De qualquer forma, comece pela verificacao da rota local.

Como verificar a rota local?

Conclusao: Execute ip route get <IP destino> para ver, em um unico passo, qual rota, interface de saida e gateway o kernel usaria. Se der erro aqui, a causa e sua propria tabela de roteamento.

Primeiro, pergunte ao kernel como ele enviaria para aquele destino.

$ ip route get 192.0.2.10

Com uma rota valida, ele mostra a interface de saida e o gateway (ou um link direto).

192.0.2.10 via 10.0.0.1 dev eth0 src 10.0.0.42 uid 1000
    cache

Sem rota, ele da erro ali mesmo.

$ ip route get 192.0.2.10
RTNETLINK answers: Network is unreachable

Nesse caso, inspecione a tabela de roteamento e o gateway padrao.

$ ip route
$ ip route show default

default via 10.0.0.1 dev eth0 proto static
10.0.0.0/24 dev eth0 proto kernel scope link src 10.0.0.42

Se nao houver uma linha default via ..., nao ha gateway padrao, e todo destino fora da rede local e inalcancavel. Confirme tambem que a interface nao esta inativa.

$ ip -br link
$ ip -br addr

eth0   UP   52:54:00:11:22:33 <BROADCAST,MULTICAST,UP,LOWER_UP>

Se a interface estiver DOWN, ative-a com sudo ip link set eth0 up; torne as configuracoes de IP e gateway permanentes no netplan / NetworkManager.

ip route get reproduz apenas a selecao de rota do kernel sem enviar um pacote. Ele mostra qual interface e gateway um destino mapeia sem efeitos colaterais, tornando-o o primeiro passo ideal.

Como verificar o ARP no mesmo segmento?

Conclusao: Se o destino esta na mesma sub-rede, a comunicacao requer resolucao de MAC via ARP. Se o par nao responder, a tabela de vizinhos vai para FAILED e voce recebe No route to host. Verifique o estado com ip neigh.

Se ip route get mostrou sem via <GW> e em vez disso dev eth0 src ... (um link direto), o destino esta no mesmo segmento. Entao tudo depende da resolucao do MAC via ARP (NDP para IPv6).

$ ping -c1 -W1 192.0.2.10
$ ip neigh show 192.0.2.10

Se o par responder, voce obtem REACHABLE ou STALE com um MAC. Se nao, vai para FAILED.

192.0.2.10 dev eth0 FAILED

FAILED significa "deveria estar neste segmento, mas ninguem responde ao ARP". Suspeite que o par esta inativo, IP digitado errado, IP duplicado ou problema L2 (switch / VLAN / cabo). Comparar o ARP com outro host no mesmo segmento ajuda a diferenciar seu lado do dele.

$ ip neigh

10.0.0.1 dev eth0 lladdr 52:54:00:aa:bb:cc REACHABLE
192.0.2.10 dev eth0 FAILED

Se o gateway (10.0.0.1) esta REACHABLE enquanto apenas o alvo esta FAILED, sua L2 esta funcionando, e o problema e o host par ou seu caminho.

A tabela ARP muda de estado ao longo do tempo. Apos ver FAILED, verifique ip neigh novamente alguns segundos depois, ou acione ativamente a resolucao com ping antes de ler o estado, para evitar um veredito falso.

E se um roteador no caminho for a causa?

Conclusao: Se No route to host aparece para um destino em outra rede, um roteador no caminho provavelmente esta retornando ICMP host/network-unreachable. Identifique a origem pelo endereco de resposta do ping e o salto onde o traceroute para.

Quando o destino esta em outra sub-rede e tanto a rota local quanto o gateway estao funcionando, o veredito esta acontecendo no caminho. Um ping pode obter uma resposta unreachable de um roteador em seu nome.

$ ping -c2 192.0.2.10

From 10.0.0.1 icmp_seq=1 Destination Host Unreachable
From 10.0.0.1 icmp_seq=2 Destination Host Unreachable

O detalhe-chave e que a resposta vem From 10.0.0.1 — o roteador, nao o destino. Significa "alcancei o gateway, mas alem dele o host e inalcancavel". Encontre onde quebra com traceroute / mtr.

$ traceroute -n 192.0.2.10

 1  10.0.0.1   0.4 ms   0.3 ms   0.3 ms
 2  10.0.0.1  !H  *  !H

O salto que mostra !H (host unreachable) e a origem da rejeicao. !N significa network unreachable, e !X significa administratively prohibited (um firewall, coberto a seguir). Uma vez aqui, a causa nao e seu host — e um dispositivo no caminho ou a configuracao do lado remoto.

As flags finais no traceroute sao um atalho: !H = host unreachable, !N = network unreachable, !X = administratively prohibited (filtrado). Se voce ver a familia !X, va para a secao de firewall a seguir.

Quando um firewall e a causa (icmp-host-prohibited)

Conclusao: Se um firewall rejeita com reject-with icmp-host-prohibited (ou icmp-host-unreachable), o cliente ve No route to host. tcp-reset produz refused em vez disso — o tipo de REJECT decide o sintoma.

Um REJECT permite escolher o que ele retorna para recusar o trafego. O ICMP que ele envia de volta muda o que o cliente ve.

Tipo de REJECT	Sintoma no cliente
`icmp-host-prohibited`	No route to host
`icmp-host-unreachable`	No route to host
`icmp-net-unreachable`	Network is unreachable
`icmp-port-unreachable` (padrao)	Connection refused
`tcp-reset`	Connection refused

Entao, se voce ve No route to host e a rota local, ARP e traceroute estao todos limpos, suspeite de uma regra REJECT da familia icmp-host-prohibited. As regras iptables padrao de algumas distribuicoes incluem exatamente esse tipo.

# Inspecionar regras nftables
$ sudo nft list ruleset | grep -i -E 'reject|prohibit'

# Em sistemas usando iptables
$ sudo iptables -L -n -v --line-numbers

Chain INPUT (policy ACCEPT)
num  target  prot  ...  destination
8    REJECT  all   ...  reject-with icmp-host-prohibited

Se uma regra reject-with icmp-host-prohibited corresponde ao trafego, ela e a origem. Use a posicao de !X no traceroute para julgar se esta no servidor ou no caminho. Para confirmar e restaurar regras de permissao no ufw, veja Troubleshooting de ufw e SSH.

Errar a ordem das regras do firewall pode cortar sua propria conexao (como SSH). Ao editar regras remotamente, combine a alteracao com um rollback agendado (por exemplo, um job at que restaura o conjunto de regras anterior apos alguns minutos) para nao ser bloqueado.

Checklist quando ainda falha

Conclusao: No route to host confirma um problema de "caminho / alcancabilidade". Trabalhe do seu host para fora — rota local -> ARP -> traceroute -> regra REJECT — e a causa se reduz a uma dessas quatro camadas.

[ ] Voce diferenciou No route to host (instantaneo) de timed out (longa espera)?
[ ] ip route get <dest> mostrou a rota, interface de saida e gateway?
[ ] Ha uma linha de gateway padrao em ip route show default?
[ ] A interface de saida esta UP (ip -br link)?
[ ] Para um alvo no mesmo segmento, ip neigh esta mostrando FAILED (resolucao ARP)?
[ ] A resposta unreachable do ping e do destino ou de um roteador (From <GW> significa no caminho)?
[ ] Qual salto mostra !H / !N / !X no traceroute?
[ ] Ha um REJECT da familia icmp-host-prohibited em nft list ruleset / iptables -L?