---
title: "Erro 502 Bad Gateway no Nginx: causas e como corrigir"
description: "Entenda o erro 502 Bad Gateway no Nginx, leia o error.log, ache a causa (app parado, porta errada, PHP-FPM, falta de RAM) e saiba a diferença para o 504."
url: "https://streethosting.com.br/guias/vps/erro-502-bad-gateway-nginx"
category: "vps"
slug: "erro-502-bad-gateway-nginx"
datePublished: "2026-11-13"
dateModified: "2026-11-13"
author: "Equipe StreetHosting"
difficulty: "intermediario"
language: "pt-BR"
keywords:
  - "erro 502 bad gateway nginx"
  - "nginx connection refused upstream"
  - "nginx no live upstreams"
  - "502 php-fpm socket"
  - "nginx 502 vs 504"
  - "nginx error.log"
---

# Erro 502 Bad Gateway no Nginx: como achar a causa e corrigir

O 502 quer dizer que o Nginx tentou falar com a sua aplicação e não recebeu uma resposta válida. Veja como ler o log de erro, o que cada mensagem significa e as causas mais comuns, de app parado a falta de memória.

> **Resposta rápida**
>
> O erro **502 Bad Gateway** quer dizer que o Nginx não recebeu uma resposta válida do servidor que fica atrás dele, o *upstream*: sua aplicação, um contêiner ou o PHP-FPM. Para achar a causa, rode `sudo tail -n 50 /var/log/nginx/error.log` e leia a mensagem. As causas mais comuns são a aplicação parada, a porta ou o endereço errado no `proxy_pass`, o socket do PHP-FPM com caminho ou permissão errada e a aplicação sendo morta por falta de memória. O 504 é outro problema: o upstream respondeu devagar demais.

## O que o 502 significa

Quando o Nginx funciona como proxy reverso, ele recebe o pedido do visitante e o repassa para outro programa: uma aplicação Node.js, um servidor Python, um contêiner Docker, o PHP-FPM. Esse programa de trás é o **upstream**. O código 502 é o jeito do Nginx dizer que a conversa com o upstream deu errado: não conseguiu conectar, ou conectou e recebeu algo que não é uma resposta HTTP válida, ou a conexão foi cortada no meio.

