Cloudflare Tunnel em VPS: acesso seguro sem portas

Resposta direta

Cloudflare Tunnel em VPS permite publicar aplicações internas sem abrir portas públicas diretamente no servidor da aplicação. Em vez de liberar 80, 443 ou portas específicas no firewall, você instala o cloudflared na VPS, cria um túnel de saída para a rede da Cloudflare e aponta subdomínios para serviços locais, como localhost:3000, 127.0.0.1:8080 ou um proxy reverso Nginx, Caddy ou Traefik. A arquitetura funciona bem para painéis internos, APIs administrativas, ambientes de homologação, dashboards e automações. Para produção, o desenho precisa incluir DNS correto, firewall restritivo, autenticação no Cloudflare Access, logs, atualização do agente e um plano de recuperação caso o túnel caia.

Resumo rápido

• Cloudflare Tunnel cria uma conexão de saída da VPS para a Cloudflare, reduzindo a necessidade de portas públicas abertas.
• Uma VPS pequena, com 1 vCPU, 1 GB de RAM e 20 GB de SSD, já atende laboratórios e painéis leves.
• Em produção, prefira 2 vCPUs, 2 GB a 4 GB de RAM, disco SSD ou NVMe e monitoramento básico do serviço.
• O túnel não substitui hardening, firewall, autenticação forte, logs e atualização do sistema operacional.
• Proxy reverso continua útil quando há várias aplicações, headers específicos, compressão, TLS interno ou regras por path.
• DNS deve ser planejado por subdomínio, por exemplo admin.exemplo.com, n8n.exemplo.com e api-interna.exemplo.com.
• LetsCloud, DigitalOcean, Vultr, AWS Lightsail e outros provedores podem rodar essa arquitetura, mas recursos, regiões e preços precisam ser conferidos nas páginas oficiais antes de publicar comparativos.

Como fica a arquitetura com Cloudflare Tunnel em uma VPS

A ideia central do Cloudflare Tunnel é inverter a lógica tradicional de exposição. No modelo comum, você instala a aplicação na VPS, abre portas no firewall, aponta o DNS para o IP público e deixa Nginx, Caddy ou Traefik responder na internet. Funciona, mas aumenta a superfície pública. Qualquer pessoa consegue bater no IP, varrer portas, tentar descobrir versões de serviços e forçar login em painéis mal protegidos. Com o Tunnel, a VPS inicia uma conexão de saída para a Cloudflare usando o agente cloudflared. O tráfego do usuário chega primeiro à borda da Cloudflare e só depois é encaminhado pelo túnel para a origem.

Na prática, um usuário acessa https://admin.seudominio.com. O DNS desse subdomínio fica gerenciado na Cloudflare e aponta para o túnel, não para o IP direto da VPS. A Cloudflare recebe a requisição, aplica as regras configuradas, como Access, WAF conforme plano, políticas de identidade e bloqueios geográficos, e encaminha a conexão ao cloudflared. O agente entrega a requisição para um serviço local, por exemplo http://localhost:3000, ou para um proxy reverso escutando apenas na rede privada da máquina. Isso permite publicar uma interface interna sem abrir a porta 3000 na internet.

Essa arquitetura é útil quando a VPS funciona como gateway seguro para aplicações pequenas ou médias. Um exemplo comum é rodar n8n, Uptime Kuma, Grafana, Portainer, Metabase ou um painel administrativo de Laravel em portas locais. Outro cenário é usar a VPS como ponto intermediário entre uma rede interna e a internet, desde que a conectividade e as políticas de segurança sejam bem desenhadas. Se o projeto já usa proxy reverso, o artigo sobre reverse proxy com Nginx, Caddy e Traefik ajuda a entender como organizar múltiplos serviços atrás de uma única camada de roteamento.

Não confunda isso com tornar a VPS invisível por completo. O IP público ainda existe, o SSH ainda pode estar acessível se você deixar, e processos mal configurados podem escutar em 0.0.0.0. O ganho vem de reduzir portas expostas e centralizar o acesso HTTP e HTTPS pela Cloudflare. Em termos de desenho, o ideal é tratar a VPS como origem protegida: serviços internos escutam em 127.0.0.1, firewall bloqueia entrada desnecessária e o Tunnel publica apenas os hostnames previstos.

Requisitos da VPS: CPU, RAM, disco, rede e sistema

