Erro 502 bad gateway na loja virtual: o que 502, 503 e 504 significam e qual deles é falta de servidor

502, 503 e 504 são três respostas diferentes do servidor web sobre a mesma pergunta — ele pediu a página para a aplicação e algo deu errado. Só um padrão aponta para falta de capacidade: o erro que aparece quando o acesso sobe e some sozinho quando o acesso cai.

O que significa o erro 502 bad gateway na loja virtual

O erro 502 bad gateway na loja virtual quer dizer que o servidor web da frente — o Nginx ou o Apache, o programa que atende o navegador do cliente — pediu a página para a aplicação que roda atrás dele e não recebeu uma resposta válida de volta. Essa aplicação de trás é o PHP-FPM, o Node, o processo que executa o código da sua loja.

Vale entender a arquitetura em duas camadas, porque ela sustenta a leitura de todos os outros códigos: quem conversa com o navegador é o servidor web; quem monta a página é a aplicação. Os códigos 502, 503 e 504 são o servidor web relatando o que aconteceu com a camada de trás. O 500 é diferente: ele costuma nascer dentro da própria aplicação e só passar pelo servidor web.

E é importante saber o que o 502 não diz: ele não informa o motivo. Diz apenas que a resposta não veio. O motivo está no log, não na tela do cliente.

Para o dono da loja a consequência é direta: o cliente vê uma página branca de erro no meio do checkout e vai embora. E o diagnóstico precisa acontecer enquanto o erro está de pé — depois que passa, sobra pouca coisa para olhar.

Nenhum código sozinho separa aplicação quebrada de máquina no teto. Quem separa é a combinação do código com horário e carga.

Qual a diferença entre erro 500, 502, 503, 504 e ‘não foi possível acessar esse site’

O 503 merece um parágrafo à parte porque é o mais mal lido dos quatro. Ele não é a aplicação travando: é uma recusa explícita de quem está na frente. Em loja montada sobre WordPress e WooCommerce, muitas vezes ele nem vem da aplicação — vem do limite de requisições do Nginx, do modo manutenção que ficou ligado depois de uma atualização ou de uma camada de cache. Antes de concluir qualquer coisa sobre capacidade, descubra qual camada gerou o 503.

E aqui vai a correção que mais economiza tempo de diagnóstico: na pilha mais comum de loja — Nginx na frente, PHP-FPM atrás — falta de vaga na aplicação costuma aparecer como 502 ou 504, não como 503. Quando todos os processos estão ocupados, os pedidos se acumulam na fila; ou a conexão é recusada e vira 502, ou a espera estoura o tempo limite e vira 504.

A regra de leitura que vale para a tabela inteira: quanto mais fundo o erro, mais a aplicação está viva. Um 500 significa que o código executou e quebrou. Um 504 significa que o pedido foi aceito e demorou demais. Um 502 — resposta nenhuma — indica que algo do outro lado está morto, recusando conexão ou saturado. E ausência de código, com o navegador dizendo não foi possível acessar esse site, é o caso mais grave: nem o servidor web conseguiu responder.

O que verificar na VPS no momento em que o erro está acontecendo

• Log de erro do servidor web. É onde 502 e 504 aparecem com a razão técnica: connection refused, upstream timed out, no live upstreams. Upstream é como o Nginx chama a aplicação que está atrás dele — quando o log fala em upstream, está falando do PHP-FPM ou do processo da sua loja.
• Log de erro do PHP-FPM. Mostra processo que morreu e o aviso explícito de que o número máximo de processos filhos foi atingido. Esse aviso é o sinal mais direto de que a aplicação ficou sem vaga.
• Load average comparado ao número de núcleos da VPS. Sem saber quantos núcleos a máquina tem, o número não significa nada — o mesmo valor é tranquilo em uma VPS e crítico em outra.
• Memória e swap. Memória disponível caindo de forma sustentada e swap (o pedaço de disco usado como memória emprestada) em uso ativo é o quadro que antecede processo morto.
• Processo morto pelo OOM killer. Quando a memória acaba, o sistema mata um processo escolhido por um critério que pesa bastante o consumo de memória — na prática, um dos maiores — e registra isso no log do sistema (dmesg, journalctl, syslog). Se o processo da aplicação ou do banco foi morto, o 502 é consequência, não causa.
• Número de workers do PHP-FPM configurado. É quantos pedidos a aplicação consegue atender ao mesmo tempo.

