Como configurar um proxy reverso com Nginx para uma aplicação rodando em outra porta

Oi! Aqui é a Sensei da GeHost 🥋 Hoje vou te ensinar um truque muito útil pra quem tem uma aplicação rodando numa porta "escondida" do servidor (tipo localhost:3000, localhost:8080 etc.) e quer que ela apareça bonitinha no seu domínio, sem porta na URL. Isso se chama proxy reverso, e o Nginx é o queridinho pra fazer esse trabalho.

Atenção antes de começar: este guia serve para quem tem acesso via SSH/root a um servidor próprio (VPS ou dedicado) com Nginx instalado. Os planos de hospedagem compartilhada em cPanel da GeHost não oferecem esse tipo de acesso ao servidor. Se sua aplicação está hospedada com a gente e você precisa de algo assim, é só chamar o suporte pelo painel.gehost.com.br que a equipe te orienta sobre a melhor forma de fazer isso no seu plano.

O que é um proxy reverso, afinal?

Imagina que sua aplicação (um sistema, uma API, um app Node.js, Python, etc.) está rodando numa porta específica do servidor, tipo 3000. O problema é que ninguém digita seusite.com.br:3000 no navegador — todo mundo espera acessar direto pelo seusite.com.br, na porta padrão (80 para HTTP, 443 para HTTPS).

O Nginx entra como um "recepcionista": ele recebe a visita na porta 80/443 e, por trás dos panos, encaminha ("proxeia") essa requisição pra sua aplicação na porta real onde ela está rodando. O visitante nunca precisa saber desse detalhe.

Passo 1 — Confirme que sua aplicação está rodando

Antes de mexer no Nginx, teste se a aplicação já responde localmente no servidor. Rode algo assim (ajuste a porta pro número real da sua aplicação):

curl http://127.0.0.1:3000

Se vier alguma resposta (mesmo que seja um erro da própria aplicação), ótimo — significa que ela está de pé e escutando na porta certa. Se der "conexão recusada", o problema é a aplicação, não o Nginx — resolva isso primeiro.

Passo 2 — Crie o arquivo de configuração do site

No Nginx, cada site costuma ter seu próprio arquivo de configuração. Em servidores baseados em Debian/Ubuntu, o caminho comum é /etc/nginx/sites-available/. Crie um arquivo com o nome do seu domínio:

sudo nano /etc/nginx/sites-available/seusite.com.br

Passo 3 — Escreva a regra do proxy reverso

Cole (e adapte) o bloco abaixo, trocando seusite.com.br pelo seu domínio e 3000 pela porta real da sua aplicação:

server {
    listen 80;
    server_name seusite.com.br www.seusite.com.br;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_cache_bypass $http_upgrade;
    }
}

Explicando rapidinho cada linha, sem enrolação:

proxy_pass — é o endereço real da sua aplicação. Essa é a linha mais importante de todas.
proxy_set_header Host / X-Real-IP / X-Forwarded-For — garantem que sua aplicação "enxergue" corretamente o domínio e o IP de quem está acessando, e não pense que tudo veio do próprio servidor.
Upgrade / Connection — deixam funcionar direitinho conexões que precisam ficar "abertas", como WebSocket (bate-papo em tempo real, notificações etc.). Se sua aplicação não usa isso, tudo bem deixar mesmo assim, não atrapalha.

Passo 4 — Ative o site

Depois de salvar o arquivo, crie um link simbólico pra pasta que o Nginx realmente lê (sites-enabled):

sudo ln -s /etc/nginx/sites-available/seusite.com.br /etc/nginx/sites-enabled/

Passo 5 — Teste a configuração antes de aplicar

Esse passo é sagrado: nunca reinicie o Nginx sem testar antes, senão um errinho de digitação pode derrubar todos os sites do servidor. Rode:

sudo nginx -t

Se aparecer syntax is ok e test is successful, pode seguir em frente. Se der erro, ele te mostra exatamente a linha do problema — volte e corrija antes de continuar.

Passo 6 — Recarregue o Nginx

sudo systemctl reload nginx

Pronto! Agora, ao acessar seusite.com.br, o Nginx vai receber a visita e encaminhar tudo pra sua aplicação na porta interna, de forma transparente.

Passo 7 — Não esqueça do HTTPS

Hoje em dia, site sem cadeado é site "desconfiado" pro visitante (e pro Google também). Depois que o proxy estiver funcionando em HTTP, o próximo passo natural é emitir um certificado SSL válido para o domínio e configurar o Nginx pra redirecionar tudo automaticamente de HTTP para HTTPS. Existem ferramentas consagradas do mercado pra automatizar essa emissão — se tiver dúvida em qual usar no seu servidor, é um ótimo assunto pra levar ao suporte técnico.

Erros comuns (e como não cair neles)

502 Bad Gateway — geralmente significa que a aplicação não está rodando na porta configurada, ou caiu. Verifique com o curl do Passo 1.
Porta errada no proxy_pass — confira duas vezes o número da porta. É o erro mais comum de todos.
Esquecer o nginx -t — sempre teste antes de recarregar. Sempre mesmo.
Firewall bloqueando — se a porta interna da aplicação estiver liberada para acesso externo por engano, isso é um risco de segurança; o ideal é que ela só escute em 127.0.0.1 (local) e o Nginx seja o único "porteiro" público.

Ficou com alguma dúvida na hora de aplicar isso no seu servidor, ou não tem certeza se seu plano permite esse tipo de configuração? Chama a gente pelo painel.gehost.com.br — a equipe técnica te ajuda a descobrir o melhor caminho pro seu caso. 💙

Foi isso por hoje! Proxy reverso parece assustador de nome, mas no fundo é só um "recepcionista educado" direcionando visitantes pro lugar certo. Até a próxima aula! 🥋

Como configurar um proxy reverso com Nginx para uma aplicação rodando em outra porta