ERR_ADDRESS_UNREACHABLE: como achar onde a rota até o servidor quebra

Em casa, fotos.familiasilva.com.br abre na hora. No escritório, o Chrome mostra "Não é possível acessar esse site" com ERR_ADDRESS_UNREACHABLE, e apertar F5 dez vezes não muda nada. A resposta curta: esse erro acontece antes do site. O nome foi resolvido para um IP, mas o seu computador não tem caminho até esse IP. Na maioria dos casos, o DNS aponta para um endereço que só existe em outra rede (um 192.168.x.x de casa, um IP de VPN) ou a máquina de destino está fora do ar na rede local. Compare o IP que cada rede resolve e teste a rota até ele.

O exemplo deste guia é exatamente esse: um servidor de fotos em casa, no IP 192.168.0.50, e um registro DNS público criado às pressas apontando o nome para esse endereço interno.

Por que o navegador diz "inalcançável"

Para abrir uma página, o navegador faz três coisas em sequência: resolve o nome em IP, abre uma conexão até esse IP e só então conversa HTTP. Cada etapa tem o seu erro característico, e saber qual apareceu já corta metade da investigação.

• ERR_NAME_NOT_RESOLVED: o nome não virou IP. Problema de DNS.
• ERR_ADDRESS_UNREACHABLE: o nome virou IP, mas o sistema operacional avisou que não há caminho até ele.
• ERR_CONNECTION_TIMED_OUT: havia caminho, mas ninguém respondeu a tempo. Costuma ser firewall descartando pacotes ou servidor travado.
• ERR_CONNECTION_REFUSED: a máquina respondeu, mas nada escuta naquela porta.

"Sem caminho" tem duas causas típicas. Se o IP está fora da sua rede local, o computador manda para o roteador, e o roteador ou alguém adiante devolve "destino inalcançável". Se o IP está na mesma faixa da sua rede, o computador pergunta na rede local quem tem aquele endereço, ninguém responde, e o sistema conclui que o destino não existe ali.

No caso do escritório, o computador recebe 192.168.0.50 do DNS público. Esse endereço é privado: existe em milhões de redes domésticas e não é roteado na internet. Na rede do escritório ele não existe, ou é outra máquina qualquer. Endereços de 10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16 nunca funcionam "da rua".

Como diagnosticar em cinco comandos

1. Veja qual IP o seu computador resolve.
2. Veja qual IP outra rede resolve, por exemplo o celular fora do Wi-Fi, usando um app de DNS ou um site de consulta de DNS.
3. Classifique o IP: privado, público, de VPN.
4. Pergunte ao sistema por onde ele mandaria o pacote para aquele IP.
5. Teste a porta diretamente, sem o navegador no meio.

No Windows, com PowerShell

Resolve-DnsName fotos.familiasilva.com.br
Find-NetRoute -RemoteIPAddress 192.168.0.50
Test-NetConnection 192.168.0.50 -Port 443
tracert -d 192.168.0.50

Find-NetRoute mostra qual interface e qual gateway o Windows usaria. Se a resposta é a rota padrão do escritório, o pacote vai para a internet atrás de um endereço privado e não chega. Test-NetConnection devolve TcpTestSucceeded : False quando a conexão não fecha, e o tracert mostra até onde o pacote foi.

No Linux ou macOS

dig +short fotos.familiasilva.com.br
ip route get 192.168.0.50
nc -vz 192.168.0.50 443

No macOS, troque ip route get por route get 192.168.0.50. Em Linux, a mensagem "No route to host" do nc é o equivalente direto do erro do Chrome.

Quando o navegador e o terminal discordam

O Chrome pode usar DNS seguro (DNS sobre HTTPS) por conta própria e mantém um cache interno de nomes. Se Resolve-DnsName mostra um IP e o navegador parece usar outro, confira a opção de DNS seguro nas configurações de privacidade e segurança e limpe o cache de host em chrome://net-internals/#dns. Um registro alterado recentemente pode também estar preso no TTL antigo, assunto de baixar o TTL antes da troca.

Os quatro cenários e o que fazer em cada um

DNS público apontando para IP privado

É o caso do exemplo. Funciona em casa por coincidência: lá, 192.168.0.50 existe. Ou você remove o nome do DNS público e acessa de fora por uma VPN, ou aponta o nome para o IP público da sua conexão e expõe o serviço com cuidado. Para um álbum de família, a VPN é a escolha mais segura, como discutido em fotos no servidor de casa.

Nome que só deveria existir na rede interna

Se o serviço é interno, use DNS interno: o roteador ou o servidor DNS da empresa responde o IP privado, e o DNS público não sabe desse nome. Quem está fora entra pela VPN e passa a usar o DNS interno.

VPN que não leva a rota

Conectado à VPN, o nome resolve para 10.20.0.15, mas a VPN foi configurada para levar só parte do tráfego e essa faixa ficou de fora. Find-NetRoute ou ip route get mostram a interface errada. A correção é incluir a faixa nas rotas da VPN, não mexer no navegador.

Máquina desligada ou com IP trocado

O servidor de casa reiniciou e pegou outro IP do DHCP. O DNS interno ainda aponta para o antigo, ninguém responde na rede local e o erro aparece até em casa. Reserve o IP no roteador para o MAC do servidor. O mesmo vale para VMs na nuvem que mudam de endereço, como em mover VM não é copiar IP.

Erros comuns

• Insistir no F5 e limpar cookies. Cookie e cache de página não criam rota; você perde tempo na camada errada.
• Publicar IP privado no DNS público. Funciona só onde o endereço existe por acaso e confunde qualquer diagnóstico depois.
• Testar só de dentro de casa. Você valida o caminho que já funcionava e descobre o problema quando está longe.
• Comparar o DNS do terminal ignorando o DNS seguro do navegador. Os dois respondem coisas diferentes e você conclui que "o DNS está certo".
• Abrir a porta do roteador sem autenticação para "resolver". O erro some e o serviço fica exposto para a internet inteira.
• Deixar o servidor com IP dinâmico na rede local. Um reinício muda o endereço e o nome passa a apontar para o vazio.

Checklist

• Você sabe qual IP o nome resolve na rede onde o erro acontece.
• Você sabe qual IP o nome resolve em outra rede.
• Nenhum nome do DNS público aponta para faixa privada.
• A rota até o IP sai pela interface esperada (rede local, VPN ou internet).
• O teste de porta direto, sem navegador, conecta.
• O servidor tem IP reservado no roteador.
• Serviços internos são acessados de fora por VPN, não por porta aberta.

Rode agora a consulta de DNS do nome que falhou. O IP que voltou pertence à rede onde você está, ou esse nome deveria existir só dentro de casa?