VPS para reverse proxy com Nginx, Caddy e Traefik

Resposta direta

Uma VPS para reverse proxy funciona como a porta de entrada de várias aplicações, recebendo tráfego HTTP e HTTPS nas portas 80 e 443 e encaminhando cada requisição para o serviço correto. Com Nginx, Caddy ou Traefik, você consegue hospedar painéis internos, APIs, sites WordPress, aplicações Node.js, containers Docker e ferramentas como n8n usando domínios diferentes no mesmo servidor. A configuração ideal combina DNS apontado para o IP da VPS, certificados TLS válidos, regras de proxy bem definidas, firewall restritivo e logs fáceis de consultar. Para produção básica, uma VPS com 2 vCPUs, 2 GB de RAM, 40 GB de SSD e pelo menos 1 TB de tráfego mensal costuma ser um ponto de partida realista, desde que as aplicações por trás do proxy não consumam todos os recursos.

Resumo rápido

• Reverse proxy centraliza o tráfego de entrada e permite rotear app.exemplo.com, api.exemplo.com e painel.exemplo.com para serviços diferentes na mesma VPS.
• Nginx é a escolha mais tradicional quando você quer controle fino, alta previsibilidade e ampla documentação para cenários HTTP.
• Caddy reduz bastante o trabalho com certificados, porque emite e renova TLS automaticamente quando DNS e portas estão corretos.
• Traefik combina muito bem com Docker, já que descobre containers por labels e atualiza rotas sem editar arquivos a cada deploy.
• Para uso leve, comece com 2 vCPUs, 2 GB de RAM e 40 GB de SSD. Para múltiplos serviços em produção, planeje 4 vCPUs, 8 GB de RAM e monitoramento.
• Exponha publicamente apenas 80, 443 e SSH restrito. Bancos de dados, Redis, filas e painéis administrativos devem ficar em rede privada ou atrás de autenticação.
• Antes de escolher provedor, confirme região, tráfego mensal, tipo de disco, política de snapshots e recursos de firewall no site oficial. Dados de provedores mudam com frequência, por isso a última verificação editorial deste guia foi registrada em 2026-07-16.

O que muda ao usar uma VPS como reverse proxy

Um reverse proxy fica entre a internet e suas aplicações. O visitante acessa um domínio, por exemplo api.exemplo.com, mas a aplicação real pode estar rodando na porta 3000, em um container Docker, em outro processo local ou até em outro servidor privado. A VPS recebe a conexão pública, negocia HTTPS, aplica regras de roteamento e encaminha a requisição para o destino correto. Essa separação parece simples, mas muda bastante a organização da infraestrutura.

Reverse proxy não é só redirecionamento

Redirecionamento manda o navegador para outro endereço. Reverse proxy mantém o endereço original e faz o encaminhamento no lado do servidor. Na prática, isso permite publicar site.exemplo.com em um container WordPress, api.exemplo.com em uma API FastAPI na porta 8000 e n8n.exemplo.com em outro container na porta 5678, tudo usando o mesmo IP público. O usuário não vê portas internas, e você ganha uma camada única para TLS, headers, compressão, limites de upload e logs.

Esse modelo também ajuda quando você precisa crescer sem bagunçar DNS. Em vez de apontar cada domínio para servidores diferentes, você concentra a entrada em uma VPS e altera os backends conforme o projeto evolui. Se amanhã a API sair da mesma máquina e for para uma rede privada, o domínio público continua igual. Só muda o destino configurado no proxy.

Quando essa arquitetura faz sentido

Ela faz mais sentido quando existe mais de uma aplicação ou quando você quer separar responsabilidades. Um único site estático talvez não precise disso. Já um ambiente com painel administrativo, landing page, API pública, automação e webhook se beneficia muito. Quem administra vários projetos na mesma máquina também deve estudar o tema junto com um guia de VPS para múltiplos sites, porque o reverse proxy costuma ser a peça que deixa esses ambientes organizados.

Atenção ao ponto que muita gente ignora: o reverse proxy não aumenta sozinho a capacidade das aplicações. Se o banco de dados estiver lento ou se o container consumir 100 por cento de CPU, o proxy apenas repassa o problema de forma mais organizada. Ele melhora entrada, segurança e operação, mas não substitui otimização da aplicação, cache, banco bem configurado e monitoramento.

