Erro 503 Service Unavailable: significado e solução

O que é o erro HTTP 503?

503 Service Unavailable significa que o servidor, ou algo na frente dele, não consegue atender sua requisição agora: está sobrecarregado, em manutenção, limitando a taxa de requisições ou não tem nenhum backend saudável para repassá-la. A RFC 9110 o define como uma condição temporária que provavelmente desaparece depois de algum tempo.

O servidor pode adicionar um cabeçalho Retry-After informando quanto tempo esperar. Ao contrário de um 500, que significa que algo quebrou, um 503 diz "agora não", e por isso os sites o usam em manutenções planejadas.

Muitas vezes quem responde não é o seu servidor web, e sim uma camada na frente dele: um balanceador de carga como o HAProxy, um cache como o Varnish, uma CDN como a Cloudflare ou um ingress do Kubernetes. O texto exato diz qual (veja abaixo).

Como o erro 503 aparece

A mensagem diz qual camada respondeu. Estas são as mais comuns, com o software que as escreve:

Seja qual for o texto, a resposta é a mesma: esta requisição não pode ser atendida agora, e a camada indicada na tabela é onde você deve olhar.

Causas comuns do erro HTTP 503

Os motivos habituais pelos quais um servidor, ou uma camada na frente dele, retorna 503:

• Sobrecarga — limites de CPU, memória ou conexões atingidos durante um pico de tráfego, uma publicação viral ou um crawler agressivo
• Manutenção planejada — o site está fora do ar de propósito para uma atualização ou migração; bem feita, com um cabeçalho Retry-After
• Nenhum backend saudável — o balanceador de carga, o proxy ou o ingress não tem nenhum servidor funcionando para enviar a requisição (aplicação travada, verificações de integridade falhando, nenhum pod pronto)
• Limites de taxa ou de conexões — limit_req e limit_conn do nginx respondem 503 por padrão, então um cliente ou crawler muito ativo pode provocá-lo
• Uma aplicação travada ou parada — PHP-FPM, Node.js ou Python parado atrás de um servidor web que continua rodando; no IIS, um pool de aplicativos parado
• Limites de recursos da hospedagem — a hospedagem compartilhada limita CPU, memória e processos por conta
• Um plugin, tema ou atualização — no WordPress e em outros CMS, uma atualização ruim pode travar a aplicação ou deixar o site preso no modo de manutenção
• Um ataque — um DDoS ou uma enxurrada de bots esgota os mesmos recursos que um pico de tráfego

Solução para visitantes: o que você pode fazer

Se você está visitando o site de outra pessoa, o problema está do lado dela. Veja o que você pode fazer:

• Espere e tente de novo — um 503 existe para ser temporário; espere um minuto e recarregue uma única vez. Se a página mostrar um tempo de Retry-After ou uma mensagem de manutenção, espere esse tempo
• Verifique se está fora do ar para todos — o Verificador de site fora do ar da DNS Robot testa o site de fora da sua rede
• Veja a página de status ou as redes sociais do site — manutenções planejadas e quedas costumam ser anunciadas
• Tente outra rede — se o site carrega com dados móveis, ou uma VPN ou proxy da sua rede habitual está respondendo com o 503, ou o site está limitando a taxa de requisições do seu endereço IP

Solução 1: descubra qual camada enviou o 503

Antes de reiniciar qualquer coisa, olhe a mensagem e os cabeçalhos da resposta: eles dizem qual camada respondeu. Verifique de fora com o Verificador de headers HTTP da DNS Robot ou com curl -sI, e observe o cabeçalho server e o corpo da página (veja a tabela acima).

Depois reinicie a camada que está falhando, não apenas o servidor web:

# Restart Nginx
sudo systemctl restart nginx

# Restart Apache
sudo systemctl restart apache2      # Debian/Ubuntu
sudo systemctl restart httpd         # CentOS/RHEL

# Restart PHP-FPM
sudo systemctl restart php8.2-fpm    # Adjust version as needed

# Restart Node.js (PM2)
pm2 restart all

# Restart entire server (last resort)
sudo reboot

Se o 503 voltar minutos depois de um reinício, a causa continua lá: passe para os recursos e os logs.

Solução 2: verifique os recursos do servidor (CPU, RAM, disco)

Se o servidor está sobrecarregado, reiniciar traz apenas alívio temporário. Verifique o que está consumindo os recursos.

# Check CPU and memory usage
top -bn1 | head -20

# Check disk space
df -h

# Check memory in detail
free -m

# Check active connections
ss -s

# Find processes using the most memory
ps aux --sort=-%mem | head -10

# Find processes using the most CPU
ps aux --sort=-%cpu | head -10

Se a CPU ou a RAM estiver acima de 90%, você precisa otimizar sua aplicação, encerrar processos descontrolados ou fazer upgrade do servidor. Se o espaço em disco estiver cheio, limpe arquivos de log, backups antigos ou arquivos temporários.

