Diagnosticando "No route to host"
O que significa "No route to host"?
Conclusão: Não há caminho utilizável para entregar pacotes ao host. O kernel — ou um dispositivo no caminho — decidiu que o destino é inalcançável, e
EHOSTUNREACHé retornado. Assim como refused, falha imediatamente.
No route to host aparece quando algo no caminho até o destino decide que não pode entregar o pacote. No nível de chamada de sistema, connect() retorna EHOSTUNREACH, que as aplicações 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 três lugares: (1) o kernel local decide que não há nenhuma rota, (2) um host no mesmo segmento não 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.
Pré-requisitos
- SO: Ubuntu / um Linux típico (comando
ip= iproute2) - Destino: qualquer host que você deseja alcançar por IP
- Assumimos que você pode ler as tabelas de roteamento e ARP sem
sudo
Como é diferente de refused e timeout?
Conclusão: Refused significa "chegou mas foi rejeitado na porta", timeout significa "nenhuma resposta", e No route to host significa "não há caminho para entregar / o host não pode ser alcançado". Mesma conexão falhada, ponto de partida completamente diferente.
Erros de conexão se dividem em três famílias que falham em camadas diferentes. Identifique qual você tem primeiro.
| Erro | O que retorna | Camada da causa |
|---|---|---|
| Connection refused | TCP RST (instantâneo) | Serviço / porta (L4, aplicação) |
| Connection timed out | Sem resposta (longa espera) | DROP / caminho silencioso (L3-L4) |
| No route to host | ICMP unreachable (instantâneo) | 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, você está sendo parado antes do host de destino, em algum lugar no caminho. Para um serviço parado ou porta fechada veja Connection refused; para uma longa espera silenciosa veja Conectividade de Portas. Este artigo cobre No route to host.
Refused é "o host está vivo mas a porta me rejeitou"; No route to host é "não há estrada até o host / ele não pode ser alcançado". A diferença é decisiva: este é um problema de L2-L3 (caminho e alcançabilidade), não de L4 (porta).
Por que "No route to host" acontece?
Conclusão: A causa se reduz a quatro coisas — (1) rota local ausente, (2) resolução 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 próxima (seu próprio host) para fora.
Os caminhos que produzem EHOSTUNREACH, organizados por causa:
| Causa | Quando acontece | Onde começar |
|---|---|---|
| Sem rota local | Sem gateway padrão / rota deletada / interface inativa | ip route get |
| Resolução 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 está presente |
nft list ruleset |
Faça a triagem da camada mais próxima do seu host para fora. Primeiro verifique se sua tabela de roteamento tem uma rota, depois se você consegue alcançar um host no mesmo segmento via L2, e finalmente se algo no caminho está rejeitando você.
Um primo próximo é Network is unreachable (ENETUNREACH), que aparece quando não há rota para a rede de destino (por exemplo, sem rota padrão). No route to host (EHOSTUNREACH) tende a significar "a rede é alcançável, mas o host além dela não é". De qualquer forma, comece pela verificação da rota local.
Como verificar a rota local?
Conclusão: Execute
ip route get <IP destino>para ver, em um único passo, qual rota, interface de saída e gateway o kernel usaria. Se der erro aqui, a causa é sua própria tabela de roteamento.
Primeiro, pergunte ao kernel como ele enviaria para aquele destino.
$ ip route get 192.0.2.10
Com uma rota válida, ele mostra a interface de saída 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 dá 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 padrão.
$ 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 não houver uma linha default via ..., não há gateway padrão, e todo destino fora da rede local é inalcançável. Confirme também que a interface não está 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 configurações de IP e gateway permanentes no netplan / NetworkManager.
ip route get reproduz apenas a seleção 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?
Conclusão: Se o destino está na mesma sub-rede, a comunicação requer resolução de MAC via ARP. Se o par não responder, a tabela de vizinhos vai para
FAILEDe você recebe No route to host. Verifique o estado comip neigh.
Se ip route get mostrou sem via <GW> e em vez disso dev eth0 src ... (um link direto), o destino está no mesmo segmento. Então tudo depende da resolução 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, você obtém REACHABLE ou STALE com um MAC. Se não, vai para FAILED.
192.0.2.10 dev eth0 FAILED
FAILED significa "deveria estar neste segmento, mas ninguém responde ao ARP". Suspeite que o par está 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) está REACHABLE enquanto apenas o alvo está FAILED, sua L2 está funcionando, e o problema é o host par ou seu caminho.
A tabela ARP muda de estado ao longo do tempo. Após ver FAILED, verifique ip neigh novamente alguns segundos depois, ou acione ativamente a resolução com ping antes de ler o estado, para evitar um veredito falso.
E se um roteador no caminho for a causa?
Conclusão: Se No route to host aparece para um destino em outra rede, um roteador no caminho provavelmente está retornando ICMP host/network-unreachable. Identifique a origem pelo endereço de resposta do
pinge o salto onde otraceroutepara.
Quando o destino está em outra sub-rede e tanto a rota local quanto o gateway estão funcionando, o veredito está 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 é que a resposta vem From 10.0.0.1 — o roteador, não o destino. Significa "alcancei o gateway, mas além dele o host é inalcançável". 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) é a origem da rejeição. !N significa network unreachable, e !X significa administratively prohibited (um firewall, coberto a seguir). Uma vez aqui, a causa não é seu host — é um dispositivo no caminho ou a configuração do lado remoto.
As flags finais no traceroute são um atalho: !H = host unreachable, !N = network unreachable, !X = administratively prohibited (filtrado). Se você ver a família !X, vá para a seção de firewall a seguir.
Quando um firewall é a causa (icmp-host-prohibited)
Conclusão: Se um firewall rejeita com
reject-with icmp-host-prohibited(ouicmp-host-unreachable), o cliente vê No route to host.tcp-resetproduz refused em vez disso — o tipo de REJECT decide o sintoma.
Um REJECT permite escolher o que ele retorna para recusar o tráfego. O ICMP que ele envia de volta muda o que o cliente vê.
| 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 (padrão) |
Connection refused |
tcp-reset |
Connection refused |
Então, se você vê No route to host e a rota local, ARP e traceroute estão todos limpos, suspeite de uma regra REJECT da família icmp-host-prohibited. As regras iptables padrão de algumas distribuições 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 tráfego, ela é a origem. Use a posição de !X no traceroute para julgar se está no servidor ou no caminho. Para confirmar e restaurar regras de permissão no ufw, veja Troubleshooting de ufw e SSH.
Errar a ordem das regras do firewall pode cortar sua própria conexão (como SSH). Ao editar regras remotamente, combine a alteração com um rollback agendado (por exemplo, um job at que restaura o conjunto de regras anterior após alguns minutos) para não ser bloqueado.
Checklist quando ainda falha
Conclusão: No route to host confirma um problema de "caminho / alcançabilidade". Trabalhe do seu host para fora — rota local -> ARP -> traceroute -> regra REJECT — e a causa se reduz a uma dessas quatro camadas.
- [ ] Você diferenciou
No route to host(instantâneo) detimed out(longa espera)? - [ ]
ip route get <dest>mostrou a rota, interface de saída e gateway? - [ ] Há uma linha de gateway padrão em
ip route show default? - [ ] A interface de saída está
UP(ip -br link)? - [ ] Para um alvo no mesmo segmento,
ip neighestá mostrandoFAILED(resolução ARP)? - [ ] A resposta unreachable do
pingé do destino ou de um roteador (From <GW>significa no caminho)? - [ ] Qual salto mostra
!H/!N/!Xnotraceroute? - [ ] Há um REJECT da família
icmp-host-prohibitedemnft list ruleset/iptables -L?