Como diagnosticar o erro “This site can't be reached”

“This site can't be reached” (ou a frase equivalente do seu navegador) é deliberadamente vago: abrange desde um erro de digitação na URL até um servidor totalmente fora do ar e uma queda de rede na sua própria conexão. Resolver isso com eficiência significa verificar primeiro o que é mais barato e mais rápido.

Comece com uma consulta DNS simples

Antes de presumir que um servidor está fora do ar, resolva o domínio isoladamente, independente do seu navegador. Se ele retornar um endereço IP limpo, o DNS não é o problema, e você pode passar a verificar a própria conexão (a porta está aberta, o TLS está negociando, o servidor está de fato respondendo). Se retornar NXDOMAIN, um timeout ou um endereço privado ou com aparência de inalcançável, você isolou o problema no DNS, o que descarta de imediato toda uma categoria de outras investigações.

O que cada resultado indica

É também por isso que uma ferramenta de consulta rápida e sem cadastro é realmente útil no meio de um incidente: ela entrega a resposta da camada de DNS em segundos, sem que você precise abrir um terminal ou lembrar a sintaxe de dig/nslookup, e assim você descobre de imediato se está mesmo diante de um problema de DNS antes de gastar tempo em qualquer outro lugar.

Depois do DNS: o que verificar em seguida, em ordem

1. Conectividade TCP com o IP resolvido na porta esperada (normalmente 443): um firewall ou um servidor totalmente fora do ar vai recusar a conexão ou travar aqui, mesmo com o DNS perfeito.
2. Validade do certificado TLS: um certificado expirado ou incompatível produz um alerta de segurança no navegador que parece alarmante, mas não tem nada a ver com o DNS nem com o servidor estar acessível.
3. Resposta no nível HTTP: um servidor que aceita a conexão mas retorna um erro 5xx está no ar e acessível, apenas falhando na camada de aplicação, vários passos além de qualquer coisa que o DNS poderia ter causado.

Percorrer essas camadas em ordem (DNS, depois transporte, depois TLS, depois aplicação) significa que cada etapa descartada reduz de forma significativa as possibilidades restantes, em vez de adivinhar sobre toda a pilha de uma só vez.

Por que justamente essa ordem

Cada camada dessa sequência depende inteiramente de a anterior ter sido bem-sucedida, e é exatamente por isso que verificá-las em ordem (em vez de pular para a que parece mais provável) é a abordagem eficiente. Não adianta inspecionar um certificado TLS se a conexão TCP nunca foi concluída, nem verificar códigos de resposta HTTP se a negociação do TLS falhou. Começar pelo DNS, a primeira coisa que precisa acontecer para que o resto sequer seja possível, e avançar para fora uma camada de cada vez significa que você nunca perde tempo investigando um sintoma que, na verdade, sempre foi causado por um problema mais simples de uma camada anterior.