Sobre o último item, uma resposta honesta: não existe número universal de workers. Ele sai de medir quanta memória um processo da sua aplicação consome e comparar com a RAM realmente disponível na VPS — nunca de copiar uma tabela pronta.

Todos esses sinais têm o mesmo defeito em comum: só existem enquanto o erro está acontecendo. Se as métricas não estiverem sendo guardadas com histórico, meia hora depois não sobra evidência de nada — é por isso que monitoramento de VPS vem antes do diagnóstico, e não depois.

A pergunta que separa aplicação quebrada de máquina no teto

É uma pergunta só: o erro acontece também quando tem pouca gente no site?

Se acontece com um visitante só, com a máquina folgada, às três da manhã, é aplicação, configuração ou código. Capacidade não entra na conversa — e comprar plano maior não muda o desfecho.

Se só acontece quando o acesso sobe, e desaparece sozinho quando o acesso cai, sem ninguém mexer em nada, é teto de capacidade.

Existe um caso intermediário que precisa ser dito: o erro começa no pico e continua depois que o acesso já caiu. Normalmente é processo que morreu e não voltou, ou conexão presa no banco. Reiniciar o serviço faz o site voltar e o problema reaparece no pico seguinte — pode ser dimensionamento, mas também pode ser vazamento de memória da aplicação. Aqui só o log separa os dois.

Dá para responder a pergunta sem esperar o próximo pico: compare o horário do erro com o gráfico de acesso do mesmo minuto. Se as duas curvas não coincidem, não é falta de servidor. O roteiro completo de caça ao gargalo está em WooCommerce lento com muito acesso.

Os casos em que aumentar o plano da VPS não resolve nada

• 502 fora do horário de pico. Máquina folgada e erro mesmo assim: o processo da aplicação não subiu, o socket está errado na configuração, o serviço ficou parado depois de um reboot. Máquina maior continua com o processo parado.
• 500 de erro de código. PHP quebrando em uma função, biblioteca faltando, permissão de arquivo errada. Nenhuma relação com tamanho de máquina.
• Erro logo depois de um deploy. Se o erro começou no minuto em que você publicou uma atualização, a causa é a atualização. A primeira ação é comparar o horário do erro com o horário da publicação, não olhar consumo de recurso.
• Limite de conexões do banco mal dimensionado. O banco aceita um número máximo de conexões simultâneas. Se a aplicação pede mais, o erro aparece com processador e memória sobrando — e subir mais réplicas da aplicação piora, porque cada réplica abre mais conexões.
• Plugin travando com um visitante só. Chamada a serviço externo sem tempo limite definido segura o processo até estourar e devolver 504. Um visitante basta.
• Tarefa agendada pesada rodando em horário de venda. O pico de carga é interno, não de cliente.

Em todos esses casos, capacidade extra multiplica o problema em vez de resolver — e ainda aumenta a fatura.

Quando o erro é teto de capacidade de verdade — e onde o burst entra

O padrão que caracteriza teto é estreito: erro que aparece exatamente quando o acesso sobe — em geral 502 ou 504 — com a fila do PHP-FPM cheia ou a memória no limite, e que some sozinho quando o acesso cai. Sem deploy, sem mudança de configuração, sem reinício no meio.

Nesse cenário a aplicação está correta. Ela simplesmente não tem onde rodar mais pedidos ao mesmo tempo. Ajustar workers só redistribui o problema, porque a memória da VPS continua a mesma.

É aqui que entra o burst, em uma frase: a aplicação continua na VPS fixa no dia normal e ganha máquinas extras da nuvem pública só durante o pico; quando a demanda cai, os nós extras são removidos e a cobrança deles termina ali. O conceito está em o que é cloud bursting, e a comparação de custo com trocar de plano está em servidor maior ou reforço só no pico.

A condição de aplicabilidade, dita sem rodeio: só funciona se a aplicação aguentar rodar em mais de uma máquina — sessão e arquivo de upload compartilhados, banco de dados fora do nó de aplicação. E se o erro é de banco no limite de conexões ou de código quebrado, o burst não muda o desfecho.

