Servidor fora do ar: o que verificar e em que ordem

Este guia fala do servidor em si: um VPS, um servidor dedicado ou um servidor na nuvem que você administra. Se só um site parou e todo o resto na máquina funciona, ou se seu site está em uma hospedagem compartilhada, comece pelo guia site fora do ar. Aqui olhamos a máquina: ela ainda responde? Você consegue entrar? O que parou? Em Portugal, o problema se chama “servidor em baixo”; os passos são os mesmos.

Passo 1: o que exatamente está fora do ar?

“O servidor caiu” pode significar três coisas bem diferentes, e cada uma tem a sua solução. Verifique primeiro de fora, a partir de uma rede que não seja a sua. Para os sites hospedados no servidor, o website down checker diz em segundos se o nome é resolvido, se a porta responde e qual código de status volta. Para a máquina, use ping e um teste de portas a partir do seu computador:

ping -c 3 203.0.113.10
nc -zv -w 5 203.0.113.10 22
nc -zv -w 5 203.0.113.10 443

Leia os resultados em conjunto:

• Nada de ping, nada de SSH, nada de porta web: a máquina está desligada, travada, ou a rede na frente dela caiu. Vá ao passo 2.
• O ping responde, o SSH não: a máquina funciona, mas o SSH está bloqueado, parado, ou o servidor está sobrecarregado demais para responder. Vá ao passo 3.
• O SSH funciona, o site não: o servidor está bem, um serviço não. Vá ao passo 4.

Alguns servidores não respondem a ping de propósito. Se o ping nunca funcionou, confie nos testes de porta.

Passo 2: nada responde

Abra primeiro o painel do cliente ou o console de nuvem do seu provedor. Três perguntas resolvem a maioria dos casos em um minuto:

1. O servidor está ligado? Uma instância parada, uma conta suspensa ou um pagamento recusado parecem, vistos de fora, exatamente uma falha.
2. Há um problema conhecido? Veja a status page do provedor para a sua região ou o seu data center.
3. O que o console mostra? O console web ou serial mostra a tela da máquina mesmo sem rede. Um kernel panic, “Out of memory: Killed process” repetido ou uma inicialização parada na verificação do sistema de arquivos dizem onde está o problema.

Se a máquina travou, reiniciar pelo console costuma trazê-la de volta. Antes de reiniciar, tire uma captura de tela do console: depois do reinício, a pista some. Se ela não inicia mais, use o sistema de recuperação do provedor para montar o disco, ler os logs e corrigir o /etc/fstab ou a configuração de rede.

Passo 3: o ping responde, o SSH não

A máquina está viva, então a causa está dentro dela. Entre pelo console e verifique os suspeitos de sempre:

sudo ufw status verbose
sudo iptables -S | head -n 30
sudo fail2ban-client status sshd
sudo systemctl status ssh sshd 2>/dev/null | grep -E 'Loaded|Active'

Uma regra de firewall adicionada às pressas, seu endereço IP banido depois de algumas senhas erradas ou uma configuração do SSH que não passou no próprio teste são os bloqueios mais comuns. Libere seu endereço com sudo fail2ban-client set sshd unbanip SEU_IP e rode sempre sudo sshd -t antes de reiniciar o SSH. Se o SSH funciona, mas está lentíssimo, o servidor está sobrecarregado: vá ao passo 4.

Passo 4: você entrou, leia quatro números

uptime
free -m
df -h
df -i
sudo dmesg -T | grep -iE 'oom|killed process|i/o error|read-only' | tail -n 20

• Carga (uptime): muito acima do número de núcleos significa máquina sobrecarregada. top ou htop mostra qual processo é o culpado.
• Memória (free -m): sem memória livre nem swap, e com “Killed process” no dmesg, o kernel encerrou um processo para sobreviver. Em geral é o banco de dados ou o PHP.
• Disco (df -h): disco cheio é a causa mais frequente de servidor fora do ar. Bancos de dados param de gravar, logs são interrompidos, sessões falham. df -i verifica os inodes: um disco pode estar “cheio” com gigabytes livres se milhões de arquivos pequenos ocupam todos os inodes.
• Erros de I/O ou sistema de arquivos somente leitura no dmesg: o próprio disco tem um problema. Pare de gravar, copie o que puder e fale com o seu provedor.

Para liberar espaço sem risco, comece pelo journal do sistema e pelos arquivos antigos:

sudo journalctl --vacuum-size=200M
sudo du -xh / --max-depth=2 2>/dev/null | sort -h | tail -n 15

Nunca apague arquivos do banco de dados ou do site para abrir espaço.

Passo 5: qual serviço parou e por quê?

systemctl --failed
sudo journalctl -u nginx -n 50 --no-pager
sudo nginx -t

systemctl --failed lista cada serviço que parou com erro. O log dele dá o motivo: uma porta já ocupada, um erro de sintaxe em um arquivo de configuração, um certificado ausente, espaço esgotado. Teste a configuração antes de cada reinício (nginx -t, apachectl configtest, php-fpm -t) e só então rode sudo systemctl restart SERVICO. Um reinício sem teste pode derrubar um serviço que ainda funcionava pela metade.

Passo 6: o que mudou?

Falhas têm causa, e quase sempre é a última alteração. Procure por ela:

grep -E ' (install|upgrade) ' /var/log/dpkg.log | tail -n 20
last -n 10
sudo journalctl --since "2 hours ago" -p err --no-pager | tail -n 40

Atualizações automáticas, um kernel novo esperando reinício, um deploy, um cron job que encheu o disco de backups, um certificado vencido ou uma alteração de configuração feita por outra pessoa: o que coincide com o início da falha é a pista.

Quando os mesmos problemas voltam

Um servidor que saiu do ar uma vez por disco cheio ou banco de dados parado vai sair de novo. A verificação de fora diz quando ele caiu; a verificação por dentro avisa antes. O agente de servidor envia carga, memória, discos e serviços a partir da própria máquina e avisa quando um disco passa do seu limite ou quando um serviço que você marcou para, enquanto ainda há tempo de agir. O monitoramento de servidores com agente faz parte dos planos pagos.

Quando você não quer fazer tudo isso às 3 da manhã

Se seu servidor está fora do ar e você prefere mandar reparar em vez de procurar sozinho, o Quick Fix, o reparo automático a preço fixo, resolve as causas mais frequentes: reinicia um serviço parado se o teste da configuração passar, libera um disco cheio e renova um certificado vencido, com cópia de segurança antes. Se não bastar, o Deep Fix assume, 24 horas por dia, cobrado em blocos de 15 minutos, com o preço visível antes do pedido; a estimativa é o valor máximo. Os dois trabalham pelo Responder, por SSH como root ou pelo acesso SSH à sua hospedagem compartilhada. Todos os detalhes na página de reparo de servidor 24/7.

Fora do ar? Nós resolvemos. Quick Fix a preço fixo ou Deep Fix em blocos de 15 minutos, no seu servidor ou em uma hospedagem compartilhada com acesso SSH.