Solução 3: verifique os logs de erro

Os logs dizem exatamente por que o 503 aconteceu. Leia as últimas linhas com os comandos abaixo e procure nelas o seguinte:

# Nginx error log
tail -50 /var/log/nginx/error.log

# Apache error log
tail -50 /var/log/apache2/error.log      # Debian/Ubuntu
tail -50 /var/log/httpd/error_log         # CentOS/RHEL

# PHP-FPM log
tail -50 /var/log/php8.2-fpm.log

# WordPress debug log (if WP_DEBUG_LOG is enabled)
tail -50 /var/www/html/wp-content/debug.log

# System log
tail -50 /var/log/syslog

"limiting requests" ou "limiting connections" (nginx) — limit_req ou limit_conn rejeitou a requisição; ele responde 503 a menos que você defina limit_req_status ou limit_conn_status.

"max_children" (PHP-FPM, p. ex. "server reached pm.max_children setting") — todos os workers do PHP estão ocupados: o Apache responde 503, enquanto o nginx responde 502 ou 504.

"AH01114" / "failed to make connection to backend" (Apache mod_proxy) — o Apache não conseguiu alcançar o backend e respondeu 503.

"Too many connections" (MySQL) — o limite de conexões do banco de dados se esgotou.

Os "no live upstreams" e "upstream timed out" do nginx pertencem ao 502 Bad Gateway e ao 504 Gateway Timeout, não ao 503.

Solução 4: desative plugins e temas (WordPress / CMS)

No WordPress e em outros CMS, um plugin pesado pode esgotar os workers do PHP ou os limites de recursos da sua hospedagem, o que gera um 503 (um plugin que trava gera um 500). Se o 503 começou depois de atualizar ou instalar um plugin, comece por ele.

Se você não consegue acessar o painel de administração do WordPress, desative os plugins pelo sistema de arquivos ou pelo banco de dados.

# Disable all plugins by renaming the plugins folder
cd /var/www/html/wp-content
mv plugins plugins_disabled

# If the site loads, rename it back and re-enable plugins one by one
mv plugins_disabled plugins

# To disable a single plugin
mv plugins/problem-plugin plugins/problem-plugin.disabled

Após identificar o plugin com defeito, atualize-o, substitua por uma alternativa ou entre em contato com o desenvolvedor do plugin. Verifique também se sua versão do PHP é compatível — alguns plugins quebram quando o servidor atualiza o PHP.

Preso em "Briefly unavailable for scheduled maintenance"? O WordPress cria um arquivo .maintenance na raiz do site durante as atualizações e o ignora quando ele tem mais de 10 minutos. Apague-o para voltar mais cedo; se a mensagem continuar, procure um arquivo wp-content/maintenance.php ou uma cópia em cache da página.

Solução 5: aumente os limites do PHP e do servidor

Se seu servidor fica sem workers PHP ou atinge limites de memória, você precisa aumentar os limites na configuração.

; PHP-FPM pool (e.g. /etc/php/8.2/fpm/pool.d/www.conf); the default ships with pm.max_children = 5
pm = dynamic
pm.max_children = 50
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 20
pm.max_requests = 500

; php.ini (defaults: memory_limit = 128M, max_execution_time = 30)
memory_limit = 256M
max_execution_time = 300

Reinicie o PHP-FPM depois (sudo systemctl restart php8.2-fpm, com a sua versão) para que os novos limites sejam carregados.

Solução 6: verifique sua CDN ou balanceador de carga

Se você usa a Cloudflare, outra CDN ou um balanceador de carga, o 503 pode vir deles e não do seu servidor.

A regra da Cloudflare (o guia do erro 503 deles):

• A página contém "cloudflare" ou "cloudflare-nginx" — foi gerada pela Cloudflare: verifique se um Worker está acima dos limites de CPU ou memória e depois fale com o suporte da Cloudflare com a saída de /cdn-cgi/trace
• Sem marca da Cloudflare — o seu servidor de origem retornou o 503 e a Cloudflare o repassou: verifique os logs da origem e pergunte à sua hospedagem se ela limita a taxa dos endereços IP da Cloudflare

Com HAProxy, um balanceador de carga em nuvem ou um ingress do Kubernetes, verifique os backends: um 503 ali geralmente significa que nenhum backend conseguiu atender a requisição (em um Application Load Balancer da AWS, que o grupo de destino não tem destinos registrados). O Consulta DNS da DNS Robot confirma que o seu domínio ainda aponta para onde você espera.

Solução 7: verifique ataques DDoS ou de bots

Um pico repentino de tráfego vindo de bots ou um ataque DDoS pode sobrecarregar seu servidor. Verifique seus logs de acesso para padrões suspeitos.

# Count requests per IP in the last 1000 lines
tail -1000 /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -20

# Requests per minute (use -f1-4 for per second)
awk '{print $4}' /var/log/nginx/access.log | cut -d: -f1-3 | uniq -c | sort -rn | head -10

