89,6% dos sites europeus usam CDN — Cloudflare: quais os riscos da monocultura de filtros

Em 7 de setembro de 2026, pesquisadores da CipherCue publicaram uma medição que todos que navegam na web europeia de forma automatizada devem ler: de 44.143 empresas europeias, das quais foi possível detectar CDN, 89,6% estão atrás do Cloudflare. Não é um "líder de mercado com grande vantagem" — é quase todo o mercado como um todo. Para scraping, multi-contas e qualquer automação, isso significa uma coisa simples: o acesso a nove sites em cada dez na UE é decidido pelo mesmo algoritmo, com os mesmos critérios, no mesmo segundo.

O que exatamente foi contado

A amostra consiste em empresas da Alemanha, Reino Unido, Países Baixos, Polônia, França, Itália, Espanha e Irlanda, que tinham pelo menos um componente CDN identificado em seus sites. A detecção foi feita através das respostas HTTP e impressões do servidor: o cabeçalho cf-ray e server: cloudflare para Cloudflare, x-served-by com marcador de cache para Fastly, x-amz-cf-id para CloudFront. A data da observação é 7 de setembro de 2026.

A distribuição por provedores é a seguinte:

• Cloudflare — 39.547 empresas (89,6%)
• Amazon CloudFront — 3.112
• Fastly — 1.299
• Akamai — 396

Por países, a variação é notável, mas o teto é alto em todos os lugares:

• Países Baixos — 95,6% (7.587 de 7.939)
• Reino Unido — 93,2% (15.846 de 17.007)
• Polônia — 92,6% (2.682 de 2.896)
• França — 86,2% (3.456 de 4.008)
• Itália — 85,4% (3.126 de 3.661)
• Alemanha — 81,4% (4.650 de 5.715)
• Espanha e Irlanda — 78,8% cada

Os autores reconhecem as limitações, e isso é honesto: uma empresa pode estar sob vários provedores ao mesmo tempo (contagem dupla), e a amostra está inclinada em direção a pequenas e médias empresas — um segmento onde o plano gratuito do Cloudflare é mais forte. Ou seja, 89,6% é a participação entre empresas com CDN detectado, e não entre todas as entidades jurídicas europeias.

Uma verificação independente da ordem de grandeza existe: segundo dados da W3Techs em setembro de 2026, o Cloudflare é utilizado por 84,7% dos sites que têm um reverse proxy conhecido, o que representa 25,2% de todos os sites em seu índice. Diferentes metodologias, diferentes amostras, mas a conclusão é uma: diante de um quarto da web e da esmagadora maioria das instalações de CDN reconhecidas, há um único intermediário.

Por que para automação isso não é apenas uma "quota de mercado"

Quando há muitos filtros, um erro em uma impressão custa o acesso a um site. Quando o filtro é praticamente um só, um erro custa o acesso a todo o segmento de uma vez — e isso muda a economia do trabalho.

O Cloudflare atribui uma pontuação de bot de 1 a 99 a cada solicitação: quanto mais baixa, maior a confiança de que a automação está diante do site. O modelo que calcula essa pontuação, segundo a descrição da própria empresa, processa mais de 46 milhões de solicitações HTTP por segundo e considera não apenas sua solicitação específica, mas também a estatística global de toda a rede: reputação do IP, ASN e tipo de endereço (data center / residencial / móvel), consistência dos cabeçalhos, impressão TLS, sinais comportamentais. A detecção é em camadas — heurísticas mais ML, sendo que a maior parte das decisões é baseada em aprendizado de máquina.

Consequência prática: seu pool e sua impressão são avaliados não pelo site, mas pela rede. Se você foi detectado em um recurso, o sinal de reputação já foi considerado na próxima solicitação a outro. Em um mundo onde nove em cada dez sites europeus estão nessa rede, "mudar para outro alvo e esperar" deixa de ser uma estratégia.

IP residencial deixou de ser uma indulgência

A antiga lógica de "pegou um endereço residencial — passou como um humano" esbarra no fato de que o provedor de filtro já captura esse truque há muito tempo. O Cloudflare descreveu publicamente um modelo separado contra bots que usam proxies residenciais: inicialmente, tentaram sinais de rede (saltos extras, latência), mas desistiram devido a falsos positivos na internet via satélite, e passaram para a análise comportamental — picos característicos de atividade em endereços IP. Em sua publicação, eles apresentaram a escala do fenômeno que observam: cerca de 17 milhões de IPs únicos por hora envolvidos em ataques através de proxies residenciais, 45 mil ASN e 237 países e regiões (os números referem-se a março de 2024, e a empresa não forneceu dados mais recentes). A precisão declarada na classificação de um ataque distribuído a um de seus clientes é de 95%, com um aumento de 20% na detecção de bots de redes em nuvem.

