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?
| Nginx | Caddy | |
|---|---|---|
| HTTPS | Via Certbot, configurado à parte | Automático: emite e renova sozinho |
| Configuração | Mais verbosa, muito documentada | Poucas linhas por site |
| Ajuste fino (cache, limites, regras) | Muito amplo | Suficiente para a maioria dos casos |
| Quando escolher | Já usa Nginx, precisa de cache ou regras complexas | Quer 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.
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-Forvindo apenas do IP do proxy (no Nginx de destino, comset_real_ip_from 10.10.10.10;ereal_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 linkshttp://. - 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.brretorna 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:8080e 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-Protoacima. - Upload falha com 413: aumente
client_max_body_sizeno 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.
