O site está fora do ar para todo mundo ou só para mim?

Por que uma verificação multilocalização resolve isso

Uma requisição saindo do seu notebook passa pelo cache do navegador, pelo resolvedor de DNS do sistema operacional, pelo seu roteador, pelo seu provedor, e só então alcança o caminho de internet até o servidor. Qualquer uma dessas camadas pode falhar sozinha enquanto o servidor está perfeitamente saudável. Rode a mesma requisição de um ponto de verificação em outro país e nenhuma das suas camadas locais entra na história. Se falhar lá também, o problema está no destino. Se funcionar, o problema está entre você e a internet, e a busca encurtou do mundo inteiro para a sua máquina e a sua rede.

Rodar de mais de uma localização acrescenta uma terceira resposta possível, e ela é comum: o site está no ar em alguns lugares e fora em outros. Esse padrão aponta para uma rota de rede regional, uma borda de CDN, um bloqueio geográfico ou uma mudança de DNS que chegou a alguns resolvedores e não a outros, e não para o servidor estar desligado.

O que costuma estar errado quando é só com você

• Cache de DNS desatualizado. O seu resolvedor ou o seu sistema operacional ainda guarda um IP antigo do domínio, então você está se conectando a um servidor que mudou de lugar.
• O seu provedor ou a rota até a hospedagem. Um link de peering quebrado ou um problema de roteamento afeta todo mundo daquele provedor e mais ninguém.
• VPN ou proxy corporativo. O tráfego sai de outro lugar completamente, e esse ponto de saída pode estar bloqueado, filtrado ou simplesmente lento.
• O arquivo hosts. Uma entrada adicionada meses atrás durante um teste continua sobrepondo o DNS real, normalmente apontando para uma máquina que não existe mais.
• Cache do navegador, service worker ou uma extensão. Uma página de erro em cache, um service worker desatualizado ou um bloqueador de conteúdo podem fazer uma página funcional parecer morta.
• Firewall local ou software de segurança. Alguns pacotes bloqueiam categorias inteiras de sites, ou bloqueiam uma porta de que o site precisa.
• Um certificado expirado ou não confiável só na sua máquina. Um relógio do sistema errado faz todo certificado válido parecer vencido.

Como verificar de outra rede

O teste manual mais rápido não precisa de ferramenta nenhuma. Desligue o Wi-Fi do celular e abra o site pela rede móvel: outra rede, outro resolvedor de DNS. Se carregar ali e não no seu notebook, a falha é local.

Pelo terminal, peça os cabeçalhos diretamente e depois pergunte a um resolvedor público qual IP ele acha que o domínio tem:

curl -I -sS --max-time 10 https://example.com/
dig +short example.com @8.8.8.8
dig +short example.com

A primeira linha diz se algum servidor respondeu e com qual código de status. Se o curl relatar tempo esgotado de conexão ou falha de DNS, nada respondeu. Se as duas linhas de dig discordarem, o seu resolvedor local está segurando um endereço diferente do público, e um cache desatualizado é o suspeito provável. No Windows, ipconfig /flushdns limpa o cache local; no macOS, sudo dscacheutil -flushcache; na maioria dos sistemas Linux, reiniciar o serviço do resolvedor resolve.

O que cada resultado significa

• Fora do ar em todo lugar. O servidor, a hospedagem ou o DNS estão realmente quebrados. Olhe o código de status: um 502 ou 503 significa que alguma coisa respondeu e a aplicação atrás dela não, o que é bem diferente de nenhuma resposta.
• Fora do ar só em alguns lugares. Suspeite de DNS que ainda não terminou de atualizar em todo lugar, de uma borda ou região de CDN com problema, ou de uma regra de firewall que bloqueia certas redes ou países.
• No ar em todo lugar, menos para você. Percorra as causas locais listadas acima, começando pelo DNS e pela VPN.
• No ar, mas lento em todo lugar. Isso não é uma queda. Costuma vir antes de uma, então meça direito em vez de chutar.

Um detalhe engana as pessoas. Um site pode estar "no ar" no sentido de devolver uma página e ainda estar quebrado para os visitantes: uma verificação que só procura por uma resposta conta uma página de erro de banco de dados como sucesso quando o servidor a devolve com 200. Olhe o que voltou, não só se algo voltou.

Descobrir antes de um cliente

Uma verificação avulsa responde à pergunta que você tem agora, e só porque você lembrou de fazê-la. Quedas que começam às três da manhã, ou que afetam só uma região, costumam ser encontradas primeiro por um cliente. O monitoramento programado roda a mesma verificação continuamente, de muitas localizações, e avisa no momento em que o resultado muda, com a localização e o erro anexados. A HostTracker roda essas verificações a partir de mais de 300 pontos de verificação em 158 cidades e alerta por e-mail, SMS, chamada de voz, Slack, Telegram e outros canais, então uma falha regional se distingue de uma global já no primeiro alerta. O verificador de site fora do ar mostra o status de um site agora. Se o site responde, mas responde devagar, meça direito: tempo de resposta do servidor.