# Block an abusive IP (-I puts the rule first, before any ACCEPT rules)
sudo iptables -I INPUT -s 1.2.3.4 -j DROP

# Or in nginx's server block:
# deny 1.2.3.4;

Se um endereço ou um intervalo pequeno envia milhares de requisições, bloqueie-o no firewall. Atrás da Cloudflare ou de outra CDN, primeiro faça seus logs mostrarem o IP real do visitante (set_real_ip_from mais real_ip_header CF-Connecting-IP no nginx), ou você bloqueará a CDN em vez do atacante. Para um ataque grande, o modo "I'm Under Attack" da Cloudflare ou a proteção DDoS da sua hospedagem filtra o tráfego antes que chegue até você.

Solução 8: corrija problemas de conexão com o banco de dados

Quando o banco de dados fica sem conexões ou para, a aplicação na frente dele pode falhar. Alguns apps respondem 503; o WordPress mostra "Error establishing a database connection". Verifique o banco de dados diretamente:

# Check if MySQL/MariaDB is running (the unit is mysqld on RHEL, mariadb for MariaDB)
sudo systemctl status mysql

# Restart MySQL
sudo systemctl restart mysql

# Check current connections vs limit
mysql -e "SHOW STATUS LIKE 'Threads_connected';"
mysql -e "SHOW VARIABLES LIKE 'max_connections';"

# Increase max connections (temporary)
mysql -e "SET GLOBAL max_connections = 200;"

# Check for long-running queries
mysql -e "SHOW PROCESSLIST;" | head -20

Se você encontrar muitas conexões dormentes, sua aplicação não está fechando as conexões do banco de dados corretamente. Se consultas de longa duração estão bloqueando outras, otimize essas consultas ou encerre-as para desbloquear o banco de dados.

Solução 9: entre em contato com seu provedor de hospedagem

Se você está em uma hospedagem compartilhada, WordPress gerenciado ou uma plataforma como Squarespace, Wix ou Shopify, pode não ter acesso aos logs do servidor ou permissão para reiniciar serviços. Nesses casos, o 503 pode ser causado pela infraestrutura do provedor de hospedagem.

Entre em contato com o suporte do seu provedor de hospedagem e forneça:

• A URL exata que retorna 503
• Quando o erro começou — anote a data e o horário
• O que mudou — você instalou um plugin, atualizou um tema ou alterou configurações de DNS?
• Se é intermitente ou constante — erros 503 intermitentes sugerem limites de recursos; erros 503 constantes sugerem travamento ou configuração incorreta

503 vs outros erros HTTP

O erro 503 é frequentemente confundido com outros erros de servidor. Veja como eles se diferenciam.

A diferença principal: um 503 existe para ser temporário, e um cabeçalho Retry-After pode informar por quanto tempo. Para o rastreamento, o Google trata erros 5xx e 429 do mesmo jeito: seus crawlers desaceleram, e as URLs indexadas são mantidas por um tempo, mas acabam sendo removidas se os erros continuarem (Google Search Central).

Para os erros do lado do proxy, veja 502 Bad Gateway e 504 Gateway Timeout; para limites de taxa, 429 Too Many Requests.

Como prevenir erros 503

Prevenção é melhor do que combater incêndios. Aqui estão as melhores práticas para evitar erros 503.

• Monitore os recursos do servidor — Configure alertas para CPU > 80%, RAM > 85% e disco > 90%. Ferramentas como UptimeRobot, Pingdom ou Grafana fornecem notificações instantâneas.
• Use uma CDN — Cloudflare, Fastly ou AWS CloudFront armazenam em cache ativos estáticos e absorvem picos de tráfego, reduzindo a carga no servidor de origem.
• Ative o cache — Use Redis, Memcached ou Varnish para armazenar em cache consultas ao banco de dados e páginas renderizadas. Usuários WordPress: instale um plugin de cache como WP Super Cache ou W3 Total Cache.
• Auto-escalonamento — Se você usa hospedagem em nuvem (AWS, GCP, Azure, DigitalOcean), configure o auto-scaling para adicionar mais servidores durante picos de tráfego.
• Limite a taxa de bots — Configure Nginx ou Cloudflare para limitar a taxa de crawlers e scrapers agressivos antes que sobrecarreguem seu servidor.
• Otimize consultas ao banco de dados — consultas lentas mantêm conexões e workers ocupados. Adicione índices, otimize joins e guarde os resultados em cache no Redis ou Memcached.
• Use uma página de manutenção adequada — Durante implantações, retorne 503 com um cabeçalho Retry-After em vez de deixar o servidor travar. Isso preserva o SEO e informa os usuários.
• Mantenha o software atualizado — Atualize seu CMS, plugins, PHP e banco de dados para as versões estáveis mais recentes para evitar bugs conhecidos e problemas de segurança.