Guia do nginx como proxy inverso
Nesta página
Um proxy inverso fica à frente das suas aplicações e passa-lhes os pedidos dos visitantes. Com o nginx à frente, uma aplicação Node.js, um contentor Docker ou um painel a correr numa porta qualquer passa a ser https://app.example.com, com HTTPS, os cabeçalhos certos e um único sítio para gerir tudo.
Este guia configura o nginx como proxy inverso no Ubuntu, passo a passo: o server block, os cabeçalhos, os WebSockets, o HTTPS gratuito e os erros que mais provavelmente vai encontrar.
O que faz um proxy inverso
- Um único ponto de entrada público. O nginx escuta nas portas 80 e 443 e encaminha cada domínio ou caminho para a aplicação certa, pelo que as aplicações nunca ficam expostas diretamente à internet.
- HTTPS num só sítio. O nginx trata dos certificados; as aplicações por trás dele podem falar HTTP simples em localhost.
- Várias aplicações num 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 na aplicação.
Passo 1: instalar o nginx
sudo apt update sudo apt install nginx
Abra http://your-server-ip e deverá ver a página de boas-vindas do nginx. Se usar o ufw, permita o tráfego web com sudo ufw allow 'Nginx Full'.
Confirme que a sua aplicação está a correr 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.
Corra o nginx e as suas aplicações com acesso root total: os planos VPS KVM da HytHost começam em €2.92/mês.
Ver planos VPSPasso 2: criar o server block do proxy
No Ubuntu, cada site tem um ficheiro em /etc/nginx/sites-available/, ativado com uma ligação 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-o, 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 registo A do domínio para o seu servidor e http://app.example.com passa a mostrar a sua aplicação. Execute sempre nginx -t antes de recarregar: apanha os erros de escrita antes de deitarem o site abaixo.
Os cabeçalhos e a barra final
Hostpassa o domínio que o visitante pediu. Sem ele, o nginx envia o endereço deproxy_pass, e as aplicações que constroem links a partir do host deixam de funcionar.X-Real-IPeX-Forwarded-Forpassam o endereço IP do visitante. Sem eles, todos os pedidos parecem vir de127.0.0.1.X-Forwarded-Protodiz à aplicação se o visitante usou HTTPS, para que não entre num ciclo de redirecionamentos.
O pacote nginx do Ubuntu já traz estas linhas em /etc/nginx/proxy_params, por isso include proxy_params; serve de atalho.
A barra final faz diferença. Para uma aplicação num caminho:
location /app/ {
proxy_pass http://127.0.0.1:3000/;
}
Com a barra depois da porta, /app/login chega à aplicação como /login. Sem ela, a aplicação recebe o caminho completo /app/login.
WebSockets
Aplicações de chat, painéis em tempo real e muitos painéis de administração usam WebSockets, que precisam de dois cabeçalhos extra. Adicione este map uma única vez, dentro do bloco http, por exemplo num novo ficheiro /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 ligação em proxy que não envie nada durante 60 segundos; um proxy_read_timeout mais longo mantém abertos os WebSockets inativos. proxy_http_version 1.1 só é o valor predefinido a partir do nginx 1.29.7, e o Ubuntu 24.04 traz a 1.24, por isso mantenha a linha.
Passo 3: HTTPS gratuito 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 gratuito da Let's Encrypt, adiciona as definições HTTPS ao seu server block e pode redirecionar HTTP para HTTPS. Renova o certificado automaticamente; confirme com sudo certbot renew --dry-run. Mais sobre certificados em como obter um certificado SSL gratuito.
Corrigir os erros 502, 504 e 413
| Erro | Causa habitual | Solução |
|---|---|---|
| 502 Bad Gateway | O nginx não consegue chegar à aplicação: está parada, falhou ou escuta noutra porta ou endereço | Inicie a aplicação, verifique a porta com curl http://127.0.0.1:PORT, leia /var/log/nginx/error.log |
| 504 Gateway Timeout | A aplicação demorou mais de 60 segundos a responder | Torne o pedido mais rápido ou aumente proxy_read_timeout nessa location |
| 413 Request Entity Too Large | Um upload excede o limite predefinido do nginx, de 1 MB | Defina client_max_body_size 50m; no server block |
| Ciclo de redirecionamentos | A aplicação não sabe que o visitante usou HTTPS | Passe X-Forwarded-Proto e indique à aplicação que está atrás de um proxy |
Depois de cada alteração: sudo nginx -t e, a seguir, sudo systemctl reload nginx.
Use-o num VPS da HytHost
Um proxy inverso precisa de um servidor onde controle as portas 80 e 443. Os planos VPS da HytHost correm em KVM com acesso root total, armazenamento SSD e proteção DDoS; escolha o Ubuntu 24.04 e siga os passos acima. Corre as suas aplicações em contentores? Configure primeiro o Docker com como instalar o Docker no Ubuntu e associe as portas dos contentores a 127.0.0.1, para que só o nginx lhes consiga chegar.
Perguntas frequentes
Um proxy inverso encaminha pedidos para uma ou mais aplicações por trás dele. Um balanceador de carga é um proxy inverso que distribui os pedidos por várias cópias da mesma aplicação. O nginx faz as duas coisas, com um bloco upstream que lista as cópias.
O nginx não consegue chegar à aplicação por trás dele. Confirme que a aplicação está a correr e a escutar no endereço e na porta indicados em proxy_pass, e leia /var/log/nginx/error.log para ver o motivo exato.
Não, quando a aplicação corre no mesmo servidor. O nginx trata do HTTPS para os visitantes e fala com a aplicação em HTTP simples em 127.0.0.1, que nunca sai da máquina.
Dê a cada aplicação o seu próprio server block com o 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 contentor apenas em 127.0.0.1 e aponte o proxy_pass para ela. Assim os contentores ficam fora da internet pública, o que é importante porque as portas publicadas pelo Docker contornam o ufw.
Aloje as suas aplicações 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?