Um detalhe importante de lá: o modelo não é intencionalmente construído para bloquear IPs — para não derrubar usuários reais das mesmas redes. Essa é uma boa notícia para o tráfego legítimo de endereços residenciais e uma má notícia para aqueles que acreditam que "casa" por si só dá luz verde. O que funciona não é o tipo de endereço, mas a combinação "tipo de endereço + comportamento + impressão". Fizemos uma análise detalhada das diferenças entre os muros em comparação sistemas anti-bots do Cloudflare, DataDome, Akamai e Kasada — agora vale a pena voltar a isso com a correção de que os pesos na primeira linha na Europa se tornaram desproporcionalmente muitos.

Lado oposto: quando um cai — todos caem

Uma monocultura tem um segundo lado, não sobre bloqueios, mas sobre disponibilidade. Os últimos um ano e meio deram três episódios exemplares:

1. 18 de novembro de 2025 — uma falha global que afetou, segundo estimativas, cerca de uma em cada cinco páginas da web e um terço dos 10.000 sites e serviços mais populares. A razão, segundo a análise da própria empresa: uma alteração de permissões no cluster ClickHouse levou à duplicação de linhas no arquivo de características usado pelo modelo de ML para pontuação de bots. Ironicamente: o mecanismo que decide se você é humano ou não derrubou uma parte significativa da internet.
2. 5 de dezembro de 2025 — falha às 8:47 UTC por cerca de 25 minutos, afetando um subconjunto de clientes que representavam cerca de 28% de todo o tráfego HTTP passando pela rede.
3. 20 de fevereiro de 2026 — às 17:48 UTC, parte dos clientes usando BYOIP (seus próprios intervalos de IP) tiveram seus roteamentos retirados via BGP devido a uma mudança no pipeline de integração de endereços.

A formulação dos autores da pesquisa aqui é precisa: quando um provedor domina a maior parte do mercado, seus erros deixam de ser seus problemas e se tornam problemas de todos ao mesmo tempo. Para o pipeline de coleta de dados, isso significa que "o site alvo caiu" e "toda a região caiu" agora se diferenciam mal — e alertas configurados para um domínio específico mentem.

O que fazer com isso na prática

Abaixo estão as mudanças reais no processo de trabalho, se aceitarmos a monocultura do filtro como um dado.

1. Teste a combinação em mais de um site. Se sua impressão passa em três recursos — você provavelmente testou o mesmo filtro três vezes. Inclua no conjunto de testes um recurso do CloudFront, um do Fastly, um do Akamai e um sem CDN, caso contrário, a amostra não prova nada.
2. Divida os pools por projetos, e não por sites. Uma vez que a reputação é avaliada pela rede, "um pool separado para cada domínio" não isola nada. A isolação faz sentido no nível do projeto e do perfil: um projeto — seu próprio pool de endereços, seu próprio conjunto de impressões, seu próprio ritmo.
3. Observe o tipo e a origem do endereço. ASN e categoria de endereço são entradas diretas na pontuação. Para fins sensíveis, são razoáveis proxies residenciais e endereços móveis; tarefas técnicas em massa (verificação de disponibilidade, suas APIs, trabalho com plataformas sem um anti-bot rigoroso) são mais baratas e honestas ao serem fechadas com proxies de data center, sem desperdiçar tráfego caro.
4. Não queime a sub-rede. Modelos comportamentais capturam picos de atividade em um endereço. Um ritmo uniforme em um pool amplo sobrevive melhor à pontuação do que um curto ataque agressivo de um estreito.
5. Organize sua impressão como um todo. Impressão TLS, ordem e composição dos cabeçalhos, versão HTTP, comportamento JS — são avaliados em conjunto. Um IP residencial com a impressão de um cliente HTTP nu dá um resultado pior do que um endereço de data center cuidadoso com uma pilha de navegador honesta.
6. Separe "fomos bloqueados" e "eles têm uma falha". Regra simples: em caso de aumento massivo de erros, primeiro verifique se tudo caiu ao mesmo tempo em vários alvos não relacionados e o que a página de status do provedor mostra. Retries durante uma falha global são uma maneira de queimar o pool sem motivo.
7. Tenha um plano B para o dia em que o filtro cair. Uma fila de tarefas que pode esperar e recuperar o que foi perdido é mais cara de desenvolver, mas sobrevive a 25 minutos de indisponibilidade sem perda de dados.

Conclusão

O número 89,6% não diz que o Cloudflare é ruim, nem que a web europeia se fechou. Ele diz que a diversidade de alvos não significa mais diversidade de obstáculos. Uma pontuação, um modelo, uma base de reputação — e, como consequência, um único modo de falha: tanto quando você é confundido com um bot, quanto quando o provedor derruba os roteamentos.

A conclusão para a prática é entediante, mas funcional: parar de otimizar a contornagem "para o site" e começar a otimizar o comportamento — qualidade dos endereços, ritmo uniforme, impressão consistente, diagnóstico honesto de falhas. Isso é o único que funciona igualmente bem tanto do lado de 89,6% quanto do lado oposto.