×
Notícias , , , ,

Cloudflare Private Origins leva WAF e cache a origens privadas

Cloudflare Private Origins leva WAF e cache a origens privadas

Neste artigo

O Cloudflare Private Origins chegou à disponibilidade geral em 30 de outubro de 2026 para encaminhar solicitações de endereços públicos a servidores em redes privadas, com WAF, cache e Workers no caminho. A novidade atende empresas que precisam disponibilizar aplicações e APIs pela Internet sem atribuir um IP público ao servidor de origem, aproveitando a conectividade do Cloudflare One.

Cloudflare Private Origins conecta o domínio à rede privada

O recurso, chamado oficialmente de Application Services for Private Origins, conecta hostnames públicos a origens privadas por HTTP ou HTTPS. A origem é o servidor que responde às solicitações por trás do proxy da Cloudflare.

Segundo o anúncio de disponibilidade geral, essa conexão recebe serviços de aplicação como WAF, regras gerenciadas, gerenciamento de bots, limitação de requisições e cache. Também entram transformações, reescritas e Workers.

O endereço acessado pelo visitante continua público, enquanto o trecho até o servidor utiliza a rede privada. Entre os usos previstos estão APIs internas que precisam atender solicitações externas, backends de agentes de IA, servidores MCP e ferramentas operacionais, conforme o anúncio inicial.

A mudança amplia o aproveitamento das conexões existentes: uma infraestrutura já integrada à rede privada da Cloudflare passa a receber também o processamento de segurança e desempenho dos serviços de aplicação.

Quem recebe o recurso e o que precisa estar habilitado

O anúncio de outubro declara disponibilidade para clientes com conectividade Cloudflare One. A configuração exige Private Origins e Unified Routing habilitados, além de uma conexão por IPsec, GRE, CNI, Cloudflare Tunnel ou Cloudflare Mesh.

Até a publicação desta matéria, havia uma diferença entre o anúncio e a documentação de Private Origins: o guia ainda classificava o recurso como exclusivo de Enterprise e orientava procurar a equipe de conta. Essa descrição antecede a disponibilidade geral e, isoladamente, não define a elegibilidade comercial atual.

Para quem vai implantar, a consequência prática é conferir as habilitações da conta antes de alterar o DNS. No procedimento específico por Cloudflare WAN, o guia de configuração exige uma assinatura WAN ativa e a ativação de Private Origins separada do acesso ao DNS autoritativo.

A disponibilidade específica no Brasil e as condições comerciais brasileiras não estavam confirmadas até a publicação desta matéria. O anúncio de disponibilidade geral também não deve ser usado como confirmação de inclusão automática nos planos Free, Pro ou Business.

Configuração do hostname no painel de DNS

O procedimento oficial de roteamento privado utiliza registros A ou AAAA com proxy ativado. O atributo `private_routing` informa ao proxy que a conexão deve seguir para a camada de rede privada.

Com a conectividade e as habilitações preparadas, a configuração no painel segue estes passos:

  1. Acesse DNS Records no painel da Cloudflare.
  2. Selecione Add record para criar um registro A ou AAAA, ou Edit em um registro existente.
  3. Informe o endereço IP da origem que receberá as solicitações.
  4. Confira Proxy status ativado, identificado pela nuvem laranja.
  5. Ative Use private network routing. Para endereços privados reconhecidos, a opção é habilitada automaticamente; para IPs públicos alcançáveis somente pela infraestrutura privada, a ativação pode ser manual.
  6. Selecione Save para salvar o registro.

Essa configuração usa a rede virtual padrão, sem seleção de uma rede virtual específica. O atributo de roteamento privado não é suportado em tipos de registro diferentes de A e AAAA.

Para automatizar o cadastro, a API aceita criar registros por POST e alterar registros existentes por PATCH com `private_routing: true`. A operação exige a permissão DNS Write, conforme a mesma documentação.

Escolha do conector e preparação da rota de retorno

As opções de conectividade têm diferenças de implantação. O WAN utiliza equipamentos de rede existentes com GRE ou IPsec; o Mesh instala nós Linux; o Tunnel executa `cloudflared` em um servidor da rede privada. A documentação de redes privadas explica essas arquiteturas.

Nas conexões compatíveis com Cloudflare Source IPs, o prefixo IPv4 padrão de saída é `100.64.0.0/12`, configurável. O prefixo IPv6 é `2606:4700:cf1:5000::/64` e não pode ser alterado. A rede de destino precisa devolver as respostas pelo caminho Cloudflare One para manter o tráfego simétrico.

Se houver conflito de endereçamento, o IPv4 pode ser substituído por um único CIDR `/12`, respeitando as restrições de sobreposição da conta. Esses parâmetros estão no guia de Cloudflare Source IPs.

O Tunnel exige atenção no diagnóstico: a rede de destino enxerga o IP do host que executa `cloudflared`, em vez do prefixo Cloudflare Source IPs.