A consequência prática é boa: o erro quase sempre está na aplicação ou na ponte entre ela e o Nginx, não no Nginx. E o Nginx sempre anota o motivo exato no log de erro. A configuração básica do proxy está no [guia de proxy reverso com Nginx](https://streethosting.com.br/guias/vps/configurar-nginx-reverse-proxy-vps); aqui o foco é diagnosticar quando ela não funciona.

## Ler o error.log do Nginx

Abra o log em tempo real, provoque o erro no navegador e leia a linha nova:

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

# ou só as últimas ocorrências de upstream
sudo grep upstream /var/log/nginx/error.log | tail -n 20
```

Cada mensagem aponta para uma causa diferente. As mais comuns:

- **connect() failed (111: Connection refused) while connecting to upstream:** o Nginx chegou no endereço, mas não havia nada ouvindo naquela porta. A aplicação está parada, caiu ou ouve em outra porta ou outra interface.
- **no live upstreams while connecting to upstream:** você definiu um bloco upstream e todos os servidores dele foram marcados como fora do ar depois de falhas seguidas. O Nginx para de tentar por um tempo. A causa real é a mesma de uma conexão recusada: veja a linha de erro anterior.
- **upstream prematurely closed connection while reading response header from upstream:** a conexão abriu, mas a aplicação a fechou antes de responder. Costuma ser queda do processo no meio da requisição, ou o proxy falando um protocolo diferente do que a aplicação espera (por exemplo HTTP numa porta que espera HTTPS).
- **connect() to unix:/run/php/php8.3-fpm.sock failed (13: Permission denied):** o Nginx achou o socket, mas o usuário dele não tem permissão para usar esse socket.
- **connect() to unix:... failed (2: No such file or directory):** o caminho do socket está errado, ou o serviço que cria o socket não está rodando.
- **recv() failed (104: Connection reset by peer):** a aplicação derrubou a conexão de forma abrupta, em geral por um erro interno ou por ter sido reiniciada.

Para investigar a aplicação depois, o [guia de logs na VPS](https://streethosting.com.br/guias/vps/analisar-logs-vps-linux) mostra como ler o journalctl e os logs do serviço.

## Aplicação parada ou travada

A causa número um. A aplicação não está rodando, ou rodou e morreu. Confira o estado de acordo com como você a sobe:

```
# serviço do systemd
systemctl status minha-app
journalctl -u minha-app -n 50 --no-pager

# processo gerenciado pelo PM2
pm2 list
pm2 logs minha-app --lines 50

# contêiner Docker
docker ps -a
docker logs --tail 50 minha-app
```

Se o serviço está parado, o log dele mostra por quê: erro de código, variável de ambiente faltando, porta já em uso, banco fora do ar. Corrija o motivo antes de só reiniciar, senão ele cai de novo. E para a aplicação voltar sozinha depois de um reinício da VPS, configure o serviço no boot: o [guia do PM2 com systemd](https://streethosting.com.br/guias/vps/configurar-pm2-startup-systemd-vps) e o de [criar um serviço systemd](https://streethosting.com.br/guias/vps/criar-servico-systemd-linux) cobrem isso.

Depois, teste a aplicação sem o Nginx, direto na porta dela. Se o curl abaixo responde, o problema está na ponte; se falha, está na aplicação:

```
curl -I http://127.0.0.1:3000
```

## Porta ou endereço errado no proxy_pass

Veja onde a aplicação realmente ouve e compare com o que o Nginx usa:

```
sudo ss -tlnp | grep -E ':3000|:8000|:8080'
sudo nginx -T | grep proxy_pass
```

A saída do ss mostra o endereço e a porta de cada processo que ouve. Os problemas típicos:

- **Porta diferente:** a aplicação sobe na 3001 e o proxy_pass aponta para a 3000. Comum depois de mudar a porta no código ou no arquivo de ambiente.
- **Ouvindo só em IPv6 ou em outra interface:** se o ss mostra `[::1]:3000`, a aplicação ouve só em IPv6 local e um proxy_pass para 127.0.0.1 é recusado. O contrário também acontece. Alinhe os dois lados, e prefira escrever o endereço numérico no proxy_pass em vez de localhost, que pode resolver para IPv6 ou IPv4 conforme o sistema.
- **Aplicação em Docker ouvindo em 127.0.0.1 dentro do contêiner:** dentro do contêiner, 127.0.0.1 é só ele mesmo, e a porta publicada não recebe nada. A aplicação precisa ouvir em 0.0.0.0, e a porta precisa estar publicada no compose, por exemplo `127.0.0.1:3000:3000`.
- **Protocolo errado:** proxy_pass com https para uma porta que fala HTTP simples, ou o contrário, gera upstream fechado ou falha de handshake SSL no log.

Depois de ajustar, valide e recarregue:

```
sudo nginx -t
sudo systemctl reload nginx
```

## Socket do PHP-FPM

Em sites PHP (WordPress, Laravel), o upstream é o PHP-FPM, em geral por um socket Unix. O 502 aqui quase sempre é uma destas três coisas:

1. **O PHP-FPM está parado:** confira com `systemctl status php8.3-fpm` (troque pela versão instalada) e reinicie se preciso.
2. **O caminho do socket mudou:** o nome do socket inclui a versão do PHP. Depois de atualizar o PHP, o fastcgi_pass antigo aponta para um arquivo que não existe mais. Veja o caminho real e compare com a configuração:
3. **A permissão do socket não deixa o Nginx entrar:** o usuário do Nginx (em geral www-data) precisa ter acesso ao socket.

```
ls -l /run/php/
grep -R "fastcgi_pass" /etc/nginx/sites-enabled/
grep -E "^(listen|user|group)" /etc/php/8.3/fpm/pool.d/www.conf
```

No arquivo do pool, as linhas `listen.owner` e `listen.group` definem quem pode usar o socket, e `listen.mode` o modo. O padrão do Ubuntu já usa www-data, então o erro de permissão costuma aparecer quando o Nginx roda com outro usuário ou quando o socket foi movido para uma pasta sem acesso. Se o PHP-FPM ouve em uma porta (127.0.0.1:9000), o fastcgi_pass precisa usar o mesmo endereço.

## Aplicação reiniciando por falta de RAM

Se o 502 vem e vai, ou aparece sob carga, suspeite de memória. Quando a RAM acaba, o kernel do Linux escolhe um processo e o mata (OOM killer). Muitas vezes é justamente a sua aplicação ou o banco. O serviço reinicia sozinho, e durante esses segundos o Nginx devolve 502. Confirme:

```
sudo dmesg -T | grep -i -E "out of memory|killed process"
sudo journalctl -k | grep -i oom
free -h
```

Uma linha como `Out of memory: Killed process 1234 (node)` confirma a causa. As saídas, da mais barata para a mais definitiva:

- **Configurar swap** para dar fôlego em picos. Não faz milagre, mas evita a morte do processo em momentos curtos de pressão. O passo a passo está no [guia de swap no Ubuntu](https://streethosting.com.br/guias/vps/configurar-swap-ubuntu-vps).
- **Reduzir o consumo:** menos processos da aplicação, limite de memória do Node, menos conexões simultâneas no banco, cache mais enxuto.
- **Aumentar a RAM da VPS:** se o uso normal já está perto do limite, é o caminho certo.

> **Atenção**
>
> Não resolva o 502 só colocando a aplicação para reiniciar sempre que cair. Isso esconde o sintoma e deixa o problema de memória voltando sob carga. Descubra o que está consumindo a RAM.

## 502 ou 504: qual é a diferença

Os dois aparecem na frente do Nginx e se confundem, mas contam histórias diferentes:

- **502 Bad Gateway:** o Nginx não conseguiu uma resposta válida. A conexão foi recusada, o upstream fechou antes de responder ou respondeu algo inválido. Aponta para aplicação caída, endereço ou socket errado.
- **504 Gateway Timeout:** o Nginx conectou, esperou e o upstream não respondeu dentro do limite (`proxy_read_timeout`, 60 segundos por padrão). No log aparece `upstream timed out (110: Connection timed out)`. Aponta para aplicação lenta, consulta pesada ou processo preso.

Aumentar o timeout só faz sentido se o trabalho legitimamente demora, como a geração de um relatório. Para uma aplicação que trava, o caminho é achar o gargalo, e não esconder a espera.

> **Dica**
>
> Um roteiro curto para qualquer 502: leia a última linha de upstream no error.log, teste a aplicação com curl direto na porta dela, confira o estado do serviço, compare a porta ou o socket com o que o Nginx usa e, se for intermitente, olhe o dmesg atrás de falta de memória.

## Onde rodar isso na StreetHosting

Diagnosticar um 502 exige ler logs do sistema, ver portas abertas, consultar o dmesg e reiniciar serviços, tudo com acesso root. Nas VPS da StreetHosting a virtualização é KVM, com kernel próprio e root, em São Paulo, então os comandos deste guia funcionam como mostrado, inclusive o dmesg para achar quedas por memória.

Se o problema for falta de RAM de forma recorrente, a VPS Ryzen 9 9950X tem planos de 2 GB até 64 GB com memória DDR5, e a [página de VPS](https://streethosting.com.br/vps) mostra as configurações disponíveis. Todas incluem AntiDDoS e IPv4 dedicado.

## Perguntas frequentes

### O que significa 502 Bad Gateway no Nginx?

Significa que o Nginx, atuando como proxy, tentou falar com o servidor de trás (o upstream, como uma aplicação Node, Python ou o PHP-FPM) e não recebeu uma resposta válida. O problema quase nunca está no Nginx em si, e sim na aplicação, no endereço que ele usa ou na comunicação entre os dois.

### Onde fica o log que explica o 502?

No Nginx padrão do Ubuntu, em /var/log/nginx/error.log. Rode sudo tail -n 50 /var/log/nginx/error.log logo depois de provocar o erro e leia a última linha com a palavra upstream. Ela diz o endereço que o Nginx tentou e o motivo da falha.

### Qual a diferença entre 502 e 504?

No 502 o Nginx recebeu uma resposta inválida ou não conseguiu conectar ao upstream. No 504 o upstream demorou mais do que o limite de espera para responder, em geral depois de aceitar a conexão. O 502 aponta para app caída ou endereço errado, e o 504 para app lenta ou presa.

### Por que o 502 aparece só às vezes?

Quase sempre porque a aplicação cai e volta. Uma queda por falta de memória, um reinício do serviço durante um deploy ou um processo que trava sob carga fazem o Nginx falhar enquanto o app está fora do ar e acertar quando ele volta. Veja o dmesg e o log do próprio serviço.

### Reiniciar o Nginx resolve o 502?

Raramente. O Nginx costuma estar saudável, e o que falha é o que fica atrás dele. Antes de reiniciar qualquer coisa, confira se a aplicação está rodando e ouvindo na porta que o proxy_pass usa. Depois de mudar a configuração, use nginx -t e recarregue com systemctl reload nginx.

## Guias relacionados

- [Como configurar o Nginx como reverse proxy na VPS](https://streethosting.com.br/guias/vps/configurar-nginx-reverse-proxy-vps.md)
- [Como configurar memória swap no Ubuntu da VPS](https://streethosting.com.br/guias/vps/configurar-swap-ubuntu-vps.md)
- [Como analisar logs de uma VPS Linux com journalctl e grep](https://streethosting.com.br/guias/vps/analisar-logs-vps-linux.md)
- [PM2 ou systemd: manter sua aplicação Node sempre online na VPS](https://streethosting.com.br/guias/vps/configurar-pm2-startup-systemd-vps.md)
- [Como criar um serviço systemd no Linux para rodar qualquer app](https://streethosting.com.br/guias/vps/criar-servico-systemd-linux.md)

## Produtos citados

- https://streethosting.com.br/vps

## Dados estruturados

```json
[
  {
    "@context": "https://schema.org",
    "@type": [
      "Article",
      "TechArticle"
    ],
    "headline": "Erro 502 Bad Gateway no Nginx: como achar a causa e corrigir",
    "name": "Erro 502 Bad Gateway no Nginx: causas e como corrigir",
    "abstract": "O 502 quer dizer que o Nginx tentou falar com a sua aplicação e não recebeu uma resposta válida. Veja como ler o log de erro, o que cada mensagem significa e as causas mais comuns, de app parado a falta de memória.",
    "description": "Entenda o erro 502 Bad Gateway no Nginx, leia o error.log, ache a causa (app parado, porta errada, PHP-FPM, falta de RAM) e saiba a diferença para o 504.",
    "datePublished": "2026-11-13",
    "dateModified": "2026-11-13",
    "author": {
      "@type": "Organization",
      "name": "Equipe StreetHosting"
    },
    "publisher": {
      "@type": "Organization",
      "name": "StreetHosting",
      "url": "https://streethosting.com.br"
    },
    "inLanguage": "pt-BR",
    "mainEntityOfPage": {
      "@type": "WebPage",
      "@id": "https://streethosting.com.br/guias/vps/erro-502-bad-gateway-nginx"
    }
  },
  {
    "@context": "https://schema.org",
    "@type": "FAQPage",
    "mainEntity": [
      {
        "@type": "Question",
        "name": "O que significa 502 Bad Gateway no Nginx?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "Significa que o Nginx, atuando como proxy, tentou falar com o servidor de trás (o upstream, como uma aplicação Node, Python ou o PHP-FPM) e não recebeu uma resposta válida. O problema quase nunca está no Nginx em si, e sim na aplicação, no endereço que ele usa ou na comunicação entre os dois."
        }
      },
      {
        "@type": "Question",
        "name": "Onde fica o log que explica o 502?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "No Nginx padrão do Ubuntu, em /var/log/nginx/error.log. Rode sudo tail -n 50 /var/log/nginx/error.log logo depois de provocar o erro e leia a última linha com a palavra upstream. Ela diz o endereço que o Nginx tentou e o motivo da falha."
        }
      },
      {
        "@type": "Question",
        "name": "Qual a diferença entre 502 e 504?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "No 502 o Nginx recebeu uma resposta inválida ou não conseguiu conectar ao upstream. No 504 o upstream demorou mais do que o limite de espera para responder, em geral depois de aceitar a conexão. O 502 aponta para app caída ou endereço errado, e o 504 para app lenta ou presa."
        }
      },
      {
        "@type": "Question",
        "name": "Por que o 502 aparece só às vezes?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "Quase sempre porque a aplicação cai e volta. Uma queda por falta de memória, um reinício do serviço durante um deploy ou um processo que trava sob carga fazem o Nginx falhar enquanto o app está fora do ar e acertar quando ele volta. Veja o dmesg e o log do próprio serviço."
        }
      },
      {
        "@type": "Question",
        "name": "Reiniciar o Nginx resolve o 502?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "Raramente. O Nginx costuma estar saudável, e o que falha é o que fica atrás dele. Antes de reiniciar qualquer coisa, confira se a aplicação está rodando e ouvindo na porta que o proxy_pass usa. Depois de mudar a configuração, use nginx -t e recarregue com systemctl reload nginx."
        }
      }
    ]
  }
]
```