O cloudflared é leve. Em muitos ambientes, ele consome menos de 100 MB de RAM quando há baixo tráfego. Mesmo assim, a VPS precisa ser dimensionada para a aplicação que está atrás do túnel, não apenas para o agente. Um painel administrativo simples em Node.js pode rodar em 1 vCPU e 1 GB de RAM. Já um conjunto com n8n, PostgreSQL, Redis e um proxy reverso fica mais confortável com 2 vCPUs, 4 GB de RAM e 40 GB a 80 GB de SSD. Se houver Grafana, Prometheus, filas ou processamento de arquivos, suba para 4 vCPUs e 8 GB de RAM antes de culpar o Tunnel por lentidão.

Para laboratório, uma configuração inicial razoável é 1 vCPU, 1 GB de RAM, 20 GB de SSD e Ubuntu Server LTS. Para produção pequena, use 2 vCPUs, 2 GB ou 4 GB de RAM, 40 GB de SSD e pelo menos 1 TB de transferência mensal, quando o provedor divulgar esse dado. Em produção com clientes externos, pense em 2 a 4 vCPUs, 4 GB a 8 GB de RAM, disco SSD ou NVMe e snapshots regulares, sempre confirmando se snapshot, backup e tipo de armazenamento estão disponíveis no plano e na localidade escolhida. NVMe ajuda mais quando a aplicação faz leitura e escrita intensiva, como banco local, filas e uploads, mas não corrige uma API mal indexada ou um banco saturado.

Rede também merece atenção. Cloudflare Tunnel cria conexões persistentes de saída, então a qualidade da rota entre a VPS e a rede da Cloudflare influencia estabilidade e latência. Para público brasileiro, uma VPS no Brasil pode reduzir a latência até a origem, mas a rota final depende de DNS, peering, provedor e localização do usuário. Se a aplicação atende usuários no Brasil, datacenter em São Paulo, Rio de Janeiro, Fortaleza ou outra região nacional pode ajudar. Se o painel é usado por uma equipe distribuída, Miami ou costa leste dos EUA pode ser aceitável, desde que os testes reais de latência confirmem.

No sistema operacional, prefira uma distribuição com pacotes atualizados e suporte previsível. Ubuntu 22.04 LTS, Ubuntu 24.04 LTS, Debian 12 e Rocky Linux 9 são escolhas comuns. Instale o cloudflared como serviço do systemd, não como processo solto em uma sessão SSH. Configure reinício automático, acompanhe logs com journalctl e mantenha o pacote atualizado. O mínimo operacional é simples: systemctl status cloudflared, journalctl -u cloudflared -f e alertas quando o serviço ficar inativo. Parece básico, mas é isso que evita descobrir uma queda só quando alguém reclama.

DNS, proxy reverso e roteamento de aplicações

DNS é onde muita configuração de Tunnel começa certa ou errada. Para publicar uma aplicação, você precisa de um domínio gerenciado na Cloudflare e de um hostname associado ao túnel, como admin.exemplo.com. O usuário não precisa saber o IP da VPS. Em vez de criar um registro A apontando para a máquina, você cria uma rota de túnel, geralmente como CNAME para o identificador gerado pela Cloudflare. Pelo painel Zero Trust, esse processo fica mais visual. Pela linha de comando, o cloudflared tunnel route dns registra o hostname para o túnel escolhido.

Um bom padrão é separar aplicações por subdomínio. Use n8n.exemplo.com para automações, grafana.exemplo.com para métricas, portainer.exemplo.com para containers e admin.exemplo.com para área administrativa. Evite expor tudo em paths no mesmo domínio sem necessidade, como /n8n, /grafana e /admin, porque algumas aplicações esperam base URL própria e podem quebrar cookies, callbacks OAuth e websockets. Subdomínios também facilitam políticas diferentes no Cloudflare Access, por exemplo permitir Grafana apenas para o time de infraestrutura e n8n apenas para usuários de automação.

O proxy reverso continua relevante mesmo com Cloudflare Tunnel. Você pode apontar cada hostname diretamente para portas locais, como http://localhost:5678 e http://localhost:3000. Isso é simples e funciona bem. Só que, conforme o ambiente cresce, um Nginx, Caddy ou Traefik local ajuda a padronizar headers, comprimir respostas, aplicar limites, rotear containers por nome e simplificar deploys. Com Docker Compose, por exemplo, o Traefik consegue descobrir serviços por labels e o cloudflared aponta para o Traefik em uma rede interna. Para quem pretende hospedar várias aplicações, vale conectar este desenho com uma estratégia de DNS autoritativo em VPS no Brasil apenas quando houver necessidade real de operar DNS próprio, já que a Cloudflare costuma assumir a zona pública nesse tipo de arquitetura.

