Configure proxy reverso com Nginx ou Caddy para publicar vários sites e VMs do Proxmox em um único IP, com HTTPS automático, WebSocket e IP real.

Para que serve

Um proxy reverso recebe as conexões HTTP/HTTPS da internet e as repassa para o serviço certo, conforme o domínio acessado. No servidor dedicado ele resolve dois cenários comuns:

  • Várias VMs no Proxmox numa rede interna (por exemplo 10.10.10.0/24), cada uma com um sistema ou site, publicadas por um único IP público.
  • Aplicações que escutam em porta local (Node.js na 3000, um painel na 8080, um container Docker) e precisam de HTTPS com domínio próprio.

O proxy também concentra os certificados TLS: as aplicações internas podem continuar em HTTP simples dentro da rede privada.

Proxy reverso: Nginx ou Caddy?

NginxCaddy
HTTPSVia Certbot, configurado à parteAutomático: emite e renova sozinho
ConfiguraçãoMais verbosa, muito documentadaPoucas linhas por site
Ajuste fino (cache, limites, regras)Muito amploSuficiente para a maioria dos casos
Quando escolherJá usa Nginx, precisa de cache ou regras complexasQuer o caminho mais curto até ter HTTPS em vários domínios

Pré-requisitos

  • Uma VM (ou o próprio servidor) com Debian 13 ou Ubuntu 24.04 e um IP público com as portas 80 e 443 liberadas. Em Proxmox, essa VM precisa de uma placa no bridge público e outra no bridge interno. Para montar a rede interna, veja também o artigo «VLAN no Proxmox: como segmentar a rede das VMs com bridges e firewall».
  • Os serviços de destino acessíveis a partir do proxy. Teste com curl -I http://10.10.10.20:80.
  • Os domínios apontando (registro A) para o IP público do proxy.
Não exponha o painel do Proxmox (porta 8006) por proxy reverso para a internet aberta. Acesse-o por VPN ou restrinja por IP de origem. Veja também o artigo «Como liberar o acesso ao Proxmox (porta 8006), SSH e RDP só pela VPN».

Opção A: Caddy

1. Instale pelo repositório oficial

apt install -y debian-keyring debian-archive-keyring apt-transport-https curl gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | tee /etc/apt/sources.list.d/caddy-stable.list
chmod o+r /usr/share/keyrings/caddy-stable-archive-keyring.gpg /etc/apt/sources.list.d/caddy-stable.list
apt update && apt install -y caddy

2. Configure os sites

Substitua o conteúdo de /etc/caddy/Caddyfile:

{
    email ti@suaempresa.com.br
}

erp.suaempresa.com.br {
    reverse_proxy 10.10.10.20:8080
}

app.suaempresa.com.br {
    reverse_proxy 127.0.0.1:3000
}

loja.suaempresa.com.br {
    reverse_proxy 10.10.10.30:80 10.10.10.31:80 {
        lb_policy round_robin
        health_uri /health
    }
}

Só isso: o Caddy emite os certificados, redireciona HTTP para HTTPS, repassa os cabeçalhos X-Forwarded-For e X-Forwarded-Proto e já trata WebSocket.

3. Aplique

caddy validate --config /etc/caddy/Caddyfile
systemctl reload caddy

Opção B: Nginx

1. Instale e crie um trecho reutilizável

apt install -y nginx certbot python3-certbot-nginx

Crie /etc/nginx/snippets/proxy.conf:

proxy_http_version 1.1;
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_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_read_timeout 120s;

E, para o WebSocket funcionar, crie /etc/nginx/conf.d/websocket-map.conf:

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

2. Um server block por domínio

/etc/nginx/sites-available/erp.conf:

server {
    listen 80;
    listen [::]:80;
    server_name erp.suaempresa.com.br;

    client_max_body_size 100m;

    location / {
        proxy_pass http://10.10.10.20:8080;
        include snippets/proxy.conf;
    }
}

Ative e emita o certificado:

ln -s /etc/nginx/sites-available/erp.conf /etc/nginx/sites-enabled/
nginx -t && systemctl reload nginx
certbot --nginx -d erp.suaempresa.com.br

Para balancear entre várias VMs, declare um bloco upstream loja { server 10.10.10.30; server 10.10.10.31; } no arquivo e use proxy_pass http://loja;.

Ajustes na aplicação de destino

  • IP real do visitante: a aplicação passa a ver o IP do proxy. Configure-a para confiar no cabeçalho X-Forwarded-For vindo apenas do IP do proxy (no Nginx de destino, com set_real_ip_from 10.10.10.10; e real_ip_header X-Forwarded-For;).
  • HTTPS: aplicações como WordPress, Laravel e Nextcloud precisam saber que o acesso original foi HTTPS (pelo X-Forwarded-Proto), ou entram em loop de redirecionamento ou geram links http://.
  • Firewall: nas VMs de destino, aceite as portas da aplicação apenas a partir do IP interno do proxy.

O proxy reverso também é o melhor lugar para filtrar ataques na camada de aplicação e padronizar o TLS de todos os sites: veja também os artigos «Como instalar um WAF no servidor: ModSecurity com OWASP CRS e Cloudflare» e «Como desabilitar TLS 1.0 e 1.1 e tirar nota A no SSL Labs (Nginx, Apache e Windows Server)».

Como saber se funcionou

  • curl -I https://erp.suaempresa.com.br retorna o código esperado (200, 301, 302) e o certificado é válido.
  • No log de acesso da aplicação de destino, aparece o IP real do visitante, não o do proxy.
  • Recursos em tempo real (chat, notificações) continuam funcionando, sinal de que o WebSocket passa.

Problemas comuns

  • 502 Bad Gateway: o proxy não alcança o destino. Teste do próprio proxy com curl -v http://10.10.10.20:8080 e verifique o firewall da VM de destino.
  • Caddy não emite o certificado: as portas 80/443 precisam chegar ao Caddy e nenhum outro serviço (Apache, Nginx) pode estar ocupando-as. Veja journalctl -u caddy -n 50.
  • Loop de redirecionamento: a aplicação não reconhece o HTTPS. Veja o item sobre X-Forwarded-Proto acima.
  • Upload falha com 413: aumente client_max_body_size no Nginx do proxy (o Caddy não limita por padrão).
  • Conexão cai após 60 segundos em relatórios longos: aumente proxy_read_timeout.

Perguntas frequentes

O que é um proxy reverso?

É um servidor que recebe as requisições HTTP e HTTPS da internet e as repassa para a aplicação certa, conforme o domínio acessado. Assim, vários sites e VMs ficam publicados por um único IP público.

Proxy reverso esconde o IP do servidor?

Não. O IP do proxy continua público. Ele esconde apenas os IPs internos das VMs. Para não expor o IP de origem, é preciso um serviço como a Cloudflare na frente.

As VMs internas precisam de certificado SSL?

Não necessariamente. O proxy concentra os certificados, e o tráfego entre ele e as VMs pode seguir em HTTP dentro da rede privada. Use HTTPS interno se a política de segurança exigir.

Posso usar o proxy reverso para SSH ou RDP?

Não é o caminho indicado: o proxy reverso descrito aqui trata HTTP e HTTPS. Para SSH, RDP e painéis administrativos, use uma VPN.

Leitura complementar

Precisa de ajuda?

Se ficar com alguma dúvida, abra um ticket na área do cliente ou fale com o suporte pelo WhatsApp.

Esta resposta lhe foi útil? 0 Usuários acharam útil (0 Votos)

Leia também