visto em sites 502 Gateway ruim e 504 Tempo limite do gateway erros geralmente ocorrem porque o servidor web não está obtendo a resposta correta do serviço back-end. Este serviço pode ser PHP-FPM, backend Apache, aplicativo Node.js, serviço API de painel de jogo ou outro aplicativo por trás do proxy.

Esses erros são especialmente comuns em hospedagem, painel de jogo, WHMCS, Pterodactyl, painel de administração personalizado e sistemas de inicialização baseados na web.

1. Diferença entre erro 502 e 504

• 502 Gateway inválido: O servidor web não consegue se conectar ao serviço de back-end ou recebe uma resposta distorcida.
• Tempo limite do gateway 504: O serviço backend parece estar respondendo, mas a resposta não é retornada a tempo.

Portanto, 502 é mais uma falha de conexão/serviço e 504 é um problema de lentidão ou tempo limite.

2. Verificando o status do serviço

Primeiro, verifique se o servidor web e os serviços PHP estão em execução.

systemctl status nginx
systemctl status apache2
systemctl status php-fpm

Nos sistemas CentOS, AlmaLinux ou Rocky Linux, o serviço PHP-FPM pode ser denominado:

systemctl status php-fpm
systemctl status httpd

Se o serviço foi interrompido, reinicie-o:

systemctl restart nginx
systemctl restart php-fpm

3. Revendo arquivos de log

Não é correto prosseguir com suposições para os erros 502 e 504. O arquivo de log mostra a verdadeira causa do erro.

tail -n 100 /var/log/nginx/error.log
tail -n 100 /var/log/apache2/error.log

Em sistemas baseados em CentOS:

tail -n 100 /var/log/httpd/error_log

As seguintes declarações podem ser vistas nos logs:

• conexão() falhou: Não foi possível conectar-se ao serviço de back-end.
• o tempo limite do upstream expirou: O serviço de back-end responde com atraso.
• conexão recusada: O serviço está inativo ou há encaminhamento para a porta errada.
• permissão negada: Há um problema de soquete ou permissão de arquivo.

4. Soquete PHP-FPM ou controle de porta

Nginx se conecta ao PHP-FPM via soquete ou porta. O caminho do PHP-FPM no arquivo de configuração do Nginx e o valor de escuta real do PHP-FPM devem ser os mesmos.

grep -R "fastcgi_pass" /etc/nginx/sites-enabled/
grep -R "listen =" /etc/php/*/fpm/pool.d/www.conf

Por exemplo, se o Nginx usar:

fastcgi_pass unix:/run/php/php8.2-fpm.sock;

O mesmo soquete deve ser ouvido no lado do PHP-FPM:

listen = /run/php/php8.2-fpm.sock

5. Aumentando as configurações de tempo limite

Erros 504 podem ser recebidos em grandes painéis de processamento, mercados de jogo, APIs ou scripts PHP de execução lenta. Os valores de tempo limite do Nginx podem ser aumentados.

nano /etc/nginx/nginx.conf

Os seguintes valores podem ser adicionados ao bloco http ou ao bloco do servidor relevante:

proxy_connect_timeout 300;
proxy_send_timeout 300;
proxy_read_timeout 300;
fastcgi_read_timeout 300;

Teste as configurações e reinicie o Nginx:

nginx -t
systemctl restart nginx

6. Verificando os limites do processo PHP-FPM

Quando o tráfego aumenta, os limites de transação do PHP-FPM podem ser insuficientes. Nesse caso, as solicitações são enfileiradas e ocorre um tempo limite.

nano /etc/php/8.2/fpm/pool.d/www.conf

Configurações de exemplo:

pm = dynamic
pm.max_children = 30
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 10

Estes valores deverão ser ajustados de acordo com a quantidade de RAM do servidor. Definir um valor muito alto aumenta o consumo de RAM.

Erros Comuns

• Alterar configurações sem consultar o arquivo de log
• Não atualizar o caminho do soquete Nginx mesmo que a versão do PHP tenha mudado
• Não corrigindo a consulta lenta real aumentando o tempo limite
• Aumentando os limites do PHP-FPM sem calcular RAM
• Reiniciando o serviço sem testar a configuração do Nginx

Perguntas frequentes

O erro 502 é sempre causado pelo Nginx?
Nginx é apenas aquele que mostra o erro. O verdadeiro problema pode estar no PHP-FPM, no backend do Apache, no aplicativo Node.js ou em outro serviço.

Aumentar o tempo limite é a solução definitiva para erros 504?
Nem sempre. Aumentar o tempo limite proporciona um alívio temporário. A verdadeira solução é encontrar a consulta lenta, o processamento pesado ou o problema de desempenho.

É seguro reiniciar o PHP-FPM?
Geralmente é seguro, mas as solicitações ativas podem ser afetadas por um curto período. Em sistemas ocupados, devem ser preferidas horas de baixo tráfego.

Recomendações de desempenho

• Verifique a versão do PHP-FPM e o caminho do soquete regularmente.
• Examine os logs de consultas lentas no painel da web e nos serviços de API.
• Se a RAM for insuficiente, não aumente o valor max_children do PHP-FPM inconscientemente.
• Reduza a carga de back-end usando um sistema de cache.
• Gerencie logs de erros antes que eles cresçam com o logrotate.

Este artigo foi preparado especialmente para PvPServer.