Um exemplo de configuração local é usar Caddy escutando somente em 127.0.0.1:8080, com rotas internas para containers. O Tunnel aponta admin.exemplo.com para http://localhost:8080. O Caddy decide se manda para app-admin:3000, grafana:3000 ou uptime-kuma:3001, conforme host ou path. Esse arranjo dá flexibilidade sem abrir portas externas. Só tome cuidado com headers como X-Forwarded-For, X-Forwarded-Proto e logs de IP real. Se a aplicação usa IP do cliente para auditoria, configure a cadeia de proxy corretamente para não registrar apenas o endereço local.

Firewall, hardening e redução de superfície pública

O principal erro ao adotar Cloudflare Tunnel é achar que ele dispensa segurança da VPS. Ele reduz portas públicas, mas não corrige senha fraca, sistema desatualizado, Docker expondo portas por engano ou SSH aberto para o mundo. O firewall deve começar bloqueando tudo que não é necessário. Em muitos cenários, a entrada pública pode ficar limitada ao SSH em porta controlada, ou até bloqueada por VPN, IP allowlist ou Cloudflare Access para SSH quando a equipe domina essa abordagem. Para HTTP e HTTPS, se tudo passa pelo Tunnel, não há motivo para deixar 80 e 443 abertos no firewall da VPS.

Com UFW, um ponto de partida conservador seria permitir SSH apenas do seu IP administrativo e negar o restante. Algo como ufw default deny incoming, ufw default allow outgoing, ufw allow from 203.0.113.10 to any port 22 proto tcp e ufw enable. Substitua o IP de exemplo pelo endereço real da sua rede. Se o IP administrativo muda com frequência, use uma VPN, Tailscale, WireGuard ou uma política operacional clara para não se trancar fora do servidor. Antes de ativar regras agressivas, mantenha uma sessão aberta e teste novo login em outra janela.

Serviços internos devem escutar em 127.0.0.1 ou em uma rede Docker privada. Evite ports: "3000:3000" no Docker Compose quando a aplicação só precisa ser acessada pelo proxy interno. Prefira expose: "3000" entre containers ou bind explícito em 127.0.0.1:3000:3000 quando necessário. Esse detalhe muda bastante o risco: uma aplicação em 0.0.0.0:3000 pode ficar pública se o firewall permitir, enquanto 127.0.0.1:3000 só responde localmente. Para um checklist mais amplo, o guia de firewall e hardening de segurança em VPS complementa este ponto com SSH, fail2ban, atualizações e políticas de acesso.

Hardening também inclui usuário sem root para operação diária, autenticação por chave SSH, PasswordAuthentication no, atualização automática de pacotes de segurança e logs persistentes. Em ambientes com dados sensíveis, ative Cloudflare Access com identidade, MFA e grupos por aplicação. Não publique painel administrativo apenas confiando que a URL é difícil de adivinhar. Uma URL obscura não é controle de acesso. Para aplicações críticas, combine Access, autenticação própria da aplicação, políticas de sessão curtas e revisão periódica de usuários autorizados.

Configuração prática do Cloudflare Tunnel passo a passo

O fluxo básico começa no painel da Cloudflare ou pela CLI. Pela CLI, você instala o cloudflared, autentica a conta, cria um túnel e associa hostnames. Em Debian ou Ubuntu, a instalação pode usar o repositório oficial da Cloudflare ou pacote .deb, conforme a documentação atual. Depois, rode cloudflared tunnel login para autorizar a conta no navegador. Em seguida, crie o túnel com um nome claro, por exemplo cloudflared tunnel create vps-admin-prod. O comando gera um UUID e um arquivo de credenciais. Guarde esse arquivo com permissão restrita, porque ele identifica o túnel.

Uma configuração típica fica em /etc/cloudflared/config.yml. Exemplo simplificado:

tunnel: UUID-DO-TUNEL
credentials-file: /etc/cloudflared/UUID-DO-TUNEL.json

ingress:
  - hostname: admin.exemplo.com
    service: http://localhost:3000
  - hostname: grafana.exemplo.com
    service: http://localhost:3001
  - hostname: n8n.exemplo.com
    service: http://localhost:5678
  - service: http_status:404

