Um erro 504 Gateway Timeout significa que um servidor intermediário (Nginx, Apache, Cloudflare ou outro proxy) desistiu de esperar pelo backend que deveria gerar a página. Os culpados mais comuns são um script PHP ou uma consulta ao banco de dados lentos demais, um pool do PHP-FPM esgotado ou um servidor sem recursos. Os visitantes devem tentar de novo em um ou dois minutos; os donos do site devem procurar upstream timed out no error.log do Nginx para descobrir qual elo da cadeia não respondeu.
O que significa o erro 504 Gateway Timeout (vs 502, 503 e 524)
Uma página é entregue por uma cadeia: o navegador, opcionalmente uma CDN como o Cloudflare, o Nginx, o PHP-FPM (às vezes via Apache) e depois o MySQL e APIs externas. Cada elo espera pelo seguinte por um tempo limitado. Quando esse tempo acaba, o proxy devolve 504: ele chegou ao backend, mas não recebeu resposta a tempo.
Um 504 não significa que a ação falhou: o script pode ter concluído a importação, o pagamento ou o envio do e-mail mesmo assim.
| Código | O que aconteceu | Onde olhar |
|---|---|---|
| 500 Internal Server Error | A aplicação travou | Log de erros do PHP, .htaccess, código do tema ou de um plugin |
| 502 Bad Gateway | O backend enviou uma resposta inválida ou derrubou a conexão | PHP-FPM parado, worker encerrado, socket indisponível |
| 503 Service Unavailable | O servidor está recusando requisições temporariamente | Sobrecarga, limites da hospedagem, modo de manutenção |
| 504 Gateway Timeout | O backend não respondeu a tempo | Script lento, banco de dados, fila do PHP-FPM, timeouts |
| 522 (Cloudflare) | O Cloudflare não conseguiu abrir uma conexão TCP com o seu servidor | Servidor fora do ar, firewall, IP errado no DNS |
| 524 (Cloudflare) | Conectou, mas não houve resposta em 125 segundos | Uma requisição longa no servidor, como no 504 |
O que fazer se você é visitante
- Espere 1-2 minutos e recarregue (Ctrl+F5 no Windows, Cmd+Shift+R no macOS).
- Verifique se o site está fora do ar para todos pelos dados móveis ou por um serviço como Down For Everyone Or Just Me.
- Desligue sua VPN ou proxy: também é um gateway e pode devolver seu próprio 504.
- Limpe o cache de DNS se o site mudou de servidor recentemente (
ipconfig /flushdnsno Windows). - Não repita um pagamento na hora. Confira primeiro seu e-mail: o pedido pode ter sido concluído.
Causas comuns no servidor
- Código PHP lento: plugins pesados, relatórios, importações, backups.
- Banco de dados lento: índices ausentes, tabelas inchadas, bloqueios de tabelas.
- APIs externas que não respondem (pagamentos, frete, servidores de licença de plugins). O PHP espera, e o
max_execution_timenão conta esse tempo. - Pool do PHP-FPM esgotado: todos os workers de
pm.max_childrenestão ocupados e as novas requisições entram na fila. - Falta de recursos: CPU em 100%, memória no limite e swap, discos lentos, limites do plano.
- Bots martelando
xmlrpc.php,wp-login.phpou a busca do site. - Timeouts desalinhados, por exemplo, o Nginx espera 300 s enquanto o Apache por trás dele espera só 30 s.
- Problemas de rede: um backend parado, um firewall, um IP antigo no DNS.
Como diagnosticar um 504 sendo dono do site
Descubra qual elo devolveu o 504 e qual requisição travou. Os comandos rodam via SSH; na hospedagem compartilhada, o log de erros costuma ficar no painel de controle. Veja também como diagnosticar um site lento ou erros 5xx.
Passo 1. Meça o tempo até a falha
curl -s -o /dev/null -w "HTTP %{http_code} TTFB %{time_starttransfer}s total %{time_total}s\n" https://example.com/wp-admin/O tempo aponta o culpado: cerca de 30 s é o Apache (Timeout 30 na configuração padrão de alguns painéis), 60 s é o padrão do Nginx, 125 s é o Cloudflare (você verá 524) e 300 s é o nginx.conf padrão de alguns painéis de controle.
Passo 2. 504 do Cloudflare ou 504 da origem
Se curl -sI https://example.com/ mostrar server: cloudflare e cf-ray, a requisição passou pelo Cloudflare. Então observe a página de erro:
- Página com a marca do Cloudflare e Error ao lado de Host: o seu servidor de origem devolveu o 504, então corrija na hospedagem.
- Página simples, sem marca: um problema do lado do Cloudflare. Se persistir, envie ao suporte do Cloudflare o horário, a URL e a saída de
example.com/cdn-cgi/trace. - Erro 524: nenhuma resposta em 125 segundos. Só os planos Enterprise podem aumentar esse limite (até 6000 s).
Teste a origem diretamente, sem passar pelo Cloudflare:
curl -s -o /dev/null -w "%{http_code} %{time_total}s\n" --resolve example.com:443:203.0.113.10 https://example.com/Para tarefas que realmente passam de 125 segundos, o Cloudflare recomenda um subdomínio somente DNS (nuvem cinza) ou uma tarefa assíncrona com consulta periódica de status.
Passo 3. Encontre “upstream timed out” no error.log do Nginx
sudo grep "upstream timed out" /var/log/nginx/error.log | tail -n 20
# per-domain log
sudo tail -f /var/log/nginx/domains/example.com.error.log2026/09/11 14:20:01 [error] 1187#1187: *48213 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 198.51.100.25, server: example.com, request: "POST /wp-admin/admin-ajax.php HTTP/2.0", upstream: "fastcgi://unix:/run/php/php8.3-fpm.sock:", host: "example.com"while reading response header from upstreamé o caso mais comum: o backend aceitou a requisição, mas não respondeu a tempo (script lento ou fila do PHP-FPM). Controlado porfastcgi_read_timeoutouproxy_read_timeout.while connecting to upstream: o backend está fora do ar, a porta está fechada ou o IP está errado. Controlado porproxy_connect_timeout(fastcgi_connect_timeoutno PHP-FPM).
Mensagens como upstream prematurely closed connection ou (111: Connection refused) significam um 502, não um 504.
Passo 4. Verifique o PHP-FPM: max_children e o slowlog
sudo grep -E "max_children|execution timed out" /var/log/php8.3-fpm.log | tail
# WARNING: [pool www] server reached pm.max_children setting (5), consider raising itEsse aviso significa que todos os workers estavam ocupados. Para ver o que está lento, ative o slowlog no arquivo do pool (por exemplo, /etc/php/8.3/fpm/pool.d/www.conf) e execute sudo systemctl reload php8.3-fpm:
request_slowlog_timeout = 10s
slowlog = /var/log/php8.3-fpm-slow.log[11-Sep-2026 14:19:10] [pool www] pid 2345
script_filename = /var/www/example.com/index.php
[0x00007f8a1c0154e0] curl_exec() /var/www/example.com/wp-includes/Requests/src/Transport/Curl.php:205
[0x00007f8a1c015210] wp_remote_get() /var/www/example.com/wp-content/plugins/some-plugin/api.php:88Aqui o PHP está esperando uma chamada HTTP de saída de um plugin. Se mysqli_query() estiver no topo da pilha, procure uma consulta SQL lenta.
Passo 5. Recursos do servidor e banco de dados
uptime; nproc # load average vs core count
free -h
vmstat 1 5 # wa = disk wait
sudo dmesg -T | grep -i -E "oom|killed process"
sudo mysql -e "SHOW FULL PROCESSLIST"Consultas demoradas ou Waiting for table metadata lock apontam para o banco de dados. Ative o slow query log (SET GLOBAL slow_query_log = 1; SET GLOBAL long_query_time = 2;) e continue com a otimização do banco de dados na hospedagem.
Timeouts: onde ficam e como alinhá-los
Aumente os timeouts só depois de encontrar a causa; caso contrário, o 504 vira uma página que demora cinco minutos para carregar.
| Configuração | Onde | Padrão | Quando excedido |
|---|---|---|---|
| Cloudflare Proxy Read Timeout | Cloudflare, só Enterprise | 125 s | 524 |
| Nginx proxy_read_timeout | nginx.conf: http, server, location | 60 s (alguns painéis: 300 s) | 504 |
| Nginx proxy_connect_timeout | nginx.conf | 60 s, em geral no máx. 75 s | 504 |
| Nginx fastcgi_read_timeout | nginx.conf, junto ao fastcgi_pass | 60 s (alguns painéis: 300 s) | 504 |
| Apache Timeout / ProxyTimeout | apache2.conf ou VirtualHost | 60 s (alguns painéis: 30 s) | 504 |
| PHP-FPM request_terminate_timeout | arquivo do pool em pool.d | 0 (desativado) | worker encerrado, Nginx devolve 502 |
| PHP max_execution_time | php.ini, .user.ini, ini_set() | 30 s (CLI: 0) | Fatal error, página 500 |
A regra: os elos externos esperam mais do que os internos, e o limite rígido do PHP-FPM fica um pouco acima do limite do Nginx. Um exemplo que funciona atrás do Cloudflare: max_execution_time 60 s, fastcgi_read_timeout 90 s, request_terminate_timeout 95 s, Cloudflare 125 s. Sem request_terminate_timeout, um script travado mantém seu worker ocupado depois do 504, e alguns desses bastam para esvaziar o pool.
# Nginx + PHP-FPM
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php8.3-fpm.sock;
fastcgi_read_timeout 90s;
}
; /etc/php/8.3/fpm/pool.d/www.conf
request_terminate_timeout = 95s
php_value[max_execution_time] = 60
# Apache: apache2.conf or VirtualHost
Timeout 90
ProxyTimeout 90
sudo nginx -t && sudo systemctl reload nginx
sudo php-fpm8.3 -t && sudo systemctl reload php8.3-fpmEm alguns servidores com painel de controle e Nginx + Apache, o Timeout padrão do Apache é de 30 s, enquanto o Nginx espera 300 s. Um 504 aos exatos 30 segundos que continua mesmo com um max_execution_time maior é quase sempre o Apache.
Segundo o manual do PHP, no Linux o max_execution_time conta apenas a execução do próprio script, não consultas ao banco de dados, chamadas de sistema ou streams. Um script que espera dois minutos por uma API nunca chega ao Fatal error; o visitante recebe um 504 no lugar. Rode tarefas longas pontuais via WP-CLI ou cron: no CLI o padrão é 0 e o Nginx não participa.
Erros 504 no WordPress
Muitas causas coincidem com os motivos pelos quais o WordPress fica lento, mas estas são as que mais pesam:
- Plugins. Se o erro surgiu depois de uma atualização, rode
wp plugin deactivate --allou renomeiewp-content/pluginse reative os plugins um a um. - wp-cron. As tarefas agendadas rodam a cada visita e ocupam workers do PHP; passe-as para um cron do sistema (abaixo).
- admin-ajax.php e Heartbeat. Abas abertas do painel, construtores de páginas e plugins de estatísticas inundam o
admin-ajax.php; reduza a frequência do Heartbeat. - Opções de autoload inchadas. Desde o WordPress 6.6, a Saúde do Site alerta acima de 800 KB; confira com
wp option list --autoload=on --format=total_bytes. - Consultas e chamadas de API lentas. O Query Monitor mostra as duas coisas, com os tempos.
- Importações e backups. Diminua o tamanho dos lotes, rode tarefas pesadas via WP-CLI e acompanhe a fila de Scheduled Actions do WooCommerce.
- Sem cache. O cache de página mantém a maioria das requisições longe do PHP; veja como cache e RAM na hospedagem trabalham juntos.
# wp-config.php
define( 'DISABLE_WP_CRON', true );
# crontab -e, every 5 minutes
*/5 * * * * cd /home/user/web/example.com/public_html && wp cron event run --due-now >/dev/null 2>&1Hospedagem compartilhada ou VPS: o que você pode mudar
Na hospedagem compartilhada você não pode mudar o fastcgi_read_timeout, mas pode ler o log de erros do domínio no painel, definir max_execution_time no .user.ini (aplicado em até 5 minutos), adicionar cache, atualizar o PHP, remover plugins e enviar ao suporte o horário exato, a URL e o erro. Se os 504 coincidem com os picos de tráfego, o site já ficou grande demais para o plano.
Em uma VPS você controla toda a cadeia. Dimensione pm.max_children pela memória; este comando mostra o tamanho médio de um worker do PHP-FPM:
ps --no-headers -o rss -C php-fpm8.3 | awk '{s+=$1} END {printf "%.0f MB\n", s/NR/1024}'Divida a memória que você pode dar ao PHP por esse número: 2 GB com 80 MB por worker dão cerca de 25 workers. Ir além troca os 504 por swap e pelo OOM killer. Em muitos painéis, o pool padrão de cada domínio usa pm = ondemand com um limite baixo, por exemplo pm.max_children = 8: nesse caso a nona requisição lenta simultânea já espera. Se os pools são gerados a partir de modelos, edite uma cópia personalizada, e coloque as diretivas do Nginx de cada domínio nos arquivos include previstos pelo painel. Um monitoramento da hospedagem regular mostra o pool enchendo antes que os visitantes percebam.
Como verificamos: em 30 de outubro de 2026 comparamos os valores padrão e os limites deste guia com fontes oficiais: documentação do Cloudflare (Connection limits, Error 524, Error 502/504), documentação do Nginx e do Apache, manual do PHP, Google Search Central (erros HTTP e de rede) e os modelos padrão de um painel de controle de código aberto no GitHub (nginx.conf, apache2.conf, modelo de PHP-FPM). As linhas de log e os comandos são exemplos com example.com e endereços IP de documentação.
Perguntas frequentes
Um erro 504 prejudica o SEO?
Um erro breve, não. O Google trata códigos 5xx como temporários e reduz o rastreamento, mas se o erro durar dias, as páginas podem sair aos poucos do índice.
Por que aumentar o max_execution_time não resolveu?
Porque o 504 vem de um proxy, não do PHP. O Nginx, o Apache ou o Cloudflare cortam a requisição antes. Use o tempo até a falha para identificar o elo.
Por que o 504 só aparece no painel do WordPress?
Os visitantes muitas vezes recebem páginas em cache, enquanto o painel sempre executa PHP, além de atualizações, importações, construtores de páginas e admin-ajax.php.
Qual a diferença entre 504 e 524 no Cloudflare?
A causa é a mesma. Um 524 significa que o Cloudflare esperou 125 segundos; um 504 com a marca do Cloudflare significa que o timeout aconteceu no seu próprio servidor.
O DNS pode causar um 504?
Sim, se um proxy ou o Cloudflare ainda apontar para o IP antigo depois de uma migração; nesse caso, o Cloudflare costuma mostrar 522. Nosso guia de migração de hospedagem sem perdas explica como evitar isso.
Conclusão
Um 504 Gateway Timeout é um sintoma, não um diagnóstico: um elo parou de esperar por outro. Meça o tempo até a falha, encontre a entrada “upstream timed out”, verifique o pool do PHP-FPM e o banco de dados, corrija a parte lenta e só então alinhe os timeouts. Se o seu site vive ficando sem recursos, compare os planos de hospedagem da RichHost com armazenamento NVMe e painel de controle próprio com assistente de IA.