Para WAN, a recomendação oficial é usar dois túneis IPsec anycast com endpoints diferentes e duas rotas estáticas com prioridades distintas, oferecendo failover. Nesse cenário, Automatic return routing deve permanecer desativado, e os testes de saúde usam tipo `reply`, direção `bidirectional` e frequência `mid`.

Origem privada não substitui autenticação

A Cloudflare afirma que a origem mantém seu IP privado, sem exigir uma exceção de entrada no firewall. Com WAN ou Mesh, também dispensa a execução de um conector no próprio servidor de origem; a terminação TLS continua na Cloudflare.

Isso resolve a conectividade até o servidor, mas o controle de quem acessa a aplicação exige uma configuração própria. Na documentação de publicação por Tunnel, o hostname público fica acessível pela Internet, e uma aplicação Access pode restringir a entrada.

Para um painel operacional ou uma API destinada a um grupo específico, essa distinção muda a implantação: manter o servidor em endereço privado não autentica automaticamente as solicitações recebidas pelo domínio público.

Também não há garantia confirmada de processamento ou armazenamento exclusivamente no Brasil pelo uso de Private Origins. Os controles de localização de chaves, logs e processamento HTTPS pertencem à Data Localization Suite, um adicional pago separado para Enterprise.

Validação e correção de falhas de conexão

No cenário WAN, a validação oficial inclui conferir a saúde dos túneis, acessar o hostname HTTPS de fora da rede e verificar se o tráfego chega à origem. O guia também recomenda alertas para acompanhar a saúde das conexões.

A documentação de solução de problemas relaciona os principais sintomas às seguintes verificações:

  • Erro 1002, “DNS points to prohibited IP”: conferir a habilitação de Private Origins com a equipe de conta.
  • Solicitações que não chegam ao servidor: verificar túnel ativo, alcance do IP, proxy habilitado e `private_routing: true`.
  • Timeout sem resposta: conferir a rota de retorno do prefixo Cloudflare Source IPs pelo túnel. No cenário WAN documentado, verificar também a faixa privada `/12` do Source IP.
  • IKE estabelecido com testes de saúde falhando: permitir ICMP entre os endpoints e revisar os valores `bidirectional` e `reply`.
  • Opção aparentemente desativada com tráfego ainda passando pelo túnel: procurar outros registros do mesmo hostname, pois a configuração se aplica ao nome.

O retorno das respostas merece atenção porque o encaminhamento de entrada, sozinho, não completa a comunicação. O caminho simétrico também ajuda firewalls com estado a acompanhar solicitações e respostas.

Limites atuais e alternativas para outros acessos

O lançamento não oferece suporte a Argo Smart Routing nem a Aegis. As verificações de integridade da origem exigem Load Balancing, segundo o anúncio de disponibilidade geral.

Para serviços TCP e UDP, a alternativa relacionada é o Spectrum. Suas origens por rede virtual exigem endereço único, porta única e Proxy Protocol desativado, conforme as opções de configuração.

Outra opção é publicar uma aplicação com Cloudflare Tunnel, associando um hostname público a um serviço local por `cloudflared`, com cache, WAF e proteção DDoS. Já as rotas privadas do Cloudflare One atendem usuários conectados à organização Zero Trust e podem receber políticas Gateway baseadas em identidade e postura do dispositivo.

Private Origins começou em beta fechado para clientes Enterprise elegíveis em 10 de junho de 2026. A chegada geral ocorreu dentro da previsão de lançamento no quarto trimestre.

O próximo cenário anunciado é o tráfego de privado para privado, com beta fechado previsto para o começo de 2027. Trata-se de uma etapa futura; para escolher a configuração atual, a distinção central continua sendo entre publicar um hostname para acessos externos e oferecer acesso privado a usuários conectados à organização.

Fontes

Perguntas frequentes

O servidor precisa ter um IP público?

Não. O endereço público usado pelo visitante é o hostname; o servidor pode continuar em uma rede privada alcançada pela conectividade da Cloudflare.

O recurso aceita endereços IPv6 privados?

Sim. O roteamento aceita registros AAAA e reconhece endereços locais únicos da faixa fc00::/7.

Private Origins substitui o Cloudflare Tunnel?

Não. O Tunnel continua disponível e também aparece entre as formas de conectar a infraestrutura ao novo recurso.

O visitante precisa instalar algum aplicativo?

A publicação por hostname público atende acessos pela Internet. A conexão do dispositivo à organização é uma exigência de outro cenário: o acesso direto às redes privadas pelo Cloudflare One.

O que significa o erro 1002 nessa configuração?

A mensagem “DNS points to prohibited IP” pode indicar que a conta ainda precisa da habilitação de Private Origins. A documentação orienta procurar a equipe de conta.

Serviços TCP e UDP usam a mesma configuração?

Esses protocolos seguem a configuração do Cloudflare Spectrum, que possui exigências próprias para origens em redes virtuais.


Leia também

Tag

Related Posts