| Sintoma | Causa raiz | Ação corretiva |
|---|---|---|
| 502 intermitente em horário de pico | PHP-FPM sem workers livres | Aumentar pm.max_children no pool |
| 502 após atualizar plugin | Processo travado por loop ou consulta lenta | Desativar plugin via FTP e revisar |
| 502 só atrás do Cloudflare | Origem demora mais de 100s para responder | Reduzir tempo da origem ou subir timeout |
| 502 ao salvar post longo | Estouro de memory_limit do PHP | Elevar memory_limit no wp-config |
| 502 logo após deploy | OPcache servindo bytecode antigo | Limpar OPcache e reiniciar PHP-FPM |
Legenda: a tela genérica do erro 502 não diz qual camada falhou, por isso o log do servidor é o ponto de partida real.
--- ## Por que o erro 502 some sozinho e volta depois O erro 502 que aparece e some sozinho denuncia esgotamento de recursos, não um arquivo quebrado, e responde por boa parte dos chamados de 502 no suporte da FULL. Quando o PHP-FPM fica sem worker livre porque o tráfego subiu, o Nginx recebe uma resposta vazia do upstream e devolve o 502; em até 1 ou 2 segundos, quando um processo libera, a página volta. A causa técnica é a fila de processos. Cada visita ao WordPress consome um worker do PHP-FPM, e o limite `pm.max_children` define quantos rodam ao mesmo tempo. Em servidor compartilhado com memory_limit baixo, esse teto é apertado: um plugin de backup ou um robô de indexação agressivo enche a fila, e o próximo visitante pega o erro 502. A correção não é recarregar, é dimensionar o pool de PHP-FPM ou migrar para um ambiente com workers garantidos. --- ## Erro 502 por plugin ou tema: Como isolar o culpado Um plugin mal escrito derruba o erro 502 quando ocupa o processo PHP por mais de 30 segundos ou estoura a memória antes de devolver o HTML. Os 3 suspeitos recorrentes são plugins de backup como o UpdraftPlus, importadores de produtos WooCommerce e o Elementor carregado de widgets: eles seguram o worker até o Nginx cortar no timeout do upstream. A lógica de isolamento é idêntica à de outras falhas de tela branca: desativar tudo e reativar em blocos. Sem acesso ao painel, renomeie a pasta `wp-content/plugins` via FTP para derrubar todos de uma vez; se o erro 502 sumir, o culpado está ali. Reative um a um, observando o error.log do Nginx a cada passo. A ferramenta Query Monitor ajuda a flagrar a consulta lenta depois que o site volta. Esse mesmo raciocínio resolve casos de falha de publicação após atualização no WordPress, que também nasce de processo travado. --- ## Erro 502 atrás do Cloudflare: Origem versus borda Com Cloudflare em modo proxy, o erro 502 pode vir de 2 lugares diferentes, e confundir os dois faz você corrigir a camada errada. O Cloudflare tem teto de 100 segundos para a origem responder no plano gratuito; se o WordPress passar disso, é a borda do Cloudflare que cospe o 502, mesmo com o servidor de pé. A página de erro do Cloudflare traz um Ray ID no rodapé, enquanto o 502 da origem mostra a tela do Nginx, e essa é a forma mais rápida de saber quem gerou a resposta. A relação causal é direta: Cloudflare em proxy ativo + origem respondendo acima de 100 segundos por causa de um job de backup em horário de pico = erro 502 servido pela borda, não pela origem. Para confirmar de qual lado vem, pause o proxy do Cloudflare (nuvem cinza) e teste; se o 502 sumir, o gargalo é o tempo de resposta da origem. De acordo com a documentação oficial da Nginx (proxy module), o valor de `proxy_read_timeout` controla quanto o proxy espera o upstream antes de cortar a conexão e gerar o 502. --- ## Erro 502 por php-fpm e memória: A camada que cai primeiro O PHP-FPM é a peça que mais derruba o erro 502, porque executa o código do WordPress por trás do Nginx. Quando um processo estoura o `memory_limit` (o padrão seguro para WooCommerce é 256M) ou bate o `request_terminate_timeout`, o PHP-FPM mata o worker antes de responder, e o Nginx traduz esse silêncio em erro 502. O ajuste fino acontece no arquivo wp-config.php, onde você eleva o limite de memória com segurança até os 256M recomendados. Existe um detalhe que só aparece em operação real. Em servidor compartilhado com Nginx na frente do PHP-FPM, o erro 502 costuma surgir sem nenhuma linha no log do PHP, porque o processo morre antes de conseguir escrever o erro. A pista real fica no error.log do Nginx, na linha "upstream prematurely closed connection", e não no debug.log do WordPress. Quem procura no lugar errado perde horas, e por isso padronizar o ambiente de PHP-FPM é tão decisivo. --- ## Como prevenir o erro 502 com cache e ambiente estável Prevenir o erro 502 custa menos do que apagar incêndio, e a base é tirar carga do PHP-FPM com cache. Um cache de página bem configurado entrega HTML pronto sem acionar o PHP em mais de 80% das visitas, o que reduz a chance de a fila de workers estourar e gerar o 502. O WP Rocket e o LiteSpeed Cache cobrem isso; depois de ativar, limpe o cache antigo seguindo o passo a passo de como limpar o cache no WordPress. O segundo pilar é o ambiente. Servidor com PHP-FPM de workers garantidos, OPcache ativo e PHP 8.2 em diante sofre muito menos com erro 502 do que hospedagem compartilhada barata. Vale medir o tempo de resposta antes e depois com ferramentas de teste de desempenho: um TTFB acima de 600 ms já sinaliza upstream sob pressão. Para sair do servidor que cai, a hospedagem gerenciada com ambiente padronizado é o caminho mais direto. --- ## Plano PRO da FULL: Ambiente padronizado por r$85 por site Boa parte dos chamados de erro 502 some quando o site sai de um servidor instável e passa a rodar num ambiente padronizado, com PHP-FPM dimensionado e os plugins de performance já inclusos. O plano PRO da FULL custa R$849 e cobre até 10 sites, o que dá R$85 por site, com WP Rocket, Perfmatters e All in One Security no mesmo bundle que a gente usa para estabilizar o upstream. Em vez de licenciar cada plugin de cache avulso e ainda brigar com a hospedagem, você conecta o site e padroniza o ambiente de uma vez. Veja os planos da FULL para comparar o custo por site. ---Porque ele denuncia esgotamento de recursos, não um arquivo quebrado. Quando o PHP-FPM fica sem worker livre em um pico de tráfego, o Nginx recebe resposta vazia do upstream e devolve o 502; assim que um processo libera, a página volta. O padrão intermitente quase sempre significa pool de PHP-FPM subdimensionado, e a correção é elevar o pm.max_children, não recarregar a página.
Sim, em parte: via FTP você renomeia a pasta wp-content/plugins para derrubar todos os plugins de uma vez e testar se o 502 some, além de elevar o memory_limit no wp-config.php para 256M. O que exige a hospedagem é ajustar workers do PHP-FPM e timeout do Nginx. Sem esse acesso, o teto prático é isolar o plugin culpado e abrir um chamado com o log do erro 502 em mãos.
O erro 502 significa que o proxy recebeu uma resposta inválida do upstream, e o 504 significa que o upstream nem respondeu dentro do prazo. Na prática, o 502 costuma vir de processo PHP-FPM que morreu, e o 504 de processo que travou e estourou o timeout de 60s ou mais. Ambos são da classe 5xx, mas o 504 sempre aponta para lentidão, enquanto o 502 pode ser queda seca do worker.
Em geral segundos, desde que o OPcache e o PHP-FPM sejam reiniciados. O 502 logo após um deploy costuma vir do OPcache servindo bytecode antigo de arquivos que já mudaram; limpar o OPcache e dar reload no PHP-FPM resolve quase na hora. Se o 502 persistir além de 1 ou 2 minutos depois disso, o problema migrou para outra camada, como um plugin novo ou um timeout de upstream.
O Cloudflare impõe um teto de 100 segundos para a origem responder no plano gratuito; se o WordPress demorar mais que isso, é a borda do Cloudflare que devolve o erro 502, e não o servidor. A pista é o Ray ID no rodapé da página de erro. Para confirmar, pause o proxy (nuvem cinza) e teste: se o 502 sumir, o gargalo é o tempo de resposta da origem, geralmente um plugin pesado em horário de pico.