Escolha da VPS e dimensionamento para reverse proxy

A VPS que roda o reverse proxy precisa de rede estável, CPU suficiente para TLS e compressão, memória para buffers e logs, além de disco confiável para sistema, certificados e arquivos de acesso. O consumo do proxy puro costuma ser baixo. Um Nginx bem configurado pode encaminhar muitas requisições usando pouca RAM. O problema aparece quando a mesma VPS também hospeda os containers, banco de dados, filas, cache e uploads dos usuários. Nesse caso, o dimensionamento deve considerar o conjunto completo, não apenas o proxy.

CPU, RAM, disco e rede

Para laboratório, 1 vCPU e 1 GB de RAM funcionam, mas esse limite fica apertado assim que entram Docker, logs persistentes e certificados. Para produção pequena, pense em 2 vCPUs, 2 GB de RAM e 40 GB de SSD. Essa configuração suporta um proxy, alguns containers leves e tráfego moderado, desde que bancos pesados fiquem fora ou bem limitados. Para cinco a dez aplicações pequenas, 4 vCPUs, 8 GB de RAM e 80 GB de SSD ou NVMe dão mais folga. NVMe ajuda em logs, builds e I/O de containers, mas não corrige sozinho aplicação mal escrita ou banco sem índice.

Rede também pesa. Um site com imagens, APIs públicas e webhooks pode consumir muito tráfego mensal mesmo com CPU baixa. Confirme no provedor se há franquia, limite de bandwidth, cobrança por transferência ou política de uso justo. DigitalOcean, Vultr, Linode, AWS Lightsail, Hetzner, Contabo e provedores brasileiros podem atender cenários diferentes, mas preço, região, tráfego e tipo de armazenamento precisam ser revisados nas páginas oficiais antes de publicação editorial ou contratação. A coleta de referências para este artigo foi registrada em 2026-07-16.

Tabela de dimensionamento por cenário

Cenário de uso	VPS sugerida	Proxy indicado	Exemplo prático	Pontos de atenção
Laboratório e estudo	1 vCPU, 1 GB RAM, 20 GB SSD	Caddy ou Nginx	2 domínios, 1 API Node.js, 1 painel interno	Sem banco pesado, logs com rotação curta
Produção pequena	2 vCPUs, 2 a 4 GB RAM, 40 GB SSD	Nginx ou Caddy	Site, API, n8n e dashboard em containers	Firewall, backup, TLS e monitoramento básico
Time com Docker	4 vCPUs, 8 GB RAM, 80 GB SSD ou NVMe	Traefik	6 a 12 serviços com deploys frequentes	Labels revisadas, rede Docker dedicada, alertas
Produção crítica	4 a 8 vCPUs, 8 a 16 GB RAM, disco rápido	Nginx ou Traefik	APIs públicas, webhooks e clientes pagantes	Plano de rollback, snapshots, métricas e revisão humana

Se você pretende rodar quase tudo em containers, leia também o guia de VPS para Docker. Ele ajuda a planejar volumes persistentes, redes internas e limites de recursos, pontos que afetam diretamente a estabilidade do reverse proxy.

Nginx como reverse proxy: controle fino e previsibilidade

Nginx é uma escolha muito usada para reverse proxy porque é estável, performático e amplamente documentado. Ele funciona bem quando você quer arquivos de configuração explícitos por domínio, controle de headers, cache, limites de upload e regras específicas para caminhos como /api, /admin ou /webhook. Em uma VPS Ubuntu ou Debian, a instalação costuma ser direta com apt install nginx, seguida de arquivos em /etc/nginx/sites-available e links simbólicos em /etc/nginx/sites-enabled.

Exemplo básico com HTTPS e headers

Um bloco simples para encaminhar app.exemplo.com para uma aplicação local na porta 3000 pode seguir este padrão:

server {
    listen 80;
    server_name app.exemplo.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;
    }
}

