
O Chrome exibe “Não é possível acessar esse site” para pelo menos seis falhas diferentes, e elas quase não têm nada em comum além da ordem em que acontecem. Uma significa que o nome não existe. Outra significa que a máquina atendeu e desligou. Outra significa que o wifi do seu visitante caiu.
A frase é sempre a mesma porque é a única coisa honesta que o navegador pode dizer sobre uma página que nunca chegou a receber. O que os diferencia é o pequeno código cinza logo abaixo, e esse código é o diagnóstico completo.
A ordem em que as coisas acontecem
Carregar uma página passa por quatro etapas, e cada uma tem sua própria forma de falhar. Ler os códigos nessa ordem é o que faz eles fazerem sentido.
1. Encontrar o endereço. O navegador pergunta a um resolvedor para qual IP o hostname aponta.
2. Abrir uma conexão. Ele tenta alcançar esse IP nessa porta.
3. Protegê-la. No caso de HTTPS, ele valida um certificado.
4. Pedir a página. Ele envia a requisição e aguarda uma resposta.
Uma falha na etapa um não pode ser culpa do seu servidor, porque nada chegou até ele ainda. Uma falha na etapa quatro quase certamente é. O código informa a qual etapa você chegou, e isso vale mais do que qualquer quantidade de descrição do sintoma.
Os códigos, nessa ordem
DNS_PROBE_FINISHED_NXDOMAIN e ERR_NAME_NOT_RESOLVED são a etapa um. A própria descrição
do Chromium para o segundo é “O nome do host não pôde ser resolvido.” O nome não existe, pelo
menos para o resolvedor que respondeu. Um código relacionado, e mais específico, é
ERR_NAME_RESOLUTION_FAILED, “Ocorreu um erro ao tentar fazer uma resolução de nome (DNS)”, que
é a própria busca dando errado em vez de simplesmente voltar vazia.
Um erro de digitação causa isso. O mesmo vale para um registro DNS que ainda não se propagou, um domínio que expirou no fim de semana, e um filtro DNS corporativo ou de controle parental que se recusa a responder pelo seu domínio. Esse último caso importa mais do que parece: para a pessoa afetada, seu site simplesmente não existe, e ele funciona perfeitamente para você.
ERR_CONNECTION_REFUSED é a etapa dois, e é a falha mais informativa desta lista. Algo
respondeu. Uma máquina naquele endereço disse não ativamente, o que significa que o DNS
funcionou, a rota funcionou, e há um host ali sem nada escutando naquela porta. Porta errada, um
serviço que morreu, um container que não voltou depois de um deploy.
ERR_CONNECTION_TIMED_OUT é a etapa dois falhando em silêncio: “Uma tentativa de conexão
expirou.” Nada disse não, e nada disse sim. Um firewall que descarta pacotes em vez de
rejeitá-los tem exatamente essa cara, assim como um servidor ocupado demais para aceitar a
conexão.
ERR_ADDRESS_UNREACHABLE é roteamento: “O endereço IP está inacessível. Isso geralmente
significa que não há rota até o host ou rede especificados.” Os pacotes não têm para onde ir.
ERR_INTERNET_DISCONNECTED é “A conexão com a internet foi perdida”, e é o único caso em que
você pode parar de investigar imediatamente. É a própria rede do visitante, e nenhum relato
baseado nele diz qualquer coisa sobre o seu site.
ERR_EMPTY_RESPONSE é a etapa quatro: “O servidor encerrou a conexão sem enviar nenhum
dado.” Este aqui geralmente é seu mesmo. Algo aceitou a conexão e depois sumiu sem responder: um
processo que travou no meio da requisição, um proxy que desistiu, um worker morto por falta de
memória.
Falhas de certificado também acontecem na etapa três, mas ganham uma tela própria em vez desta.
Qual das cinco é a sua é uma questão à parte,
e a família ERR_CONNECTION_* tem
seu próprio artigo
detalhando a diferença entre refused e reset.
- Fraco
- Cliente diz que o site está fora do ar. Aqui parece normal. Pedimos para ele limpar o cache.
- Melhor
- DNS_PROBE_FINISHED_NXDOMAIN, só na rede do escritório dele, funciona com dados móveis. É o filtro DNS deles, não o nosso servidor. Confirmamos que o registro resolve a partir de três resolvedores públicos.
Qual metade da lista é sua, afinal
Ordene-os por quem pode corrigi-los e a lista se divide quase ao meio, o que é a parte útil disso.
Geralmente é deles: as falhas de DNS quando são filtradas ou armazenadas em cache localmente, a internet desconectada, o endereço inacessível, e um timeout causado pela rede deles em vez da sua carga.
Geralmente é seu: conexão recusada, resposta vazia, e um timeout quando seus servidores estão de fato saturados.
Genuinamente ambíguo, e vale a pena checar primeiro: uma falha de DNS que se reproduz a partir de um resolvedor público é problema do seu registro, não da rede deles. Essa checagem leva dez segundos e resolve a maior categoria da lista. Em qualquer máquina:
nslookup example.com 1.1.1.1
nslookup example.com 8.8.8.8
Se ambos responderem com o seu IP e o visitante ainda receber NXDOMAIN, o problema está entre ele e o resolvedor dele. Se nenhum dos dois responder, é o seu registro, e o relógio disso começou a contar desde a última vez que ele mudou.
Session Replay
Extensão gratuita para Chrome. Um clique na página que está com problema captura a tela, o console e o log de rede, e entrega a você um link para colar no chamado.
O problema do relato, que é o verdadeiro problema
Todo código acima aparece em uma página gerada pelo navegador. Seu site nunca chegou a rodar. Não há console, não há entrada na aba de rede, nenhum erro que o seu tracker consiga capturar, e nada para qualquer ferramenta embutida na página registrar, incluindo a nossa.
Então essa categoria inteira só chega até você se alguém te contar, e essa pessoa vai contar mal, porque não há nada na tela para copiar além de uma frase e um código que ela não tem motivo para achar que importa. A maioria dos relatos assim chega como “seu site está fora do ar”, vindo de alguém para quem ele genuinamente está.
Isso torna a pergunta de acompanhamento incomumente valiosa, e incomumente simples. Não é “por favor, reproduza com o console aberto”, o que não é possível aqui. São três coisas:
- O código, do texto pequeno e cinza abaixo da mensagem, na íntegra.
- Se acontece em outra rede, sendo dados móveis o teste mais fácil.
- Se mais alguém consegue acessar, o que separa uma queda global de um problema no resolvedor de uma única pessoa, em uma única mensagem.
Com três respostas você já costuma saber qual das quatro etapas falhou antes mesmo de olhar para um servidor. É um bug seu ou uma queda deles cobre o mesmo raciocínio para serviços que estão no ar, mas degradados.
O que levar disso
“Não é possível acessar esse site” é uma categoria, não um diagnóstico, e as seis falhas dentro dela se dividem quase igualmente entre coisas que você pode corrigir e coisas que não pode.
Leia o código, descubra a qual das quatro etapas ele pertence, e verifique o DNS a partir de um resolvedor público antes de acreditar em qualquer outra coisa. E quando você não conseguir reproduzir o problema, lembre-se de que não conseguir acessar um site é a única falha em que a sua própria máquina é o instrumento menos útil que você tem: a sua resolve, conecta e funciona.
A lista de erros do Chromium, com a definição de uma linha para cada um, é net_error_list.h.