Ing. Calogero Bono
A Cloudflare tornou geralmente disponível o suporte a origens privadas, lançado em beta fechada em junho. Um registro DNS com proxy agora pode apontar para um IP privado, e o tráfego chega ao servidor pela conexão Cloudflare One que você já tem. Para quem gerencia APIs internas, backends de agentes de IA ou ferramentas operacionais, isso significa aplicar WAF, cache e bot management sem expor o servidor na Internet. Ainda falta entender quais requisitos realmente são necessários.
Alguns termos, antes de entrar nos fatos. Origem é o servidor que hospeda a aplicação, por trás da Cloudflare. WAF é o firewall de aplicação que filtra requisições maliciosas. Cloudflare One é a plataforma de conectividade privada da empresa, com túneis e redes. RFC 1918 define os endereços IPv4 privados, como 10.0.0.50. CGNAT indica os endereços compartilhados do bloco 100.64.0.0/10, usados pelas operadoras.
O que a Cloudflare lançou?
Segundo o blog oficial da Cloudflare, durante a beta fechada o acesso era restrito a clientes elegíveis, que o solicitavam ao próprio account team. Agora o acesso se amplia para além desse grupo.
Você aponta um registro A ou AAAA com proxy para um IP privado, e as ferramentas de aplicação funcionam como para origens públicas.
- WAF e regras gerenciadas
- Bot management
- Rate limiting
- Caching
- Regras de transformação e reescrita
- Workers
Que problema isso resolve?
A Cloudflare conta que ouviu muitas vezes o mesmo problema. APIs internas, backends de agentes de IA, servidores MCP e ferramentas operacionais não foram feitos para ficar na Internet, mas precisam aceitar requisições de parceiros, clientes ou agentes.
Antes, colocar a Cloudflare na frente desses serviços exigia um IP público, uma porta aberta no firewall ou o cloudflared ao lado do servidor. Muitas vezes as aplicações privadas ficavam sem as mesmas proteções das públicas.
Quem trabalha com redes privadas pode se aprofundar no nosso guia sobre sub-redes privadas e security groups na AWS.
Como funciona o roteamento privado?
Você cria um registro com proxy apontando para a origem. Para os intervalos privados suportados, a opção de roteamento privado se ativa sozinha. Se a origem tem um IP público acessível somente pela rede privada, é preciso ativá-la manualmente.
A configuração é automática para os endereços RFC 1918, para o bloco CGNAT RFC 6598 e para os IPv6 locais RFC 4193. Para esses intervalos ela não pode ser desativada, e a tentativa via API retorna erro.
Via API basta o atributo private_routing no registro DNS. Quando o proxy o identifica, encaminha a requisição para a camada de rede privada, que usa a conectividade existente, entre IPsec, GRE, Cloudflare Tunnel, CNI ou Cloudflare Mesh. Com a Cloudflare WAN não é necessário nenhum conector na origem. Com o Mesh, um conector na rede pode atender várias origens.
O que é preciso para ativar?
São necessários alguns requisitos indicados pela Cloudflare.
- A autorização Private Origins na conta, que deve ser solicitada ao account team.
- Conectividade Cloudflare One com IPsec, GRE, CNI, Tunnel ou Mesh.
- Unified Routing ativo, exceto com o Tunnel.
- Com WAN ou Mesh, uma rota de retorno para os intervalos de origem da Cloudflare, 100.64.0.0/12 para IPv4 e 2606:4700 – cf1:5000 – – /64 para IPv6.
A Cloudflare alerta que a rota de retorno ausente foi o erro de configuração mais frequente. Se as requisições dão timeout e nada chega ao servidor, verifique essa rota primeiro.
Limites a conhecer
Ainda há limitações. O Argo Smart Routing e os IPs de saída dedicados da CDN não são suportados, e as verificações de saúde da origem exigem o Load Balancing. A lista completa está na documentação para desenvolvedores. Não há preços nem verificações independentes divulgados, e a ativação passa pelo account team. O tráfego entre redes privadas ainda está em desenvolvimento.
O que muda para quem trabalha com o digital
Quem expõe APIs para parceiros ou agentes de IA pode manter o servidor sem IP público e sem portas abertas, reduzindo a superfície de ataque. Um servidor com regras de acesso claras ainda precisa ser configurado com atenção no nível de rede Linux. As regras de WAF, o cache e o bot management já em uso se aplicam ao nome de host sem outras intervenções. Para as pequenas empresas a barreira é comercial, pois é preciso ter uma infraestrutura Cloudflare One e falar com o comercial.
Nossa opinião
O passo é útil, porque leva as proteções públicas para onde antes se abria mão delas por comodidade. Mas o custo oculto é a dependência. Para proteger um serviço privado, você amarra rede, DNS e filtros a um único fornecedor, com requisitos que passam pelo account team. Para empresas que já usam a Cloudflare One faz sentido; para as demais, vale comparar soluções mais simples antes de se comprometer.
Perguntas frequentes
O que são as origens privadas da Cloudflare?
São servidores com IP privado, acessados pela Cloudflare através da sua conexão Cloudflare One. Continuam sem exposição na Internet. WAF, cache, bot management e Workers funcionam como em uma origem pública.
Precisa abrir uma porta no firewall?
Não. Segundo a Cloudflare, a origem mantém o IP privado e não é necessária nenhuma exceção de entrada no firewall. Com a Cloudflare WAN nem sequer é preciso um conector no servidor.
Quais conexões são suportadas?
A Cloudflare indica IPsec, GRE, CNI, Cloudflare Tunnel e Cloudflare Mesh. O Unified Routing funciona em todas, exceto com o Tunnel.
Por que as requisições dão timeout?
Quase sempre falta a rota de retorno. A Cloudflare diz que foi o erro mais comum durante a beta. Com WAN ou Mesh, configure as rotas para 100.64.0.0/12 e 2606:4700 – cf1:5000 – – /64.
Funciona também entre redes privadas?
Ainda não. A versão atual cobre o tráfego público para origens privadas. A Cloudflare pretende uma beta fechada para o tráfego entre redes privadas no início de 2027.
A passagem para o tráfego entre redes privadas, prevista para 2027
O próximo passo anunciado pela Cloudflare é levar WAF e rate limiting também entre redes privadas. Por enquanto é uma ambição, com beta fechada prevista para os primeiros meses de 2027.
- Leia na documentação a lista atualizada das limitações antes de planejar uma migração.
- Pergunte ao seu account team as condições de acesso ao Private Origins e à futura beta privada.
- Mapeie quais serviços internos realmente precisam receber requisições de fora, para saber onde essa proteção é necessária.