Depois disso, o fluxo típico é testar com nginx -t, recarregar com systemctl reload nginx e emitir certificado com Certbot ou outro cliente ACME. Para HTTPS, você também deve redirecionar HTTP para HTTPS, habilitar HTTP/2 quando fizer sentido e ajustar client_max_body_size se a aplicação recebe uploads. Um painel de arquivos pode precisar de 100 MB. Uma API de avatar talvez fique bem com 10 MB. Defina de acordo com o uso real, não por chute.

Quando escolher Nginx

Nginx combina com ambientes em que a configuração muda pouco e precisa ser revisada com calma. Ele é excelente para times que querem versionar arquivos no Git, aplicar revisão por pull request e evitar automação excessiva na camada de entrada. Também funciona bem para WordPress, Laravel, Django, Node.js, Go e aplicações que expõem uma porta local.

O ponto fraco é operacional. A cada novo domínio você cria ou altera um arquivo, testa a sintaxe, recarrega o serviço e cuida do certificado. Isso não é um problema em três aplicações. Em trinta containers que sobem e descem toda semana, vira trabalho repetitivo. Outro cuidado: não use proxy_pass para serviços expostos em 0.0.0.0 sem necessidade. Se o backend só precisa receber tráfego local, deixe-o escutando em 127.0.0.1 ou em uma rede Docker interna. Essa pequena escolha reduz a superfície pública da VPS.

Caddy: SSL automático e configuração enxuta

Caddy ganhou espaço porque resolve uma dor comum de quem configura reverse proxy: certificados TLS. Quando o DNS aponta corretamente para o servidor e as portas 80 e 443 estão abertas, o Caddy consegue emitir e renovar certificados automaticamente via ACME. Isso reduz a quantidade de passos manuais e evita muitos erros comuns de Certbot, cron e renovação esquecida. Para projetos pequenos e médios, essa simplicidade tem valor real.

Caddyfile para múltiplos domínios

Um Caddyfile com três aplicações pode ser bem direto:

app.exemplo.com {
    reverse_proxy 127.0.0.1:3000
}

api.exemplo.com {
    reverse_proxy 127.0.0.1:8000
}

painel.exemplo.com {
    reverse_proxy 127.0.0.1:5678
}

Com poucas linhas, você publica três serviços com HTTPS automático. Para testar localmente, dá para usar caddy validate e depois systemctl reload caddy. Se a aplicação precisa receber IP real do cliente, o Caddy já encaminha headers úteis por padrão, mas você deve validar como seu framework interpreta X-Forwarded-For e X-Forwarded-Proto. Em Express, Laravel, Django e Rails, a confiança em proxies costuma exigir configuração explícita para evitar URLs erradas, cookies sem flag segura ou logs com IP interno.

Cuidados antes de colocar em produção

A simplicidade do Caddy não elimina planejamento. Se você usa Cloudflare ou outro proxy DNS na frente, confira o modo TLS para evitar loop de redirecionamento. Se roda serviços internos, não publique tudo automaticamente só porque ficou fácil. Um painel administrativo deve ter autenticação forte, restrição por IP quando possível ou camada adicional de autenticação. Caddy também permite middlewares, compressão, headers e autenticação básica, mas esses recursos precisam ser documentados para o time.

Caddy é uma ótima escolha para dev solo, pequenas agências e projetos em que a prioridade é reduzir manutenção de TLS. Ele também é amigável quando a equipe não tem um administrador Linux dedicado. Ainda assim, em ambientes grandes com muitos containers dinâmicos, Traefik tende a encaixar melhor. Em ambientes que exigem controle minucioso de cache, regras legadas ou integrações muito específicas, Nginx continua sendo uma opção mais previsível.

Traefik com Docker: roteamento dinâmico para containers

Traefik foi criado com uma ideia bem prática: a infraestrutura muda o tempo todo, então o proxy precisa descobrir serviços automaticamente. Em vez de criar um arquivo por domínio, você adiciona labels nos containers e o Traefik monta as rotas. Isso é especialmente útil em Docker Compose, Swarm e Kubernetes, embora em uma VPS comum o uso mais frequente seja com Docker Compose. Para times que fazem deploys frequentes, essa abordagem reduz trabalho manual e evita esquecimentos.

Labels, redes Docker e descoberta automática

