VPS · Guia

Guia do nginx como proxy inverso

Atualizado October 11, 2026 5 min de leitura

Nesta página
  1. O que faz um proxy inverso
  2. Passo 1: instalar o nginx
  3. Passo 2: criar o server block do proxy
  4. Os cabeçalhos e a barra final
  5. WebSockets
  6. Passo 3: HTTPS gratuito com Certbot
  7. Corrigir os erros 502, 504 e 413
  8. Use-o num VPS da HytHost
  9. FAQ

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.com e example.com/blog podem 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 VPS

Passo 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

  • Host passa o domínio que o visitante pediu. Sem ele, o nginx envia o endereço de proxy_pass, e as aplicações que constroem links a partir do host deixam de funcionar.
  • X-Real-IP e X-Forwarded-For passam o endereço IP do visitante. Sem eles, todos os pedidos parecem vir de 127.0.0.1.
  • X-Forwarded-Proto diz à 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

ErroCausa habitualSolução
502 Bad GatewayO nginx não consegue chegar à aplicação: está parada, falhou ou escuta noutra porta ou endereçoInicie a aplicação, verifique a porta com curl http://127.0.0.1:PORT, leia /var/log/nginx/error.log
504 Gateway TimeoutA aplicação demorou mais de 60 segundos a responderTorne o pedido mais rápido ou aumente proxy_read_timeout nessa location
413 Request Entity Too LargeUm upload excede o limite predefinido do nginx, de 1 MBDefina client_max_body_size 50m; no server block
Ciclo de redirecionamentosA aplicação não sabe que o visitante usou HTTPSPasse 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.

FAQ

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 hours

Este guia foi útil?