O erro 502 no WordPress aparece quando o servidor que entrega o site recebe uma resposta inválida da camada que roda o PHP. Segundo a MDN Web Docs (2024), o 502 é da classe 5xx e sinaliza upstream inválido. Quase sempre vem de PHP-FPM derrubado, timeout ou plugin pesado. Corrigir exige achar qual camada caiu.

O erro 502 bad gateway é uma resposta de servidor que avisa que o proxy da frente (Nginx ou Cloudflare) pediu a página ao processo que roda o PHP e recebeu algo quebrado de volta. No WordPress isso raramente é culpa do PHP do site em si: o gatilho costuma ser o PHP-FPM que morreu, um timeout de upstream ou um plugin que travou o processo. Por aparecer na borda da infraestrutura, o erro 502 quase nunca deixa rastro no debug.log do WordPress. Quem cuida de erros como esse encontra o guia completo no hub de erros comuns do WordPress da FULL, e a correção certa depende de identificar a camada que falhou.

Diagnóstico rápido do erro 502: Sintoma e causa raiz

O erro 502 tem 6 causas dominantes, e o diagnóstico leva menos de 5 minutos quando você sabe onde olhar. Na maioria dos chamados que chegam ao suporte da FULL com 502, a pista não está no site, e sim no log do servidor web. A tabela abaixo cruza cada sintoma com a causa técnica e a ação corretiva imediata.

O Nginx registra a linha “upstream prematurely closed connection” enquanto o WordPress permanece em silêncio, e é por isso que recarregar a página não resolve nada. Olhe primeiro a tabela, identifique seu sintoma e vá direto para a seção da causa correspondente.

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.

Perguntas frequentes sobre o erro 502

Próximos passos para estabilizar o servidor

O erro 502 raramente é um bug do WordPress: é a camada que roda o PHP avisando que caiu, e a correção certa depende de achar se o gargalo está no PHP-FPM, no plugin, na memória ou no timeout da borda. Comece pelo log do servidor web, isole o plugin pesado via FTP e só depois mexa na infraestrutura. Para continuar aprendendo a resolver falhas de servidor, o FULL Academy reúne os tutoriais e guias de erros do WordPress em um só lugar, e o caminho mais estável é sair de um servidor que cai por padrão para um ambiente que já nasce dimensionado.