Guia de proxy reverso com nginx
Nesta página
Um proxy reverso fica na frente das suas aplicações e repassa para elas as requisições dos visitantes. Com o nginx na frente, um app Node.js, um container Docker ou um painel rodando em alguma porta vira https://app.example.com, com HTTPS, headers corretos e um só lugar para gerenciar tudo.
Este guia configura o nginx como proxy reverso no Ubuntu, passo a passo: o server block, os headers, WebSockets, HTTPS grátis e os erros que você tem mais chance de encontrar.
O que um proxy reverso faz
- Um único ponto de entrada público. O nginx escuta nas portas 80 e 443 e encaminha cada domínio ou caminho para o app certo, então os apps nunca ficam expostos diretamente à internet.
- HTTPS em um só lugar. O nginx cuida dos certificados; os apps atrás dele podem falar HTTP simples em localhost.
- Vários apps em um só servidor.
app.example.com,api.example.comeexample.com/blogpodem ir cada um para um serviço diferente. - Extras: compressão, cache, limites de upload e regras de acesso, sem mexer no app.
Passo 1: instale o nginx
sudo apt update sudo apt install nginx
Abra http://your-server-ip e você deve ver a página de boas-vindas do nginx. Se usa o ufw, libere o tráfego web com sudo ufw allow 'Nginx Full'.
Confira se o seu app está rodando e acessível no próprio servidor, por exemplo com curl http://127.0.0.1:3000. Se isso falhar, o nginx também vai falhar.
Rode o nginx e seus apps com acesso root total: os planos VPS KVM da HytHost começam em €2.92/mês.
Ver planos VPSPasso 2: crie o server block do proxy
No Ubuntu, cada site ganha um arquivo em /etc/nginx/sites-available/, ativado com um link em sites-enabled. Crie /etc/nginx/sites-available/app.example.com:
server {
listen 80;
server_name app.example.com;
location / {
proxy_pass http://127.0.0.1:3000;
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;
}
}
Ative, teste a configuração e recarregue:
sudo ln -s /etc/nginx/sites-available/app.example.com /etc/nginx/sites-enabled/ sudo nginx -t sudo systemctl reload nginx
Aponte o registro A do domínio para o seu servidor e http://app.example.com passa a mostrar o seu app. Sempre rode nginx -t antes de recarregar: ele pega erros de digitação antes que derrubem o site.
Os headers e a barra no final
Hostrepassa o domínio que o visitante pediu. Sem ele, o nginx envia o endereço doproxy_pass, e os apps que montam links a partir do host quebram.X-Real-IPeX-Forwarded-Forrepassam o endereço IP do visitante. Sem eles, toda requisição parece vir de127.0.0.1.X-Forwarded-Protoinforma ao app se o visitante usou HTTPS, para ele não entrar em loop de redirecionamento.
O pacote nginx do Ubuntu já traz essas linhas em /etc/nginx/proxy_params, então include proxy_params; é um atalho.
A barra no final faz diferença. Para um app em um caminho:
location /app/ {
proxy_pass http://127.0.0.1:3000/;
}
Com a barra depois da porta, /app/login chega ao app como /login. Sem ela, o app recebe o caminho completo /app/login.
WebSockets
Apps de chat, dashboards ao vivo e muitos painéis de administração usam WebSockets, que precisam de dois headers extras. Adicione este map uma única vez, dentro do bloco http, por exemplo em um novo arquivo /etc/nginx/conf.d/websocket.conf:
map $http_upgrade $connection_upgrade {
default upgrade;
'' close;
}
Depois, na location:
proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $connection_upgrade; proxy_read_timeout 1h;
O nginx fecha uma conexão com proxy que não envia nada por 60 segundos; um proxy_read_timeout maior mantém abertos os WebSockets ociosos. proxy_http_version 1.1 só é o padrão a partir do nginx 1.29.7, e o Ubuntu 24.04 vem com a 1.24, então mantenha a linha.
Passo 3: HTTPS grátis com Certbot
sudo snap install --classic certbot sudo ln -s /snap/bin/certbot /usr/local/bin/certbot sudo certbot --nginx -d app.example.com
O Certbot obtém um certificado grátis do Let's Encrypt, adiciona as configurações de HTTPS ao seu server block e pode redirecionar HTTP para HTTPS. Ele renova o certificado automaticamente; confira com sudo certbot renew --dry-run. Mais sobre certificados em como conseguir um certificado SSL grátis.
Como corrigir os erros 502, 504 e 413
| Erro | Causa comum | Solução |
|---|---|---|
| 502 Bad Gateway | O nginx não consegue alcançar o app: ele está parado, travou ou escuta em outra porta ou endereço | Inicie o app, confira a porta com curl http://127.0.0.1:PORT, leia /var/log/nginx/error.log |
| 504 Gateway Timeout | O app levou mais de 60 segundos para responder | Deixe a requisição mais rápida ou aumente proxy_read_timeout nessa location |
| 413 Request Entity Too Large | Um upload passa do limite padrão do nginx, de 1 MB | Defina client_max_body_size 50m; no server block |
| Loop de redirecionamento | O app não sabe que o visitante usou HTTPS | Repasse X-Forwarded-Proto e informe ao app que ele está atrás de um proxy |
Depois de cada alteração: sudo nginx -t e, em seguida, sudo systemctl reload nginx.
Rode em uma VPS da HytHost
Um proxy reverso precisa de um servidor em que você controle as portas 80 e 443. Os planos VPS da HytHost rodam em KVM com acesso root total, armazenamento SSD e proteção DDoS; escolha o Ubuntu 24.04 e siga os passos acima. Roda seus apps em containers? Configure o Docker primeiro com como instalar o Docker no Ubuntu e vincule as portas dos containers a 127.0.0.1, para que só o nginx consiga alcançá-las.
Perguntas frequentes
Um proxy reverso encaminha requisições para um ou mais apps atrás dele. Um load balancer é um proxy reverso que distribui as requisições entre várias cópias do mesmo app. O nginx faz as duas coisas, com um bloco upstream que lista as cópias.
O nginx não consegue alcançar o app atrás dele. Verifique se o app está rodando e escutando no endereço e na porta do proxy_pass, e leia /var/log/nginx/error.log para ver o motivo exato.
Não, quando o app roda no mesmo servidor. O nginx cuida do HTTPS para os visitantes e conversa com o app por HTTP simples em 127.0.0.1, que nunca sai da máquina.
Dê a cada app seu próprio server block com seu próprio server_name, como app.example.com e api.example.com, cada um com um proxy_pass para uma porta diferente.
Sim. Publique a porta de cada container só em 127.0.0.1 e aponte o proxy_pass para ela. Assim os containers ficam fora da internet pública, o que importa porque as portas publicadas pelo Docker passam por cima do ufw.
Hospede seus apps atrás do nginx
Os planos VPS KVM da HytHost com acesso root total, armazenamento SSD e proteção DDoS começam em €2.92/mês.
Live chat 8 AM – 11 PM (Chișinău time) · tickets answered during business hoursEste guia foi útil?