Descobrir o teto durante a venda é a pior hora possível. Teste de carga mede esse número antes, e o checklist de preparo para a Black Friday cobre o que dá para arrumar sem trocar de servidor.

O que anotar durante a queda para não perder a evidência

Depois que o pico passa, o log rotaciona, o gráfico do painel do provedor perde granularidade e quase ninguém consegue reconstituir o que aconteceu. A janela de evidência é curta — são estes sete registros:

1. Horário exato do início e do fim, com minuto. É o que permite cruzar com deploy, tarefa agendada e curva de acesso.
2. Código exato e a URL em que apareceu — home, categoria, carrinho ou checkout. Erro só no checkout aponta para banco ou integração de pagamento, não para capacidade geral.
3. Print da tela do cliente, incluindo o texto do navegador quando não vem código nenhum.
4. Trecho do log de erro do servidor web e do PHP-FPM naqueles minutos, copiado para fora da máquina antes de rotacionar.
5. Gráfico de carga, memória e swap da janela do incidente.
6. Saída do log do sistema procurando por processo morto por falta de memória.
7. O que mudou nas últimas 24 horas: publicação, plugin novo, atualização de tema, campanha disparada.

Com essas sete coisas anotadas dá para responder a pergunta de diagnóstico depois, com calma. Sem elas, a próxima conversa começa do zero — e a decisão de capacidade volta a ser chute.

Quero o piloto do primeiro pico

Se você já tem o registro da última queda em mãos, é uma conversa no WhatsApp para ler os números junto antes da próxima data de pico.

Perguntas frequentes

Erro 502 é problema do servidor ou do site?

O 502 diz apenas que o servidor web da frente (Nginx ou Apache) pediu a página para a aplicação que roda atrás dele — PHP-FPM, Node, o processo que executa o código da loja — e não recebeu resposta válida. Ele não informa o motivo: pode ser processo caído ou morto, socket recusando conexão ou fila da aplicação cheia. O motivo está no log, não na tela do cliente. Nenhum código sozinho separa aplicação quebrada de máquina no teto; quem separa é a combinação do código com horário e carga.

Meu site deu 503 service unavailable, é falta de memória?

Normalmente não. O 503 é recusa explícita de quem está na frente, não travamento da aplicação: limite de conexões ou de requisições configurado no servidor web, modo manutenção que ficou ligado depois de uma atualização, plugin de cache ou balanceador sem nenhum destino saudável. Na pilha mais comum de loja — Nginx na frente, PHP-FPM atrás — falta de vaga na aplicação costuma aparecer como 502 ou 504, não como 503. Antes de concluir qualquer coisa sobre capacidade, descubra qual camada gerou o 503.

Aumentar o plano da VPS resolve erro 502?

Só resolve quando o padrão é teto de capacidade. Se o 502 aparece fora do horário de pico, com a máquina folgada, a causa é outra: processo da aplicação que não subiu, socket errado na configuração, serviço parado depois de um reboot — e máquina maior continua com o processo parado. O mesmo vale para erro de código (500), erro que começou logo depois de um deploy, limite de conexões do banco mal dimensionado e plugin que trava com um visitante só. Nesses casos, capacidade extra multiplica o problema e ainda aumenta a fatura.

O erro some sozinho quando o acesso cai — isso é teto de capacidade?

Esse é justamente o padrão que caracteriza teto: erro que aparece exatamente quando o acesso sobe, em geral 502 ou 504, com a fila do PHP-FPM cheia ou a memória no limite, e que desaparece sozinho quando o acesso cai — sem deploy, sem mudança de configuração e sem reinício no meio. Existe um caso intermediário: o erro começa no pico e continua depois que o acesso já caiu, o que costuma ser processo que morreu e não voltou ou conexão presa no banco. Aí só o log separa dimensionamento de vazamento de memória da aplicação.

Quantos workers do PHP-FPM eu deveria configurar?

Não existe número universal de workers. O número de workers é quantos pedidos a aplicação consegue atender ao mesmo tempo, e ele sai de medir quanta memória um processo da sua aplicação consome e comparar com a RAM realmente disponível na VPS — nunca de copiar uma tabela pronta. Quando a aplicação fica sem vaga, o sinal mais direto é o aviso no log de erro do PHP-FPM de que o número máximo de processos filhos foi atingido.