Oculte o IP de origem do VPS com Cloudflare Tunnel (2026): Zero Trust, sem abrir portas e guia de implantação de penetração de rede interna

O Cloudflare Tunnel é mais adequado para estas necessidades:

Em uma frase: se o seu serviço é essencialmente HTTP/HTTPS e você quer ocultar o IP de origem, o Tunnel vale muito a pena.

Mas não é uma solução mágica. O Tunnel não corrige vulnerabilidades da aplicação por você, nem substitui backups, logs e controle de acesso. Ele resolve os problemas de "superfície de exposição da entrada" e "origem que contorna a Cloudflare".

A abordagem tradicional é:

用户 -> Cloudflare -> VPS 公网 IP:443 -> Nginx -> 应用

A abordagem com Tunnel é:

用户 -> Cloudflare Edge -> cloudflared 隧道 -> 127.0.0.1:3000

A diferença principal é que o cloudflared se conecta ativamente de dentro do VPS para fora, então o firewall do VPS pode fechar a entrada 80/443 e manter apenas o SSH, ou até ser gerenciado somente por console/VPN.

A documentação oficial da Cloudflare também afirma claramente que o Tunnel usa um modelo de conexão somente de saída: o cloudflared se conecta ativamente da origem à rede global da Cloudflare, e o tráfego é encaminhado bidirecionalmente por essa conexão.

Isso é muito valioso para um VPS:

• O IP de origem não precisa ser exposto diretamente aos usuários;
• Serviços internos sem IP público também podem ser publicados;
• A entrada do painel administrativo pode ficar atrás do Cloudflare Access;
• A política de firewall é mais simples: negar entrada por padrão e permitir apenas as portas de gerenciamento necessárias.

Você precisa de:

1. Um domínio já conectado à Cloudflare;
2. Um VPS com acesso à internet de saída;
3. Um serviço em execução local, por exemplo 127.0.0.1:3000;
4. Acesso ao painel do Cloudflare Zero Trust.

Primeiro confirme que o serviço local está acessível:

curl -I http://127.0.0.1:3000

Se você não consegue acessar nem localmente, não configure o Tunnel ainda. O Tunnel não é uma ferramenta de reparo de aplicações; ele apenas encaminha tráfego.

Acesse o Cloudflare Zero Trust:

Zero Trust -> Networks -> Connectors -> Cloudflare Tunnels -> Create a tunnel

Selecione Cloudflared e dê um nome ao túnel, por exemplo:

vps-main-tunnel

A Cloudflare fornecerá um comando de instalação. No Debian/Ubuntu ele tem mais ou menos este formato:

curl -L --output cloudflared.deb https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb
sudo dpkg -i cloudflared.deb
sudo cloudflared service install <你的-token>

Após a instalação, volte ao painel. Se o conector mostrar Healthy, o VPS estabeleceu conexão com a Cloudflare.

Em Public Hostname ou Published applications do Tunnel, adicione:

Subdomain: app
Domain: example.com
Type: HTTP
URL: http://localhost:3000

Após salvar, acesse:

https://app.example.com

Se o serviço estiver funcionando, as requisições chegarão à porta 3000 local do VPS pelo Cloudflare Tunnel.

Nesse momento sua aplicação pode escutar apenas em localhost:

HOST=127.0.0.1 PORT=3000 npm start

O Nginx também não precisa ser a entrada pública; pode ser apenas uma camada de proxy reverso local:

