Erro 502 Bad Gateway no Nginx: causas e como corrigir

O Erro 502 Bad Gateway Nginx aparece quando o Nginx (proxy/reverso) não consegue obter uma resposta válida do backend (PHP-FPM, Apache, Node, etc.). Ou seja: a requisição chegou no Nginx, mas morreu no caminho.

Vamos ao diagnóstico prático, do jeito que sysadmin gosta 👇

🔍 O que normalmente causa o erro 502 no Nginx

1. PHP-FPM parado ou travado
2. Socket ou porta errada no fastcgi_pass
3. Timeout entre Nginx ↔ backend
4. Backend sobrecarregado (CPU/RAM)
5. Permissões erradas no socket
6. Falha no Apache (quando Nginx é proxy)
7. Configuração quebrada após update

1️⃣ Verifique os logs (comece sempre aqui)

Nginx

tail -f /var/log/nginx/error.log

Erros comuns:

• connect() failed (111: Connection refused)
• upstream prematurely closed connection
• no live upstreams

PHP-FPM

journalctl -u php-fpm -n 50

ou

tail -f /var/log/php-fpm/error.log

💡 Se o PHP-FPM morreu, o 502 é garantido.

2️⃣ PHP-FPM está rodando?

systemctl status php-fpm

Se não estiver:

systemctl restart php-fpm

Se cair novamente logo após subir → problema de memória, pool ou config.

3️⃣ Socket ou porta do PHP-FPM (erro clássico)

No Nginx:

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

ou

fastcgi_pass 127.0.0.1:9000;

Confirme no PHP-FPM:

grep listen /etc/php-fpm.d/*.conf

⚠️ Tem que bater exatamente.

• Socket ≠ porta
• Caminho errado = 502 imediato

4️⃣ Permissões do socket (muito comum)

Se usar socket:

ls -l /run/php/php-fpm.sock

Usuário do Nginx (nginx ou www-data) precisa ter acesso.

No pool do PHP-FPM:

listen.owner = nginx
listen.group = nginx
listen.mode = 0660

Depois:

systemctl restart php-fpm nginx

5️⃣ Timeout entre Nginx e backend

Sites pesados, WordPress lento, consultas SQL grandes → 502.

No Nginx:

fastcgi_read_timeout 300;
proxy_read_timeout 300;

No PHP:

max_execution_time = 300
memory_limit = 512M

6️⃣ Backend sobrecarregado (WordPress é campeão)

Verifique:

top
htop
free -m

Se PHP-FPM:

ps aux | grep php-fpm

Erros comuns:

• pm.max_children baixo demais
• VPS sem RAM → OOM Killer mata o PHP

Ajuste no pool:

pm = ondemand
pm.max_children = 20
pm.process_idle_timeout = 10s

7️⃣ Nginx como proxy do Apache (DirectAdmin, cPanel)

Teste se o Apache responde:

curl -I http://127.0.0.1:8080

Se falhar:

systemctl restart httpd

Se Apache caiu → Nginx retorna 502.

8️⃣ Teste a config antes de reiniciar

nginx -t

Nunca reinicie Nginx sem isso em produção 🙃

🧠 Resumo rápido (checklist)

✔ PHP-FPM rodando
✔ Socket/porta correta
✔ Permissões no socket
✔ Timeouts ajustados
✔ Backend com RAM suficiente
✔ Apache funcionando (se existir)
✔ Logs sem erro crítico

FAQ