Um exemplo reduzido de serviço com Traefik em Docker Compose pode usar labels assim:

services:
  app:
    image: exemplo/app:latest
    networks:
      - proxy
    labels:
      - traefik.enable=true
      - traefik.http.routers.app.rule=Host(`app.exemplo.com`)
      - traefik.http.routers.app.entrypoints=websecure
      - traefik.http.routers.app.tls.certresolver=letsencrypt
      - traefik.http.services.app.loadbalancer.server.port=3000

networks:
  proxy:
    external: true

A rede proxy deve existir antes, por exemplo com docker network create proxy. O Traefik também precisa estar nessa rede, escutando 80 e 443 no host. A vantagem é clara: subiu um novo container com labels corretas, a rota aparece. Removeu o container, a rota some. Para ambientes com app, api, worker-dashboard, grafana e n8n, isso economiza tempo.

Quando Traefik simplifica a operação

Traefik encaixa bem quando o Docker é parte central do ambiente. Ele conversa com o Docker socket, identifica labels e aplica certificados. Só que essa integração exige cuidado. Montar /var/run/docker.sock dentro do Traefik dá poder amplo ao container. Em produção, considere usar socket proxy, permissões reduzidas, rede dedicada e dashboard protegido. Nunca deixe o dashboard do Traefik aberto na internet sem autenticação.

Outro ponto é padronização. Defina nomes de routers, services e middlewares de forma consistente. Em times pequenos, bugs aparecem quando cada pessoa cria labels de um jeito. Um serviço usa websecure, outro usa https, outro esquece o certresolver. Documente um modelo e copie sempre a partir dele. Se o ambiente usa muitos containers persistentes, combine essa seção com o planejamento de VPS para Docker, principalmente para volumes, limites de memória e reinicialização após reboot.

DNS, SSL, logs e observabilidade da camada de entrada

Reverse proxy sem DNS correto não sai do lugar. Cada domínio ou subdomínio precisa apontar para o IP público da VPS usando registros A para IPv4 e AAAA para IPv6, se você for usar IPv6. Em um exemplo simples, app.exemplo.com, api.exemplo.com e painel.exemplo.com apontam para o mesmo IP. O proxy diferencia as requisições pelo cabeçalho Host e encaminha cada uma ao backend certo. Se o DNS ainda não propagou, o certificado pode falhar, e o erro nem sempre será claro para iniciantes.

DNS e certificados

Para emitir certificados via ACME, a autoridade certificadora precisa validar que o domínio chega ao servidor correto. O desafio HTTP-01 usa a porta 80. O desafio TLS-ALPN-01 usa a porta 443. Se firewall, security group ou proxy externo bloquearem essas portas, Caddy, Traefik ou Certbot podem retornar erros de validação. Antes de culpar o software, teste com curl -I http://app.exemplo.com e confira se o IP resolvido é o da VPS usando dig app.exemplo.com.

Em ambientes com Cloudflare, Route 53 ou outro DNS gerenciado, cuidado com modo proxy, cache e TLS. Um modo flexível mal configurado pode gerar loop de redirecionamento. Para APIs e webhooks, cache indevido pode causar comportamento estranho. Webhooks de pagamento, por exemplo, devem chegar ao backend sem cache e com método HTTP preservado.

Logs úteis para troubleshooting

Logs são a diferença entre resolver um problema em cinco minutos ou passar a tarde no escuro. No Nginx, acompanhe /var/log/nginx/access.log e /var/log/nginx/error.log. No Caddy, use journalctl -u caddy -f se estiver via systemd. No Traefik, habilite access logs e consulte docker logs traefik. Procure status 502 quando o backend está fora, 504 quando há timeout, 404 quando a rota não casou e 301 ou 308 em loops de redirecionamento.

Um bom teste de produção inclui três checagens: acessar o domínio pelo navegador, testar curl -I https://dominio e simular uma rota crítica da aplicação. Para múltiplos sites, mantenha uma planilha ou arquivo de inventário com domínio, backend, porta, responsável e data da última mudança. Parece burocrático, mas evita confusão quando a VPS passa de dois para dez serviços.

Segurança, hardening e rotina de manutenção