server {
    listen 127.0.0.1:8080;
    server_name _;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Depois aponte o Tunnel para:

http://localhost:8080

O método de instalação pelo painel normalmente registra um serviço systemd automaticamente. Verifique o status:

systemctl status cloudflared
journalctl -u cloudflared -n 100 --no-pager

Comandos comuns:

systemctl restart cloudflared
systemctl enable cloudflared

Se você reinstalar o sistema mais tarde, lembre-se de reinstalar o conector. O objeto Tunnel fica no painel da Cloudflare; o cloudflared no VPS é apenas o conector.

Após usar o Tunnel, as portas públicas de entrada podem ser restringidas bastante.

Se o seu site é publicado inteiramente pelo Tunnel, você pode fazer assim:

ufw default deny incoming
ufw default allow outgoing
ufw allow OpenSSH
ufw enable

Se quiser proteger ainda mais o SSH, pode permitir apenas o seu próprio IP:

ufw allow from 你的固定IP to any port 22 proto tcp

Mas não feche o SSH de qualquer jeito antes de ter preparado console/VNC/modo de resgate. Já existem artigos relacionados de autorresgate:

• O que fazer se o SSH não conectar após ativar o UFW no VPS
• O que fazer se o SSH do VPS fica desconectando

O ponto forte do Tunnel não é apenas ocultar a origem; ele também pode ser combinado com o Cloudflare Access.

Por exemplo, se você tem estes painéis:

• n8n.example.com
• gitea.example.com
• grafana.example.com
• admin.example.com

Você pode criar uma Access Application no Zero Trust exigindo que os visitantes passem por uma das seguintes opções antes de acessar:

• OTP por e-mail;
• Login com Google / GitHub;
• E-mail da equipe especificado;
• Política de país/região ou IP especificada;
• Autenticação multifator.

Assim, mesmo que a página de login da própria aplicação administrativa esteja exposta, há uma camada extra de verificação de identidade da Cloudflare por fora.

Políticas recomendadas:

Primeiro verifique o serviço:

systemctl status cloudflared
journalctl -u cloudflared -n 100 --no-pager

Depois confirme que o VPS consegue acessar a Cloudflare:

curl -I https://www.cloudflare.com

Se o servidor estiver atrás de um firewall rígido, confirme que as conexões de saída não estão bloqueadas. A documentação da Cloudflare lembra que, em redes restritas, é preciso fazer primeiro uma verificação prévia de conectividade, especialmente para confirmar a acessibilidade à Cloudflare.

Causas comuns:

• Token copiado incorretamente;
• Serviço systemd não iniciado;
• Saída do VPS bloqueada pelo firewall;
• DNS ou hora do sistema anormais;
• Versão do cloudflared muito antiga.

O Tunnel já está Healthy, mas acessar o domínio retorna erro; normalmente o endereço do serviço local está errado.

Teste no VPS:

curl -I http://localhost:3000
curl -I http://127.0.0.1:3000

Observe que localhost pode resolver para IPv6 ::1, enquanto sua aplicação escuta apenas em IPv4. Nesse caso, no Public Hostname você pode escrever explicitamente:

http://127.0.0.1:3000

Se sua aplicação exigir o cabeçalho Host, talvez também seja necessário ajustar o HTTP Host Header nas configurações de origin request do Tunnel.

Ter o Tunnel configurado não garante que a origem esteja oculta. Você também precisa confirmar:

1. Que não há registros A de nuvem cinza no DNS expondo o IP real;
2. Que o firewall do VPS não abre mais 80/443;
3. Que registros DNS históricos, logs de transparência de certificados e cabeçalhos de e-mail não vazam a origem;
4. Que a antiga entrada do Nginx não escuta mais publicamente.

Teste o acesso direto à origem:

curl -I http://你的VPS_IP
curl -kI https://你的VPS_IP

Se ainda for possível acessar o site, significa que a origem ainda não foi realmente fechada.

A nuvem laranja comum já resolve muitos problemas de CDN/WAF/cache; o Tunnel é mais adequado para cenários em que você quer reduzir ainda mais a superfície de exposição do VPS ou não tem condições de entrada pública.

Antes de publicar um serviço, verifique pelo menos:

• O serviço local curl http://127.0.0.1:端口 está normal;
• O conector do Cloudflare Tunnel mostra Healthy;
• O Public Hostname aponta para a porta local correta;
• O UFW não bloqueou o SSH;
• A porta pública 80/443 do VPS está fechada ou não retorna mais páginas de negócio;
• O domínio do painel administrativo tem Cloudflare Access adicionado;
• Os caminhos de Webhook não estão sendo bloqueados por engano pelo Access;
• O journalctl -u cloudflared não tem erros persistentes;
• Foram testados o acesso por domínio, o IP direto e a rede móvel.

É preciso ter cautela nestes casos:

• Você precisa de controle total sobre os detalhes de TLS do Nginx e a cadeia de certificados;
• O negócio tem muitos downloads de arquivos grandes ou protocolos especiais;
• Você não quer que a entrada dependa fortemente da Cloudflare;
• Sua rede tem conexões de saída instáveis para a Cloudflare;
• Você precisa de protocolos não HTTP, mas não quer introduzir clientes adicionais nem configuração de Zero Trust.

Se for apenas um site comum, painel administrativo, ferramenta auto-hospedada ou painel interno, os benefícios do Tunnel normalmente superam a complexidade.

O Cloudflare Tunnel é muito adequado para usuários de VPS fazerem três coisas: ocultar o IP de origem, reduzir as portas públicas de entrada e adicionar uma camada de controle de acesso Zero Trust aos serviços administrativos.

O núcleo não é "deixar o site mais rápido", mas sim "expor menos a origem". Se você já está na Cloudflare e se preocupa com a origem sendo acessada diretamente, o painel sendo escaneado ou a banda larga residencial/NAT não conseguir abrir portas, então o Tunnel é uma solução que vale muito a pena dominar.

A forma realmente segura é: publicar serviços com o Tunnel, fechar no firewall as entradas desnecessárias, proteger o painel com Access e observar os logs continuamente. Assim o VPS não fica exposto sozinho na internet pública, mas colocado atrás da rede de borda da Cloudflare com acesso controlado.