Site fora do ar: como descobrir o motivo

Quando um site cai, a tentação é reiniciar tudo e torcer. Funciona às vezes, mas você não aprende nada e o problema volta. É mais rápido descobrir onde a requisição quebra.

Uma visita passa por etapas em ordem: o navegador resolve o nome no DNS, abre uma conexão segura com o certificado TLS, chega a um servidor ou proxy e, por fim, a sua aplicação responde. Cada etapa falha de um jeito reconhecível. O erro que aparece diz em qual delas a falha aconteceu.

O site caiu mesmo ou o problema é só aqui?#

Antes de mexer no servidor, confirme o alcance. Três testes de um minuto:

1. Abra o site no 4G do celular, fora do Wi-Fi.
2. Rode um curl a partir de outra máquina ou de um servidor.
3. Peça para outra pessoa abrir.

Se carrega em outro lugar, o problema é local: cache de DNS antigo, VPN, antivírus, extensão do navegador ou o provedor de internet. Limpe o cache com ipconfig /flushdns (Windows) ou sudo resolvectl flush-caches (Linux com systemd).

Se falha em todos os lugares, o problema é do site. Continue no próximo passo.

Como ler o erro que aparece?#

O curl mostra melhor que o navegador em qual camada a requisição parou:

curl -sS -o /dev/null -w "%{http_code}\n" -v https://seusite.com

O DNS está resolvendo o domínio?#

Teste com:

nslookup seusite.com
dig +short seusite.com

Se nenhum IP voltar, confira duas coisas. Primeiro, se o domínio expirou no registrador: é a causa mais simples e uma das mais comuns. Depois, se o registro A ou CNAME ainda existe. Detalhes em DNS_PROBE_FINISHED_NXDOMAIN e em propagação de DNS.

Se você acabou de mudar o DNS, o resultado pode variar por algum tempo: resolvedores diferentes guardam o valor antigo até o TTL acabar.

O certificado venceu?#

Os certificados do Let's Encrypt têm validade curta, e a documentação oficial recomenda renová-los bem antes do vencimento. Em dezembro de 2025, o Let's Encrypt anunciou uma redução gradual da validade padrão, então a renovação precisa ser automática. Se a renovação automática falha em silêncio (cron parado, porta 80 bloqueada, DNS alterado), o site "cai" com um aviso de certificado vencido.

echo | openssl s_client -connect seusite.com:443 -servername seusite.com 2>/dev/null | openssl x509 -noout -dates

A linha notAfter é a data de vencimento. Veja mais em erros de certificado SSL e em como o Let's Encrypt funciona.

O que significam 502, 503 e 504?#

São os erros que mais assustam, e todos apontam para a aplicação por trás de um proxy reverso:

• 502 Bad Gateway: o proxy falou com a aplicação e recebeu uma resposta inválida, por exemplo porque o processo caiu durante a requisição ou não está escutando onde o proxy espera.
• 503 Service Unavailable: o servidor não consegue atender agora, por sobrecarga ou manutenção.
• 504 Gateway Timeout: o proxy não recebeu resposta da aplicação a tempo.

Nos três casos, vá ao log da aplicação. Procure falta de memória (Killed, JavaScript heap out of memory, MemoryError), exceção não tratada na inicialização ou porta errada. Um servidor Node.js precisa escutar a porta e o endereço que o proxy espera:

import http from "node:http";

const port = Number(process.env.PORT) || 3000;
http
  .createServer((req, res) => res.end("ok"))
  .listen(port, "0.0.0.0", () => console.log(`ouvindo na porta ${port}`));

Escutar só em 127.0.0.1 ou numa porta que o proxy não conhece gera 502 mesmo com a aplicação "rodando".

E se for erro 500 ou página em branco?#

Aqui o servidor está no ar e o seu código quebrou. Veja o log no horário do erro e compare com o último deploy. Causas frequentes: variável de ambiente que existia na sua máquina e não existe no servidor, dependência que não foi instalada, banco recusando conexão e arquivo não enviado no deploy. Se começou logo após publicar, volte para a versão anterior primeiro e investigue depois.

Como evitar a próxima queda?#

• Ative a renovação automática do domínio e confira o e-mail de contato no registrador.
• Use um monitor externo que teste a URL a cada poucos minutos e avise por e-mail, SMS ou webhook.
• Guarde logs e acompanhe memória e CPU, para ver o limite chegando antes de ele estourar.
• Garanta que a aplicação reinicie sozinha quando o processo falhar.
• Mantenha um caminho de rollback para o deploy anterior.
• Se o site não precisa de código no servidor, considere um site estático: há menos peças que podem quebrar.

Como fazer isso na Square Cloud#

Na Square Cloud, o site roda num container isolado, sempre ligado; com o reinício automático ligado (o padrão no deploy pelo painel), a aplicação que encerra com erro volta sozinha. Você vê os logs em tempo real no painel, na CLI e no VS Code. As métricas de CPU, RAM e rede, coletadas a cada 5 minutos e guardadas por 24 horas, mostram se a memória esgotou antes da queda. Se a memória estourar, a aplicação para e só volta depois que você aumentar a RAM e iniciá-la de novo.

Toda aplicação web recebe um subdomínio *.squareweb.app com HTTPS, o que ajuda a separar problema de domínio de problema de aplicação: se o subdomínio abre e o seu domínio não, a falha está do lado do domínio (registros DNS ou o próprio domínio), não na aplicação. Em domínio personalizado (a partir do Standard), o painel mostra o status de validação dos registros DNS em tempo real, e o TLS é automático.

O analytics web, incluído em todo plano, mostra visitas, rotas e códigos de status; Pro e Enterprise acrescentam logs HTTP. Não há alerta por e-mail, então use um monitor externo para ser avisado.

Para começar, veja a página de hospedagem de sites; os detalhes do monitoramento estão na página de analytics.