A VPS de reverse proxy fica exposta na internet o tempo todo. Isso exige uma postura diferente de um servidor usado apenas em rede interna. O básico é abrir somente o necessário: 80 e 443 para web, SSH em porta padrão ou alternativa com restrição por chave, e nada mais. Banco de dados, Redis, RabbitMQ, painéis de administração e métricas devem ficar atrás do proxy, em rede interna, por VPN ou protegidos por autenticação forte.

Portas expostas e firewall

No Linux, ufw já resolve muitos cenários simples. Uma política inicial seria permitir OpenSSH, HTTP e HTTPS, depois negar o resto. Em VPS com firewall do provedor, aplique regra parecida também na borda. Duas camadas ajudam quando alguém altera o firewall local por engano. Para quem quer um checklist mais completo, o guia de VPS com firewall e hardening de segurança aprofunda SSH por chave, fail2ban, atualizações automáticas e redução de superfície.

Headers de segurança também ajudam, mas devem ser testados. Strict-Transport-Security força HTTPS, porém pode causar dor de cabeça se aplicado antes de validar todos os subdomínios. X-Frame-Options, Content-Security-Policy e Referrer-Policy melhoram proteção do navegador, mas uma CSP muito rígida pode quebrar frontends que carregam scripts de terceiros. Comece com modo de relatório quando possível.

Backups, snapshots e rollback

O reverse proxy guarda configurações pequenas, mas críticas. Um arquivo errado pode derrubar todos os domínios. Versione configurações de Nginx, Caddyfile, Compose do Traefik e scripts de deploy em Git privado. Antes de grandes mudanças, faça snapshot da VPS quando o provedor oferecer esse recurso e confirme se há custo, retenção e tempo de restauração. Backup automático, snapshot incluso e SLA variam por provedor e plano, então esses pontos devem ser conferidos no site oficial antes de qualquer recomendação comercial.

Tenha também um plano de rollback simples. Se uma mudança no Nginx falhar, nginx -t deve barrar antes do reload. No Caddy, use caddy validate. No Traefik, suba uma alteração em horário de baixo tráfego e acompanhe logs. Para produção com clientes, documente quem pode alterar rotas, onde ficam certificados, como renovar segredos e como recuperar a VPS se uma atualização quebrar o serviço.

Recomendações por perfil

Dev solo ou projeto pessoal

Para um dev solo, Caddy costuma ser o caminho mais rápido. Uma VPS com 1 a 2 vCPUs, 1 a 2 GB de RAM e 20 a 40 GB de SSD dá conta de laboratório, portfólio, uma API pequena e um painel como n8n, desde que você não rode banco pesado junto. O ganho está na configuração curta e no HTTPS automático. Use domínios como app.seudominio.com e api.seudominio.com, mantenha backups dos arquivos de configuração e limite SSH por chave. Se o projeto começar a receber usuários reais, suba para 2 vCPUs e 4 GB de RAM antes de acumular incidentes.

Time pequeno com múltiplos serviços

Para um time com deploys frequentes e aplicações em containers, Traefik tende a reduzir atrito. O padrão ideal é uma VPS com 4 vCPUs, 8 GB de RAM, disco SSD ou NVMe de 80 GB e uma rede Docker externa dedicada ao proxy. Cada serviço ganha labels padronizadas, domínio próprio e porta interna clara. O time deve manter um template de Compose, proteger o dashboard, revisar permissões do Docker socket e registrar mudanças no Git. Essa abordagem evita que cada deploy dependa de editar manualmente arquivos do proxy.

Produção com tráfego real e clientes

Em produção com clientes pagantes, escolha pela previsibilidade operacional, não pela ferramenta da moda. Nginx é excelente quando as rotas são estáveis e exigem controle fino. Traefik funciona muito bem quando containers entram e saem com frequência. Caddy pode ser usado em produção, especialmente quando simplicidade de TLS pesa mais que customização avançada. Planeje pelo menos 4 vCPUs, 8 GB de RAM, monitoramento, logs persistentes, snapshots testados e documentação de rollback. Se a latência para público brasileiro for crítica, avalie regiões no Brasil ou próximas, mas confirme disponibilidade, tráfego e tipo de disco diretamente no provedor antes de decidir.