Depois, registre os DNS: cloudflared tunnel route dns vps-admin-prod admin.exemplo.com, repetindo para os outros hostnames. Instale como serviço com cloudflared service install ou siga o método indicado para sua distribuição. Confira o status com systemctl status cloudflared e acompanhe os logs com journalctl -u cloudflared -f. Se aparecer erro de conexão com a origem, teste localmente com curl http://localhost:3000 antes de mexer no DNS. Muitas falhas vêm da aplicação fora do ar, porta errada ou container em rede diferente.

Para Docker Compose, há dois caminhos. O primeiro é instalar cloudflared direto no host e apontar para portas locais. O segundo é rodar cloudflared como container na mesma rede das aplicações. Um serviço cloudflared em container pode usar comando tunnel --config /etc/cloudflared/config.yml run, com volume de configuração montado somente leitura. Nesse modelo, você pode apontar service: http://app:3000, usando o nome do container. É limpo, mas exige cuidado com segredos e permissões de volume.

Teste a configuração em camadas. Primeiro, confirme que a aplicação responde localmente. Segundo, confirme que o cloudflared está conectado. Terceiro, confirme que o DNS do hostname resolve para o túnel. Quarto, teste o navegador fora da rede da VPS. Quinto, habilite Cloudflare Access e teste com um usuário permitido e outro bloqueado. Essa sequência economiza horas. Se tudo for feito ao mesmo tempo, qualquer erro vira uma caça confusa entre DNS, firewall, aplicação e autenticação.

Tabela comparativa: modelos de exposição segura

Escolher entre IP público tradicional, proxy reverso e Cloudflare Tunnel depende do risco aceito, do nível de controle necessário e do perfil do time. Não existe um único desenho certo. Uma API pública de alto tráfego pode precisar de 80 e 443 abertos, balanceador, WAF e observabilidade robusta. Um painel interno, por sua vez, ganha muito ao ficar atrás de Tunnel e Access. A tabela abaixo compara modelos comuns em VPS, usando critérios práticos de operação.

Modelo	Portas públicas na VPS	Melhor uso	Recursos recomendados	Cuidados principais
IP público com Nginx ou Caddy	80 e 443 abertas	Sites, APIs públicas, WordPress e aplicações com tráfego aberto	1 a 2 vCPUs, 2 GB de RAM, 40 GB SSD para início	TLS, rate limit, logs, WAF externo, atualização do proxy
Cloudflare Tunnel direto para app local	Nenhuma porta HTTP pública	Painéis internos, homologação, dashboards, n8n e ferramentas administrativas	1 vCPU, 1 a 2 GB de RAM, 20 a 40 GB SSD para apps leves	Access, firewall, serviço systemd, origem em localhost
Tunnel com proxy reverso local	Nenhuma porta HTTP pública	Várias aplicações na mesma VPS, containers e rotas por subdomínio	2 vCPUs, 4 GB de RAM, 40 a 80 GB SSD	Headers, redes Docker, logs por hostname, configuração de origem
VPN ou rede privada sem exposição web	Sem HTTP público	Administração técnica, SSH, bancos internos e manutenção	1 vCPU, 1 GB de RAM para gateway simples	Gestão de chaves, dispositivos autorizados, plano de recuperação

O Tunnel direto é o caminho mais simples quando há uma ou duas aplicações. Por exemplo, um dev solo pode publicar n8n.exemplo.com apontando para localhost:5678 e proteger com Cloudflare Access. Já uma equipe com cinco serviços internos tende a preferir Tunnel com proxy reverso local, porque fica mais fácil padronizar logs, trocar portas sem alterar o túnel e aplicar regras por hostname. Em ambos os casos, a VPS não deve expor banco de dados, Redis, painel Docker ou portas de debug para a internet.

Provedores como LetsCloud, DigitalOcean, Vultr, Linode, AWS Lightsail e Hetzner podem hospedar esse desenho, desde que permitam saída HTTPS estável e ofereçam recursos compatíveis com a aplicação. LetsCloud pode fazer sentido para quem busca presença no Brasil ou operação regional, mas disponibilidade de localidade, tipo de disco, backup, snapshots e condições comerciais devem ser confirmadas no site oficial antes de qualquer recomendação fechada. Como este artigo não é comparativo de preço, dados voláteis ficam marcados para revisão humana.

Operação em produção: logs, atualização, backup e incidentes

