{"id":2217,"date":"2026-08-12T16:57:34","date_gmt":"2026-08-12T19:57:34","guid":{"rendered":"https:\/\/jrtx.com.br\/blog\/2026\/08\/12\/cloudflare-access-atualizacao-hostname-routing-e-novo-ip-ran\/"},"modified":"2026-08-12T16:57:34","modified_gmt":"2026-08-12T19:57:34","slug":"cloudflare-access-atualizacao-hostname-routing-e-novo-ip-ran","status":"publish","type":"post","link":"https:\/\/jrtx.com.br\/blog\/2026\/08\/12\/cloudflare-access-atualizacao-hostname-routing-e-novo-ip-ran\/","title":{"rendered":"Cloudflare Access atualiza\u00e7\u00e3o: hostname routing e novo IP range"},"content":{"rendered":"

A Cloudflare Access atualiza\u00e7\u00e3o<\/strong> de agosto de 2026 marca uma virada relevante para times de infraestrutura e seguran\u00e7a que dependem de Zero Trust, especialmente no Brasil, onde o trabalho h\u00edbrido consolidou o acesso remoto a aplica\u00e7\u00f5es privadas como padr\u00e3o corporativo. A Cloudflare<\/strong> opera uma das maiores redes de borda do planeta \u2014 mais de 300 cidades<\/strong> em 100+ pa\u00edses<\/strong>, respondendo por aproximadamente 1 em cada 5 requisi\u00e7\u00f5es HTTP<\/strong> da internet \u2014 e o Access<\/strong>, pe\u00e7a central do portf\u00f3lio Cloudflare One<\/strong>, substitui VPNs legadas com autentica\u00e7\u00e3o por identidade integrada a Okta<\/strong>, Google Workspace<\/strong> e Azure AD<\/strong>. Nesta atualiza\u00e7\u00e3o, tr\u00eas mudan\u00e7as chamam aten\u00e7\u00e3o de administradores: disponibilidade geral do hostname routing<\/strong>, novo intervalo de initial resolved IPs<\/strong> p\u00fablico e impacto direto em navegadores baseados em Chromium 142<\/strong>. Vamos detalhar cada uma delas com foco em configura\u00e7\u00e3o, breaking changes e caminhos de migra\u00e7\u00e3o.<\/p>\n

O contexto de mercado em 2026 refor\u00e7a que CDN e seguran\u00e7a n\u00e3o s\u00e3o mais camadas separadas. A Cloudflare<\/strong> compete diretamente com Akamai<\/strong>, Fastly<\/strong> e AWS CloudFront<\/strong> no delivery de conte\u00fado, mas se diferencia ao entregar SASE<\/strong>, WAF<\/strong>, DDoS<\/strong> e Zero Trust<\/strong> em uma \u00fanica plataforma. Enquanto concorrentes exigem integra\u00e7\u00f5es complexas entre m\u00faltiplos fornecedores, o Cloudflare Access<\/strong> funciona como camada de autoriza\u00e7\u00e3o na borda, aplicando pol\u00edticas antes que o tr\u00e1fego alcance a origem. Para empresas brasileiras que precisam atender \u00e0 LGPD<\/strong> e reduzir lat\u00eancia em aplica\u00e7\u00f5es hospedadas em S\u00e3o Paulo, no exterior ou em nuvens h\u00edbridas, manter o Access atualizado evita falhas silenciosas de conectividade \u2014 exatamente o tipo de problema que a mudan\u00e7a de IP range pode causar se n\u00e3o for tratada a tempo.<\/p>\n

O an\u00fancio vem na esteira de uma onda de lan\u00e7amentos recentes da Cloudflare<\/strong>: o DDoS Threat Report H1 2026<\/strong> apontou aumento de 519%<\/strong> em ataques hiper-volum\u00e9tricos, o WAF<\/strong> recebeu nova detec\u00e7\u00e3o para CVE-2026-61511<\/strong> (vBulletin RCE), a p\u00e1gina de status foi reconstru\u00edda com feeds RSS separados e suporte a Markdown para agentes de IA, e o cliente Cloudflare One Client for Windows<\/strong> ganhou hotfix para reconex\u00e3o ap\u00f3s sleep. Nesse ecossistema em movimento r\u00e1pido, a Cloudflare Access atualiza\u00e7\u00e3o<\/strong> se destaca por tocar diretamente roteamento de DNS, pol\u00edticas de egress e aplica\u00e7\u00f5es privadas em portas n\u00e3o-HTTPS. Neste post, voc\u00ea vai entender o que mudou, como migrar sem downtime e por que a JRT Technology Solutions<\/strong> recomenda revisar sua configura\u00e7\u00e3o agora.<\/p>\n

Antes de avan\u00e7ar, vale refor\u00e7ar o hist\u00f3rico: o Cloudflare Access<\/strong> nasceu como alternativa leve \u00e0 VPN, usando o modelo de identity-aware proxy<\/strong>. Em vez de abrir t\u00faneis amplos na rede, cada requisi\u00e7\u00e3o a um hostname protegido \u00e9 avaliada contra pol\u00edticas de identidade, grupo, dispositivo e localiza\u00e7\u00e3o. A evolu\u00e7\u00e3o para SASE<\/strong> adicionou Gateway<\/strong>, WARP<\/strong>, Mesh<\/strong> e Tunnel<\/strong>, e agora o hostname routing<\/strong> elimina a necessidade de listas est\u00e1ticas de IPs para roteamento. A mudan\u00e7a de initial resolved IPs<\/strong>, por\u00e9m, exige aten\u00e7\u00e3o: contas que ainda usam o intervalo legado CGNAT<\/strong> podem enfrentar bloqueios no Chrome 142+<\/strong>, Edge<\/strong>, Brave<\/strong> e Opera<\/strong>.<\/p>\n

Cloudflare Access atualiza\u00e7\u00e3o: o que mudou em agosto de 2026<\/h3>\n

O changelog oficial da Cloudflare<\/strong> trouxe duas entregas estruturais para o Access<\/strong> e servi\u00e7os correlatos de Cloudflare One<\/strong>. A primeira \u00e9 a disponibilidade geral do hostname routing<\/strong>, que j\u00e1 existia em beta e agora est\u00e1 maduro para produ\u00e7\u00e3o. A segunda \u00e9 a substitui\u00e7\u00e3o do intervalo padr\u00e3o de initial resolved IPs<\/strong> \u2014 tamb\u00e9m chamado de token IPs<\/strong> \u2014 do bloco CGNAT 100.80.0.0\/16<\/strong> para o espa\u00e7o p\u00fablico 172.64.128.0\/20<\/strong> em IPv4, mantendo 2606:4700:0cf1:4000::\/64<\/strong> em IPv6. Essa segunda mudan\u00e7a foi motivada pelas restri\u00e7\u00f5es de Local Network Access (LNA)<\/strong> do Chrome 142<\/strong>, que bloqueiam requisi\u00e7\u00f5es em segundo plano para endere\u00e7os CGNAT<\/strong> no n\u00edvel do motor Chromium<\/strong>.<\/p>\n

Al\u00e9m dessas, o ecossistema recebeu atualiza\u00e7\u00f5es complementares: o Gateway<\/strong> e o Cloudflare Tunnel<\/strong> agora podem rotear por hostname, o Mesh<\/strong> ganhou atra\u00e7\u00e3o de tr\u00e1fego por hostname e o cliente Windows<\/strong> foi corrigido para reconectar ap\u00f3s wake from sleep. Para seguran\u00e7a, o WAF<\/strong> bloqueia ativamente a CVE-2026-61511<\/strong> do vBulletin, e o Email Security<\/strong> passou a aceitar regras de bloqueio por conte\u00fado com express\u00f5es regulares. A nova p\u00e1gina de status, por sua vez, entrega notifica\u00e7\u00f5es independentes da infraestrutura da Cloudflare \u2014 um al\u00edvio para quem monitora incidentes em tempo real.<\/p>\n

A tabela abaixo resume o changelog mais relevante para quem opera Cloudflare Access<\/strong> e Cloudflare One<\/strong> no dia a dia:<\/p>\n\n\n\n\n\n\n\n\n\n
Recurso<\/th>\nAntes<\/th>\nDepois<\/th>\nImpacto<\/th>\n<\/tr>\n<\/thead>\n
Hostname routing para Cloudflare Tunnel<\/td>\nBeta, gerenciamento por listas de IP est\u00e1ticas<\/td>\nGA, roteamento por hostname privado ou p\u00fablico<\/td>\nSimplifica rotas, elimina depend\u00eancia de IP fixo<\/td>\n<\/tr>\n
Initial resolved IPs IPv4 padr\u00e3o<\/td>\n100.80.0.0\/16 (CGNAT)<\/td>\n172.64.128.0\/20 (p\u00fablico Cloudflare)<\/td>\nEvita bloqueio do Chrome 142+ por Local Network Access<\/td>\n<\/tr>\n
Access em portas n\u00e3o-HTTPS<\/td>\nUsava CGNAT para associar DNS e conex\u00e3o<\/td>\nUsa intervalo p\u00fablico Cloudflare<\/td>\nMant\u00e9m compatibilidade com Chromium sem workaround<\/td>\n<\/tr>\n
Egress policy host selectors<\/td>\nSujeito a bloqueios LNA em Chromium<\/td>\nFunciona com novo IP p\u00fablico<\/td>\nSeletores Domain, Host, Application e Content Categories est\u00e1veis<\/td>\n<\/tr>\n
Cloudflare One Client Windows<\/td>\nFalha intermitente ao reconectar ap\u00f3s sleep<\/td>\nHotfix 2026.6.905.0 GA<\/td>\nElimina janela de desconex\u00e3o em notebooks corporativos<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Para administradores que gerenciam pol\u00edticas de Access<\/strong>, a leitura imediata \u00e9 clara: se sua conta ainda depende do intervalo legado 100.80.0.0\/16<\/strong>, usu\u00e1rios em navegadores Chromium<\/strong> recentes podem come\u00e7ar a falhar de forma silenciosa em recursos que dependem dos initial resolved IPs<\/strong>. A boa not\u00edcia \u00e9 que a Cloudflare<\/strong> oferece configura\u00e7\u00e3o via dashboard e API, e a mudan\u00e7a para contas novas j\u00e1 vem ativa por padr\u00e3o. Contas existentes precisam revisar a configura\u00e7\u00e3o em Zero Trust > Team & Resources > Devices > Device profiles<\/strong>.<\/p>\n

Hostname routing GA: o fim das listas est\u00e1ticas de IP<\/h3>\n

O hostname routing<\/strong> \u00e9 a mudan\u00e7a conceitualmente mais importante desta Cloudflare Access atualiza\u00e7\u00e3o<\/strong>. Antes, para rotear tr\u00e1fego entre conectores Cloudflare Tunnel<\/strong>, Mesh<\/strong> ou Gateway<\/strong>, era preciso gerenciar listas est\u00e1ticas de IPs e rotas \u2014 um modelo fr\u00e1gil quando filiais mudam de faixa, ambientes de nuvem escalam dinamicamente ou equipes adotam redes tempor\u00e1rias. Com o recurso em GA, voc\u00ea passa a rotear por hostname<\/strong>, muito mais pr\u00f3ximo do modelo de identidade que o Access<\/strong> j\u00e1 defende.<\/p>\n

Na pr\u00e1tica, um hostname privado como wiki.internal.local<\/strong> pode ser roteado para uma aplica\u00e7\u00e3o privada atr\u00e1s de um t\u00fanel espec\u00edfico, enquanto um hostname p\u00fablico como bank.example.com<\/strong> pode egressar por um t\u00fanel dedicado e ancorar tr\u00e1fego em um n\u00f3 de sa\u00edda controlado. Isso elimina a necessidade de atualizar roteadores e firewalls sempre que um IP muda, e permite pol\u00edticas de egress mais granulares \u2014 por exemplo, for\u00e7ar que o tr\u00e1fego de um dom\u00ednio sens\u00edvel saia por um conector em determinada regi\u00e3o para cumprir requisitos de resid\u00eancia de dados.<\/p>\n

Para o Access<\/strong> especificamente, o hostname routing fortalece o cen\u00e1rio de aplica\u00e7\u00f5es privadas em portas n\u00e3o-HTTPS<\/strong>, como SSH, RDP, bancos de dados e aplica\u00e7\u00f5es legadas que n\u00e3o falam TLS na porta 443. Nesses casos, a Cloudflare<\/strong> precisa associar a consulta DNS ao fluxo de conex\u00e3o subsequente, e os initial resolved IPs<\/strong> s\u00e3o o mecanismo que faz essa m\u00e1gica. Com o novo intervalo p\u00fablico, essa associa\u00e7\u00e3o permanece est\u00e1vel mesmo diante das restri\u00e7\u00f5es do Chrome 142<\/strong>.<\/p>\n

Vale notar que o hostname routing<\/strong> tamb\u00e9m se aplica ao Cloudflare Mesh<\/strong>, que interconecta data centers privados usando a espinha dorsal da Cloudflare. Empresas que operam ambientes h\u00edbridos \u2014 por exemplo, matriz em S\u00e3o Paulo e filiais no interior com links MPLS ou BGP via Network Interconnect<\/strong> \u2014 podem atrair tr\u00e1fego de hostnames privados para um n\u00f3 Mesh sem depender de propaga\u00e7\u00e3o de rotas IP complexas. Para times de rede, isso reduz drasticamente o n\u00famero de regras manuais e o risco de loops de roteamento.<\/p>\n

Novo IP range p\u00fablico: entenda o breaking change do Chrome 142<\/h3>\n

A mudan\u00e7a de initial resolved IPs<\/strong> de 100.80.0.0\/16<\/strong> para 172.64.128.0\/20<\/strong> n\u00e3o \u00e9 cosm\u00e9tica \u2014 \u00e9 uma corre\u00e7\u00e3o preventiva contra o Local Network Access (LNA)<\/strong> implementado no Chrome 142<\/strong> e herdado por todos os navegadores baseados em Chromium<\/strong>, incluindo Microsoft Edge<\/strong>, Brave<\/strong> e Opera<\/strong>. O LNA bloqueia requisi\u00e7\u00f5es em segundo plano para endere\u00e7os CGNAT<\/strong> (100.64.0.0\/10), o que antes quebrava silenciosamente recursos baseados em hostname do Access<\/strong>, Gateway<\/strong> e Mesh<\/strong>.<\/p>\n

O mecanismo funciona assim: quando um usu\u00e1rio resolve um hostname atrav\u00e9s do WARP<\/strong> ou de um t\u00fanel, a Cloudflare retorna um initial resolved IP<\/strong> tempor\u00e1rio que pertence \u00e0 sua faixa. Esse IP \u00e9 usado apenas para associar a consulta DNS \u00e0 conex\u00e3o de rede que vem em seguida, permitindo que pol\u00edticas de egress, host selectors e aplica\u00e7\u00f5es privadas em portas alternativas funcionem corretamente. Se o navegador bloqueia esse IP por consider\u00e1-lo rede local, toda a cadeia de autoriza\u00e7\u00e3o \u00e9 comprometida.<\/p>\n

Com o novo intervalo p\u00fablico 172.64.128.0\/20<\/strong>, o problema desaparece, pois o endere\u00e7o n\u00e3o pertence mais ao espa\u00e7o CGNAT<\/strong> bloqueado. O intervalo IPv6 2606:4700:0cf1:4000::\/64<\/strong> permanece o mesmo, pois n\u00e3o \u00e9 afetado pela restri\u00e7\u00e3o do Chromium<\/strong>. Contas podem configurar um intervalo IPv4 customizado caso o padr\u00e3o entre em conflito com a rede existente \u2014 \u00fatil para empresas que j\u00e1 usam 172.64.0.0\/16<\/strong> internamente em cen\u00e1rios de SD-WAN ou VPN legada.<\/p>\n

Se voc\u00ea vinha usando a pol\u00edtica empresarial LocalNetworkAccessRestrictionsTemporaryOptOut<\/strong> do Chrome como workaround, a recomenda\u00e7\u00e3o oficial \u00e9 abandon\u00e1-la assim que migrar para o novo intervalo. Esse workaround, embora eficaz temporariamente, enfraquece a postura de seguran\u00e7a ao liberar acesso a redes locais para contextos que deveriam ser restritos. A migra\u00e7\u00e3o para o intervalo p\u00fablico permite remover a exce\u00e7\u00e3o e voltar a aplicar o LNA de forma integral, alinhando seguran\u00e7a e compatibilidade.<\/p>\n

Impacto pr\u00e1tico da Cloudflare Access atualiza\u00e7\u00e3o para administradores<\/h3>\n

Para administradores de Zero Trust<\/strong>, a Cloudflare Access atualiza\u00e7\u00e3o<\/strong> exige uma revis\u00e3o proativa de tr\u00eas frentes: rotas por hostname<\/strong>, intervalo de initial resolved IPs<\/strong> e pol\u00edticas de egress com host selectors<\/strong>. O primeiro passo \u00e9 identificar se sua conta ainda usa o intervalo legado CGNAT<\/strong>. Voc\u00ea pode fazer isso no dashboard em Zero Trust > Team & Resources > Devices > Device profiles<\/strong> ou usando a API Initial Resolved IP Subnet<\/strong>. Contas criadas recentemente j\u00e1 devem estar no intervalo p\u00fablico, mas ambientes antigos podem estar no legado.<\/p>\n

O segundo passo \u00e9 mapear quais aplica\u00e7\u00f5es privadas usam portas n\u00e3o-HTTPS. Servi\u00e7os como SSH<\/strong> na porta 22, RDP<\/strong> na 3389, MySQL<\/strong> na 3306 ou PostgreSQL<\/strong> na 5432 dependem fortemente dos initial resolved IPs<\/strong> para funcionar atrav\u00e9s do Access<\/strong>. Se esses servi\u00e7os come\u00e7arem a falhar apenas em navegadores Chromium<\/strong> atualizados, o sintoma cl\u00e1ssico \u00e9 o usu\u00e1rio conseguir resolver o hostname, mas a conex\u00e3o ser bloqueada ou cair silenciosamente. Testar com curl<\/strong> ou com o cliente WARP<\/strong> pode ajudar a isolar o problema.<\/p>\n

O terceiro passo \u00e9 revisar as pol\u00edticas de egress que usam seletores Domain<\/strong>, Host<\/strong>, Application<\/strong> ou Content Categories<\/strong>. Essas pol\u00edticas dependem da associa\u00e7\u00e3o DNS-conex\u00e3o e, portanto, tamb\u00e9m s\u00e3o afetadas pelo intervalo antigo. Ap\u00f3s migrar, \u00e9 importante validar que relat\u00f3rios do Gateway<\/strong> continuam classificando corretamente o tr\u00e1fego e que regras de bloqueio baseadas em hostname voltam a funcionar como esperado. Em ambientes com muitas filiais, a valida\u00e7\u00e3o pode ser automatizada com scripts que comparam o tr\u00e1fego antes e depois da mudan\u00e7a.<\/p>\n

A seguir, uma lista de verifica\u00e7\u00e3o recomendada pela JRT Technology Solutions<\/strong> para minimizar o impacto operacional:<\/p>\n