Por que ninguém fora da sua rede consegue acessar o localhost

Um provedor de webhook precisa de uma URL para enviar um POST, e seu servidor está em localhost:3000. Ou um colega quer testar a branch que você está rodando, ou seu celular precisa acessar o servidor de desenvolvimento para conferir um layout. O servidor está no ar. Nada fora da sua rede consegue alcançá-lo.

Port forwarding no roteador resolveria, mas expõe o IP da sua casa e exige acesso de administrador que você nem sempre tem. O Cloudflare Tunnel segue outro caminho. O cloudflared, um daemon pequeno que roda ao lado do seu servidor, abre uma conexão de saída até a borda da Cloudflare, e a Cloudflare manda o tráfego de volta por ela. Você não abre nenhuma porta de entrada e não precisa de IP público.

Ele vem em dois formatos. Um quick tunnel te dá uma URL HTTPS pública em um único comando, com um hostname aleatório que morre quando você encerra o processo. É a ferramenta certa para uma demo de cinco minutos ou um teste de webhook. Um named tunnel te dá um hostname estável no seu próprio domínio, que sobrevive a reinicializações — o que o torna uma peça pequena de infraestrutura de verdade.

Como o Cloudflare Tunnel funciona sem abrir uma porta

O truque é uma inversão de direção. Expor um serviço normalmente significa abrir uma porta de entrada: algo na internet inicia uma conexão com sua máquina, então sua máquina precisa de um endereço roteável e de uma regra de firewall que deixe esse tráfego passar. Bloquear exatamente isso é para o que servem o NAT e a maioria dos firewalls domésticos e corporativos.

O cloudflared nunca escuta conexões de entrada. Ele disca para a borda da Cloudflare por HTTPS de saída comum, o mesmo tipo de conexão que seu navegador abre o dia inteiro, e mantém essa conexão aberta. A Cloudflare então empurra as requisições por essa conexão e lê as respostas de volta, de forma parecida com um servidor que envia mensagens por um WebSocket a um navegador que se conectou primeiro. Seu firewall vê uma única conexão de saída que já é permitida. É por isso também que o tunnel se comporta do mesmo jeito atrás de NAT ou em um notebook sem IP público: uma conexão de saída não liga para isso.

O custo é que a Cloudflare passa a ficar no meio do caminho. O hostname do seu tunnel resolve para a Cloudflare, que descriptografa cada requisição na borda, depois a criptografa de novo e a envia pelo tunnel até o seu daemon. É a mesma arquitetura de rodar atrás de um CDN ou de um reverse proxy: você abre mão do acesso direto em troca de um intermediário que termina o TLS e pode aplicar regras de acesso antes que qualquer coisa chegue à sua máquina.

Como criar um quick tunnel com um único comando

Instale o cloudflared primeiro: brew install cloudflared no macOS, o pacote .deb/.rpm do repositório da Cloudflare no Linux, ou o instalador do Windows na página de releases do GitHub. Depois, com algo já escutando em uma porta local:

1

cloudflared tunnel --url http://localhost:3000

Poucos segundos depois você recebe uma saída parecida com esta:

1
2
3
4
5

2026-09-23T10:14:02Z INF Thank you for trying Cloudflare Tunnel. Doing so...
2026-09-23T10:14:03Z INF +--------------------------------------------------------------------------------------------+
2026-09-23T10:14:03Z INF |  Your quick Tunnel has been created! Visit it at (it may take some time to be reachable):  |
2026-09-23T10:14:03Z INF |  https://wise-juvenile-pink-recovered.trycloudflare.com                                   |
2026-09-23T10:14:03Z INF +--------------------------------------------------------------------------------------------+

Essa URL serve HTTPS com um certificado gerenciado pela Cloudflare, então você nunca mexe em configuração de TLS. Dê alguns segundos para ela começar a resolver. A partir daí, qualquer um com o link acessa seu localhost:3000 até você apertar Ctrl-C. O hostname então desaparece de vez, e a próxima execução gera um novo. Você não faz login, não cria registro de DNS, não precisa de conta.

Os limites são reais, porém. O hostname é aleatório, então você não consegue colocá-lo em uma configuração de webhook que precise sobreviver a um reinício. A Cloudflare limita quick tunnels a 200 requisições concorrentes e não suporta Server-Sent Events neles, então um stream SSE de longa duração vai cair. Também não há garantia de uptime: os termos da Cloudflare tratam quick tunnels como uma conveniência para testes.

Para depurar um webhook agora ou deixar seu celular acessar o servidor de dev, é tudo que você precisa. Se ele tiver que continuar rodando amanhã, configure um named tunnel.

Como configurar um named tunnel no seu próprio domínio

Um named tunnel precisa de uma conta Cloudflare gratuita e de um domínio cujo DNS esteja na Cloudflare. Você faz essa configuração uma vez.

