Como verificar se um site está fora do ar (para todos ou só para você)
Um site não abre. Ele está fora do ar para todo mundo ou o problema está do seu lado: seu Wi-Fi, seu DNS, seu navegador? E, se o site é seu, por onde começar? Este guia percorre as verificações na ordem que mais economiza tempo, de "será que é só comigo" até o próprio servidor.
Passo 1: está fora do ar para todos ou só para você?
A forma mais rápida de responder é olhar o site a partir de outro lugar:
- Abra no celular com o Wi-Fi desligado (os dados móveis usam outra rede e, em geral, outro DNS).
- Teste outro navegador ou uma janela anônima: extensões e dados em cache podem quebrar páginas.
- Use o verificador de status de site. Ele solicita a página a partir do nosso servidor, que está em outra rede e outra localização em relação à sua, e mostra o status HTTP, o tempo de resposta, o SSL e os redirecionamentos.
Se o site funciona a partir do nosso servidor e dos dados móveis, mas não na sua rede doméstica, o problema é local: roteador, cache de DNS, VPN, antivírus ou firewall corporativo. Reinicie o roteador, limpe o cache de DNS, desative a VPN e tente de novo. Se o site falha em todos os lugares, continue lendo.
Passo 2: leia o erro
A mensagem de erro já ajuda a restringir a causa:
- "Não é possível acessar esse site" / DNS_PROBE_FINISHED_NXDOMAIN: o nome de domínio não resolve para um endereço. Vá para o passo de DNS.
- Tempo de conexão esgotado / conexão recusada: o DNS funciona, mas o servidor não responde. Ele está fora do ar, sobrecarregado ou um firewall derruba a conexão.
- Aviso de certificado (NET::ERR_CERT_DATE_INVALID e similares): o servidor responde, mas o certificado SSL está expirado, é inválido ou foi emitido para outro nome.
- Uma página com código de erro (500, 502, 503, 404…): o servidor está acessível e respondendo. O problema está na aplicação, na configuração ou na URL.
O site inteiro ou apenas uma página?
Antes de mexer nos servidores, verifique a abrangência. Abra a página inicial e mais duas ou três páginas, incluindo um arquivo estático, como uma imagem ou o robots.txt. Se os arquivos estáticos carregam, mas as páginas não, o servidor web está ativo e a aplicação (CMS, banco de dados, PHP) está falhando. Se apenas uma seção está quebrada, veja o que ela tem de especial: um plugin, uma API externa, uma consulta pesada ao banco de dados. Se a página inicial funciona, mas um link específico retorna 404, a página pode ter sido movida sem redirecionamento. E se tudo falha apenas na área administrativa, a causa costuma ser uma sessão, um cookie ou uma regra de segurança, e não uma queda.
Passo 3: códigos de status HTTP, 5xx vs 4xx
Quando um servidor responde, ele retorna um código de status. O verificador de status HTTP mostra o código exato de qualquer URL, incluindo todos os redirecionamentos pelo caminho.
| Código | O que geralmente significa | Causa típica |
|---|---|---|
| 500 | Erro interno do servidor | Bug no código, plugin ou atualização com falha, permissões de arquivo incorretas |
| 502 | Bad gateway | O servidor web ou a CDN não consegue obter uma resposta válida da aplicação por trás dele (PHP-FPM, Node, upstream) |
| 503 | Serviço indisponível | Sobrecarga, modo de manutenção, limite de processos atingido |
| 504 | Gateway timeout | A aplicação responde devagar demais; consultas pesadas, processos travados |
| 403 | Proibido | Permissões, bloqueio de IP, regra de um WAF ou de um plugin de segurança |
| 404 | Não encontrado | URL errada, página excluída, regras de rewrite quebradas: o servidor em si está no ar |
| 429 | Muitas requisições | Limitação de taxa pelo servidor ou pela CDN |
A regra geral: 5xx significa que há um problema no lado do servidor; 4xx significa que o servidor funciona, mas recusa ou não encontra esta requisição específica. Uma página inicial retornando 404 não está "fora do ar" no sentido usual: há algo errado com a URL ou com o roteamento.
Passo 4: problemas de DNS
Se o domínio não resolve, verifique os registros dele com a consulta de DNS: o registro A (ou AAAA) existe e aponta para o servidor certo? Os registros NS são os que o seu provedor de DNS forneceu?
Causas comuns:
- O domínio expirou. Os registradores costumam trocar o DNS para uma página de estacionamento ou removê-lo por completo. Verifique a data de expiração no WHOIS.
- Os registros foram alterados recentemente. Depois de trocar de hospedagem ou de provedor de DNS, alguns resolvers ainda retornam o endereço antigo até o TTL em cache expirar. O verificador de propagação de DNS compara as respostas de vários resolvers públicos com as dos servidores autoritativos e mostra quem já enxerga o novo valor.
- Os nameservers foram alterados no registrador, mas a zona no novo provedor está vazia ou incompleta.
Para um passo a passo de todos os tipos de registro, veja como verificar os registros DNS de um domínio.
Etapa 5: certificado SSL expirado
Os navegadores bloqueiam um site com certificado expirado exibindo um aviso em tela cheia, que os visitantes interpretam como "o site está fora do ar". A renovação automática normalmente evita isso, mas falha silenciosamente quando o DNS muda, uma CDN é adicionada ou a tarefa de renovação deixa de rodar. O verificador de SSL mostra a data de expiração, a cadeia e os nomes cobertos. Detalhes: verificação de certificado SSL.
Etapa 6: falhas de hospedagem, CDN e terceiros
Às vezes o problema não está no seu site. Grandes provedores de hospedagem, plataformas de nuvem e CDNs publicam páginas de status (geralmente status.provider.com) com os incidentes em andamento. Se você usa uma CDN como a Cloudflare, as próprias páginas de erro dela indicam qual lado falhou: um erro que cita o seu servidor de origem significa que a CDN funciona, mas não consegue alcançar a sua hospedagem.
Verifique também a lentidão, não apenas a queda total: a ferramenta de tempo de resposta divide uma requisição em DNS, conexão, TLS e tempo até o primeiro byte. Um TTFB de vários segundos indica servidor sobrecarregado ou aplicação lenta, o que costuma anteceder erros 502 e 504.
Etapa 7: bloqueio por firewalls e WAF
Um site pode estar "fora do ar" apenas para alguns visitantes. Web application firewalls, plugins de segurança, proteção contra DDoS na hospedagem e bloqueios por país podem bloquear um endereço IP, um provedor inteiro ou um país. Sinais: erro 403 ou página de desafio para algumas pessoas, acesso normal para outras; o site funciona pelos dados móveis, mas não pelo escritório. Se o IP do seu servidor ou do seu servidor de e-mail estiver em uma lista de bloqueio pública, veja por que meu IP está na lista negra.
Para donos de sites: o que fazer agora e da próxima vez
- Confirme a queda de fora da sua rede (verificador de status, dados móveis).
- Verifique o óbvio: expiração do domínio e do certificado, conta de hospedagem suspensa por fatura em aberto, disco cheio.
- Consulte os logs: o log de erros do servidor web e o log da aplicação no momento exato da falha. A maioria dos erros 500 é explicada ali.
- Desfaça a última alteração: uma atualização de plugin, um deploy, uma edição de configuração. Primeiro reverta, depois investigue.
- Reinicie os serviços (servidor web, PHP-FPM, banco de dados) se estiverem travados, e descubra o motivo depois.
- Entre em contato com a hospedagem com detalhes específicos: horário, URL, código de status, texto do erro.
Para descobrir antes dos seus visitantes, configure um monitoramento de uptime que verifique o site a cada poucos minutos de fora e avise você por e-mail ou mensageiro. Adicione alertas separados para a expiração do certificado e do domínio, pois são as quedas mais evitáveis de todas.
