Base de Conhecimento e Ferramentas de TI DIEG

O que fazer se o servidor caiu ou o site está indisponível: diagnóstico passo a passo

Quando um site fica indisponível e o servidor web para de responder às solicitações, o objetivo principal é identificar rapidamente a causa raiz antes que os negócios sofram ou as posições nos motores de busca caiam.

Causas reais de falhas no servidor e no site

1. Esgotamento do Espaço em Disco ou do Limite de Inodes (No space left on device)

A causa mais comum de falhas ocultas. O disco cheio é um problema traiçoeiro: raramente se declara de forma direta, mas provoca uma cascata de erros “fantasma” em todo o sistema:

• Bancos de dados (MySQL / PostgreSQL): Falhas de autenticação, interrupção repentina dos serviços mysqld / postgres devido à impossibilidade de gravar logs WAL, transações ou tabelas temporárias.
• Servidor web (Nginx / PHP-FPM): Erros 500 Internal Server Error e 502 Bad Gateway, recusa na gravação de sessões PHP, páginas em branco e falhas de cache.
• Inodes: Esgotamento do limite de descritores de índice (milhões de pequenos arquivos de sessão, cache ou logs), mesmo com espaço formal livre em disco. Os Inodes costumam ser esquecidos — o disco pode estar livre, mas o limite de arquivos foi atingido.

Diagnóstico:

# Verificar espaço livre nos discos
df -h
# Verificar uso de Inodes
df -iT
# Quantos inodes cada pasta está usando no diretório de sites (/var/www/)
ls -d1 /var/www/* | while read i; do echo -en "$i\t"; find "$i" -name "*" | wc -l; done;
# Ou usando o du (especialmente projetado para localizar diretórios que consomem inodes)
du --inodes -x --max-depth=1 /var/www/ | sort -n

2. OOM Killer Acionado (Out of Memory, Killed)

Falta de memória RAM é um clássico. O kernel do Linux começa a encerrar processos para salvar o sistema. O OOM também é possível ao atingir o limite de memória de um grupo de processos via cgroups, mesmo que ainda haja RAM disponível no servidor. Para o diagnóstico, é melhor procurar por mensagens características:

# Mensagens do kernel nas últimas 24 horas em sistemas com systemd
sudo journalctl -k --since "24 hours ago" --no-pager |
  grep -Ei 'out of memory|oom-kill|killed process'

# Alternativa: buffer circular atual do kernel
sudo dmesg -T | grep -Ei 'out of memory|oom-kill|killed process'

# Estado atual da RAM e Swap
free -h

3. Certificado SSL Expirado (Certificate expired, Certificate verify failed)

O site funciona normalmente, mas ao tentar abri-lo o navegador exibe um aviso de segurança, e os scripts falham com erros de SSL error: certificate verify failed ou error: certificate has expired. Principais motivos:

• A tarefa Cron de renovação automática do Certbot / Let’s Encrypt falhou.
• Cadeia de certificados intermediários incompleta (ausência do CA Bundle).
• No painel (como o FastPanel), o nome do VPS coincide com o domínio do site, e no /etc/hosts o domínio aponta para 127.0.0.1.

Para certificados já gerenciados pelo Certbot, é útil testar o procedimento de renovação sem aplicar alterações:

sudo certbot renew --dry-run

4. Registro AAAA Incorreto: Site Indisponível via IPv6

Principais motivos que levam a erros:

• O registro AAAA aponta para um endereço IPv6 incorreto ou antigo.
• O endereço está correto, mas não está configurado no servidor.
• O servidor web não aceita conexões IPv6 nas portas 80/443.
• O Firewall permite IPv4, mas bloqueia o IPv6.

Verificação — substitua example.com pelo seu domínio:

# Qual IPv6 está publicado no DNS
dig +short AAAA example.com

# Verificação do site via IPv4
curl -4 -I --connect-timeout 10 https://example.com/

# Verificação do site via IPv6
curl -6 -I --connect-timeout 10 https://example.com/

Nota: A verificação do IPv6 deve ser feita a partir de um computador ou VPS com uma conexão IPv6 ativa.