1. Autentique o cloudflared na sua conta:

1

cloudflared tunnel login

Isso abre um navegador e pede que você escolha o domínio a autorizar. Depois salva um certificado em ~/.cloudflared/cert.pem, que todo comando seguinte usa.

2. Crie o tunnel e anote o ID dele:

1

cloudflared tunnel create my-app

Isso registra um tunnel chamado my-app e escreve um arquivo de credenciais, <TUNNEL-ID>.json, em ~/.cloudflared/. Esse arquivo é a identidade do tunnel. Trate-o como um secret: quem tiver esse arquivo consegue rodar tráfego pelo seu tunnel.

3. Escreva a configuração. Crie ~/.cloudflared/config.yml:

1
2
3
4
5
6
7
8
9

tunnel: my-app
credentials-file: /home/you/.cloudflared/<TUNNEL-ID>.json

ingress:
  - hostname: app.example.com
    service: http://localhost:3000
  - hostname: api.example.com
    service: http://localhost:8080
  - service: http_status:404

ingress é uma lista ordenada de regras hostname-para-serviço, avaliada de cima para baixo. Se você já configurou o nginx como reverse proxy na frente das suas aplicações, é a mesma ideia de roteamento escrita em YAML em vez de diretivas proxy_pass. Um único tunnel pode atender vários serviços locais em hostnames diferentes. A última regra é obrigatória. É o catch-all que devolve 404 para qualquer hostname que as regras acima não bateram, e o cloudflared se recusa a iniciar sem ela.

4. Aponte o DNS para o tunnel:

1

cloudflared tunnel route dns my-app app.example.com

Isso cria um registro CNAME para app.example.com apontando para <TUNNEL-ID>.cfargotunnel.com. É resolução de DNS comum, só que mirando na infraestrutura de tunnel da Cloudflare em vez de um IP de servidor. Rode esse comando uma vez para cada hostname da sua lista de ingress.

5. Rode:

1

cloudflared tunnel run my-app

app.example.com agora serve o que estiver escutando em localhost:3000, via HTTPS. A Cloudflare termina o TLS na borda, e sua origem pode continuar em HTTP puro porque a conexão do tunnel já é criptografada.

Um tunnel rodando em um terminal morre junto com o terminal. Para que ele sobreviva a um reboot, instale-o como serviço do sistema:

1

sudo cloudflared service install

No Linux, ao rodar com sudo, o $HOME vira /root, e o cloudflared deixa de encontrar o config.yml que você criou como seu próprio usuário. Aponte para o arquivo explicitamente:

1

sudo cloudflared --config /home/you/.cloudflared/config.yml service install

Isso copia sua configuração para /etc/cloudflared/config.yml e registra o cloudflared no systemd (ou no launchd, ou no gerenciador de serviços do Windows), de modo que ele inicia no boot e reinicia se travar.

Quando o Cloudflare Tunnel é a escolha errada

Um tunnel faz sentido quando o tráfego começa fora da sua rede e precisa alcançar uma máquina sem IP público, ou uma que você não quer expor diretamente: um notebook, um servidor doméstico, uma máquina atrás de NAT corporativo. É a ferramenta errada nestes casos:

  • Você já tem um servidor com IP público. O tunnel adiciona a borda da Cloudflare como um salto extra sem ganho nenhum. Um registro A de DNS mais seu próprio reverse proxy ou terminação de TLS é mais simples e tem uma peça a menos para falhar.
  • Você precisa de latência baixa garantida ou movimenta grandes volumes de dados. Todo byte passa pela rede da Cloudflare. Para a maior parte do tráfego web esse custo é desprezível; para cargas de alto throughput ou sensíveis a latência, não é.
  • Você precisa que o serviço continue no ar quando uma máquina cai. Um único cloudflared em uma única máquina é um ponto único de falha, e o service install só cobre reinícios do processo. Se esse host morre, o hostname fica no escuro. Redundância significa rodar o mesmo tunnel a partir de uma segunda máquina.
  • Seu código confia no endereço TCP de origem para decisões de segurança. As requisições chegam à sua origem a partir das faixas de IP da Cloudflare. O IP real do cliente vem no header CF-Connecting-IP, e qualquer coisa que leia o endereço do socket vai ver a borda da Cloudflare em vez dele.

Quick tunnel ou named tunnel: por onde começar

Se você não tem certeza de qual precisa, você precisa de um quick tunnel. Rode cloudflared tunnel --url http://localhost:<porta> contra o que estiver trabalhando agora e abra a URL. Migre para um named tunnel quando esbarrar em um dos dois limites reais dele: um hostname que precisa sobreviver à sessão do terminal, ou um serviço que precisa continuar rodando sem supervisão.

Artigos relacionados