Erro 503: sobrecarga, manutenção ou limite da hospedagem?

O que o erro significa

Com um 503, o servidor web diz: “Estou aqui, mas neste momento não posso atender.” Ao contrário do 502, não há necessariamente algo quebrado, e ao contrário do 500, a aplicação não travou em um erro. O servidor envia o 503 de propósito, em três situações: está em modo de manutenção, atingiu um limite que alguém definiu para ele (conexões, workers, banda, pedidos por segundo) ou está tão carregado que recusa pedidos para não cair de vez. Um 503 pode trazer um cabeçalho Retry-After, que diz aos clientes quando voltar; os buscadores tratam um 503 curto como temporário e não tiram o site do índice.

Causas frequentes

1. Modo de manutenção que ficou travado. Durante uma atualização, o WordPress cria um arquivo .maintenance e responde 503 enquanto ele existir. Se a atualização é interrompida, o arquivo fica, e o erro com ele. Laravel, Magento, Drupal e a maioria dos frameworks têm um interruptor parecido.
2. Sobrecarga. Mais pedidos do que os workers conseguem atender: MaxRequestWorkers do Apache atingido, pm.max_children do PHP-FPM esgotado, ou um banco de dados tão lento que cada worker fica esperando.
3. Um limite da hospedagem. Hospedagens compartilhadas limitam segundos de CPU, processos simultâneos ou “entry processes” por conta. Limite atingido, seu site responde 503.
4. Um backend fora da rotação. Atrás de um balanceador de carga ou de uma CDN, 503 significa que nenhum backend passou na verificação de saúde. O Cloudflare mostra a própria página 503 quando o servidor de origem está sobrecarregado ou limitado por taxa de pedidos.
5. Crawlers e scrapers. Um crawler que baixa milhares de páginas ou um ataque de força bruta contra wp-login.php ou xmlrpc.php consome os workers; os visitantes de verdade recebem 503.
6. Disco ou memória cheios. O serviço funciona, mas não consegue mais gravar sessões, cache ou logs; algumas aplicações respondem então com 503.

Se você é visitante

Espere um minuto e recarregue; um 503 é quase sempre curto. Se um site fica em 503 por horas, quem o administra tem um modo de manutenção travado ou um problema de capacidade; só essa pessoa pode agir.

Se o site é seu: verifique primeiro

Abra o website down checker para confirmar o 503 de fora e ver se quem o enviou foi uma CDN ou o seu servidor. Depois decida: nos últimos minutos começou alguma atualização? Se sim, é o modo de manutenção. Se não, é capacidade.

No seu servidor:

# o servidor web pelo menos funciona?
systemctl status nginx
systemctl status apache2

# carga, memória, disco
uptime
free -m
df -h

# quem está martelando o site?
sudo tail -n 5000 /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head

Uma carga média muito acima do número de núcleos, menos de 100 MB de memória livre ou um único IP com milhares de pedidos nos últimos minutos: cada um explica um 503.

Soluções no seu servidor

1. Sair de um modo de manutenção travado

WordPress: exclua o arquivo .maintenance na raiz do site e abra a página. Se a atualização foi interrompida, um plugin ou o core podem ter ficado instalados pela metade; repita a atualização pelo painel ou com o WP-CLI:

rm /var/www/example.com/.maintenance
wp core verify-checksums
wp plugin update --all

Laravel: php artisan up. Magento: bin/magento maintenance:disable. Drupal: defina $settings['maintenance_mode'] como false ou use drush state:set system.maintenance_mode 0.

2. Parar a avalanche

Bloqueie o IP ou a rede suspeita e depois limite o ritmo dos pedidos, para que a próxima não chegue tão longe.

# bloquear um endereço (Debian/Ubuntu com ufw)
sudo ufw deny from 203.0.113.45

# ou com nftables
sudo nft add rule inet filter input ip saddr 203.0.113.45 drop

Limite de pedidos no nginx para a página de login (no bloco http e depois no bloco server):

limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

location = /wp-login.php {
    limit_req zone=login burst=5 nodelay;
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
}

Apache: mod_evasive ou mod_qos fazem o mesmo; o fail2ban, com as jails apache-badbots e wordpress, bloqueia os reincidentes automaticamente.

3. Dar capacidade ao servidor

Se a carga vem de visitantes de verdade e não de abuso, aumente os limites de workers até onde a memória permitir. Apache (mpm_event): MaxRequestWorkers. PHP-FPM: pm.max_children. Confira antes a memória por worker (ps -ylC php-fpm8.3 --sort:rss), depois teste e recarregue:

sudo apachectl configtest && sudo systemctl reload apache2
sudo php-fpm8.3 -t && sudo systemctl reload php8.3-fpm

Ative um cache de páginas (WordPress: um plugin de cache ou o cache FastCGI do nginx), para que um pico não inicie o PHP a cada pedido. Uma página em cache custa uma fração de milissegundo; sem cache, centenas.

4. Liberar o disco

sudo du -xh --max-depth=1 /var | sort -h | tail
sudo journalctl --vacuum-size=200M
sudo apt clean

Logs antigos, backups no mesmo disco, um log de debug que não para de crescer: os suspeitos de sempre.

5. Atrás de um balanceador de carga

Se todos os backends falham juntos na verificação de saúde, em geral o que está quebrado é a URL da verificação (página apagada, redirecionamento para HTTPS que não é seguido), não cada backend. Abra a URL de verificação à mão a partir do balanceador.

Se o problema está na sua hospedagem

Em uma hospedagem compartilhada você não pode aumentar nenhum limite. Pergunte à sua hospedagem qual limite você atingiu, e se foi o seu tráfego ou outra conta no mesmo servidor:

Prezados, meu site example.com está respondendo “503 Service Unavailable” desde aproximadamente 9h10 (UTC). Não iniciei nenhuma atualização e o site não está em modo de manutenção. Poderiam me dizer se a minha conta atingiu algum limite de recursos (CPU, processos, memória) ou se o servidor está sobrecarregado? Se for a minha conta: qual limite, e desde quando?

Se a resposta é sempre “limites atingidos”, coloque o site em cache de verdade ou passe para um plano ou servidor com mais capacidade.

Para não acontecer de novo

Um 503 se anuncia: a carga sobe, a memória fica escassa, um IP começa a inundar. As verificações do site capturam o 503 assim que ele aparece; o agente de servidor mostra carga, memória e disco antes.

Fora do ar? Nós resolvemos. No seu servidor ou em uma hospedagem compartilhada com acesso SSH, o Quick Fix, o reparo automático a preço fixo, libera espaço em disco e reinicia um serviço travado; o Deep Fix configura o limite de pedidos e o cache, em blocos de 15 minutos, 24 horas por dia, inclusive nos fins de semana, para que o servidor aguente da próxima vez; a estimativa é o valor máximo.