Depois que o túnel funciona, começa a parte que separa laboratório de produção. O primeiro ponto é log. O cloudflared deve rodar como serviço e enviar logs para o journald ou para uma solução centralizada, quando houver. Com journalctl -u cloudflared --since "1 hour ago", você consegue verificar reconexões, erros de origem e falhas de autenticação do túnel. Para aplicações web, mantenha logs do proxy ou da aplicação com timestamp, hostname e status HTTP. Um pico de 502 pode indicar aplicação fora do ar, container reiniciando ou rota interna errada.

Atualização também precisa de rotina. Cloudflare publica novas versões do cloudflared, e o sistema operacional recebe correções de segurança. Em uma VPS pequena, um ciclo mensal de manutenção já reduz bastante risco: atualizar pacotes, reiniciar serviços quando necessário, revisar usuários, conferir regras de firewall e testar restauração. Para ambientes mais sensíveis, faça janela quinzenal ou automatize correções críticas com cuidado. Atualizar sem rollback é arriscado. Nunca descubra no incidente que você não sabe recriar o túnel.

Backup da configuração é simples e frequentemente esquecido. Guarde, em local seguro, o config.yml, o identificador do túnel, a lista de hostnames, políticas do Cloudflare Access e arquivos de deploy da aplicação. Não publique credenciais em repositório aberto. Se usar Git privado, proteja secrets com ferramenta própria e controle acesso por grupo. Para VPS com containers, mantenha docker-compose.yml, variáveis de ambiente sem segredos expostos e documentação de portas internas. Um runbook de 20 linhas já ajuda: como verificar o serviço, como reiniciar, como testar origem, como desabilitar um hostname e como subir a aplicação em outra VPS.

Em incidentes, siga uma ordem objetiva. Se o usuário vê erro 502, teste a aplicação localmente com curl. Se local falhar, o problema está na aplicação ou no proxy. Se local funcionar, veja status do cloudflared. Se o túnel estiver conectado, revise DNS e políticas de Access. Se só alguns usuários reclamam, investigue autenticação, grupos, sessão e regras geográficas. Evite sair alterando firewall, DNS e aplicação ao mesmo tempo. Uma mudança por vez facilita voltar atrás.

Recomendações por perfil

Dev solo

Para dev solo, o caminho mais seguro e barato em complexidade é uma VPS pequena com Cloudflare Tunnel direto para uma ou duas aplicações. Use 1 vCPU, 1 GB ou 2 GB de RAM e 20 GB a 40 GB de SSD para painéis leves, homologação, n8n com poucas execuções ou um dashboard pessoal. Instale Ubuntu LTS ou Debian, rode cloudflared via systemd e publique subdomínios separados. Mantenha SSH com chave, firewall bloqueando HTTP público e Cloudflare Access com login por e-mail ou provedor de identidade. Se usar Docker, evite publicar portas sem necessidade. Para estudo, documente cada comando usado, porque essa anotação vira seu plano de recuperação quando a VPS for recriada.

Time pequeno

Um time pequeno precisa de previsibilidade e menos dependência de uma pessoa. A recomendação é usar 2 vCPUs, 4 GB de RAM e 40 GB a 80 GB de SSD, com Tunnel apontando para um proxy reverso local. Separe hostnames por aplicação, por exemplo grafana, metabase, portainer e admin, e aplique políticas diferentes no Cloudflare Access. Use grupos do Google Workspace, Microsoft Entra ID ou outro provedor compatível, em vez de liberar e-mails soltos sem revisão. Registre logs, defina responsáveis por atualização e mantenha um runbook simples. Antes de colocar ferramentas críticas atrás do túnel, teste o que acontece quando o cloudflared reinicia, quando o proxy cai e quando uma política bloqueia um usuário legítimo.

Produção com clientes externos

Para produção com clientes externos, a análise precisa ser mais rigorosa. Cloudflare Tunnel pode proteger áreas administrativas, webhooks privados, dashboards e backoffices, mas uma aplicação pública de cliente talvez precise de arquitetura com balanceamento, cache, WAF, observabilidade e plano de contingência. Comece com 2 a 4 vCPUs, 4 GB a 8 GB de RAM, disco SSD ou NVMe conforme I/O, backups testados e monitoramento externo. Não dependa de uma única VPS para tudo se a aplicação gera receita relevante. Separe banco de dados quando o tráfego crescer, monitore latência, registre auditoria de acesso e revise políticas de identidade. O Tunnel é uma peça boa, mas não deve ser o único controle de segurança nem o único plano de disponibilidade.