El 7 de septiembre de 2026, los investigadores de CipherCue publicaron una medición que todos los que navegan por la web europea de forma automatizada deberían leer: de 44,143 empresas europeas en las que se logró detectar CDN, el 89,6% está detrás de Cloudflare. No es "el líder del mercado por un amplio margen", sino casi todo el mercado en su conjunto. Para el scraping, la multi-cuenta y cualquier automatización, esto significa una cosa simple: el acceso a nueve de cada diez sitios en la UE es gestionado por el mismo algoritmo, según los mismos criterios, en el mismo segundo.
Qué se ha contado exactamente
La muestra incluye empresas de Alemania, Reino Unido, Países Bajos, Polonia, Francia, Italia, España e Irlanda, que tienen al menos un componente CDN en su sitio web. La detección se realizó a través de las respuestas HTTP y las huellas del servidor: el encabezado cf-ray y server: cloudflare para Cloudflare, x-served-by con el marcador de caché para Fastly, x-amz-cf-id para CloudFront. La fecha de observación es el 7 de septiembre de 2026.
Distribución por proveedores:
- Cloudflare — 39,547 empresas (89,6%)
- Amazon CloudFront — 3,112
- Fastly — 1,299
- Akamai — 396
Por países, la dispersión es notable, pero el techo es alto en todas partes:
- Países Bajos — 95,6% (7,587 de 7,939)
- Reino Unido — 93,2% (15,846 de 17,007)
- Polonia — 92,6% (2,682 de 2,896)
- Francia — 86,2% (3,456 de 4,008)
- Italia — 85,4% (3,126 de 3,661)
- Alemania — 81,4% (4,650 de 5,715)
- España e Irlanda — 78,8% cada una
Los autores reconocen las limitaciones, y esto es honesto: una empresa podría estar bajo varios proveedores a la vez (doble conteo), y la muestra está sesgada hacia las pequeñas y medianas empresas, un segmento donde el plan gratuito de Cloudflare es más fuerte. Es decir, el 89,6% es la proporción entre las empresas con CDN detectado, y no entre todas las entidades europeas.
Hay una verificación independiente del orden de magnitud: según datos de W3Techs en septiembre de 2026, Cloudflare es utilizado por el 84,7% de los sitios que tienen un reverse proxy conocido, lo que representa el 25,2% de todos los sitios en su índice. Diferentes metodologías, diferentes muestras, pero la conclusión es una: ante una cuarta parte de la web y la abrumadora mayoría de las instalaciones de CDN reconocibles, hay un solo intermediario.
Por qué para la automatización no es "solo una cuota de mercado"
Cuando hay muchos filtros, un error en una huella cuesta el acceso a un solo sitio. Cuando el filtro es prácticamente uno, el error cuesta el acceso a todo el segmento de una vez — y esto cambia la economía del trabajo.
Cloudflare asigna a la solicitud un bot score de 1 a 99: cuanto más bajo, mayor es la confianza de que hay automatización frente al sitio. El modelo que calcula esta puntuación, según la descripción de la propia empresa, procesa más de 46 millones de solicitudes HTTP por segundo y considera no solo su solicitud específica, sino también la estadística global de toda la red: la reputación de la IP, ASN y tipo de dirección (centro de datos / residencial / móvil), consistencia de encabezados, huella TLS, señales de comportamiento. La detección es en capas: heurísticas más ML, y gran parte de las decisiones provienen del aprendizaje automático.
Consecuencia práctica: su grupo y su huella son evaluados no por el sitio, sino por la red. Si se ha identificado en un recurso, la señal de reputación ya se ha tenido en cuenta en la siguiente solicitud a otro. En un mundo donde esta red alberga nueve de cada diez sitios europeos, "cambiar a otro objetivo y esperar" deja de ser una estrategia.
La IP residencial dejó de ser una indulgencia
La antigua lógica de "tomé una dirección residencial — pasé como humano" se encuentra con que el proveedor de filtros ha estado atrapando este truco durante mucho tiempo. Cloudflare ha descrito públicamente un modelo específico contra bots que utilizan proxies residenciales: primero intentaron señales de red (saltos adicionales, latencia), pero abandonaron debido a falsos positivos en internet satelital, y pasaron al análisis de comportamiento — picos característicos de actividad en las direcciones IP. En su publicación se presenta la magnitud del fenómeno que observan: alrededor de 17 millones de IP únicas por hora involucradas en ataques a través de proxies residenciales, 45,000 ASN y 237 países y regiones (las cifras corresponden a marzo de 2024, la empresa no ha proporcionado datos más recientes). La precisión declarada en la clasificación de ataques distribuidos a uno de los clientes es del 95%, con un aumento del 20% en la detección de bots desde redes en la nube.
Un detalle importante de allí: el modelo no se basa intencionadamente en el bloqueo de IP — para no expulsar a usuarios reales de las mismas redes. Esta es una buena noticia para el tráfico legítimo desde direcciones residenciales y mala para aquellos que creen que "el hogar" por sí mismo da luz verde. No es el tipo de dirección lo que importa, sino la combinación "tipo de dirección + comportamiento + huella". Hicimos un análisis detallado de las diferencias entre los muros en comparación con los sistemas anti-bots de Cloudflare, DataDome, Akamai y Kasada — ahora vale la pena volver a ello con la corrección de que la primera línea en Europa ha crecido desproporcionadamente.
El lado opuesto: cuando uno cae, todos caen
La monocultura tiene un segundo lado, no sobre bloqueos, sino sobre disponibilidad. Los últimos año y medio han dado tres episodios ejemplares:
- 18 de noviembre de 2025 — una falla global que afectó, según estimaciones, aproximadamente a una de cada cinco páginas web y a un tercio de las 10,000 páginas y servicios más populares. La causa, según el análisis de la propia empresa: un cambio de permisos en el clúster de ClickHouse llevó a la duplicación de filas en el archivo de características que utiliza el modelo de ML para puntuar bots. Irónicamente, el mecanismo que decide si eres humano o no, afectó a una parte considerable de internet.
- 5 de diciembre de 2025 — una falla desde las 8:47 UTC durante aproximadamente 25 minutos, que afectó a un subconjunto de clientes que representaban alrededor del 28% de todo el tráfico HTTP que pasaba por la red.
- 20 de febrero de 2026 — a las 17:48 UTC, parte de los clientes que utilizan BYOIP (sus propios rangos de IP) vieron que sus rutas fueron retiradas por BGP debido a un cambio en el proceso de incorporación de direcciones.
La formulación de los autores del estudio aquí es precisa: cuando un proveedor representa a la mayor parte del mercado, sus errores dejan de ser su problema y se convierten en el problema de todos al mismo tiempo. Para el pipeline de recolección de datos, esto significa que "el sitio objetivo ha caído" y "toda la región ha caído" ahora se diferencian mal — y las alertas configuradas para un dominio específico son engañosas.
Qué hacer prácticamente con esto
A continuación, lo que realmente cambia en el proceso de trabajo si se acepta la monocultura del filtro como un hecho.
- Pruebe la combinación en más de un sitio. Si su huella pasa en tres recursos, probablemente ha verificado el mismo filtro tres veces. Incluya en el conjunto de prueba un recurso de CloudFront, uno de Fastly, uno de Akamai y uno sin CDN en absoluto, de lo contrario la muestra no prueba nada.
- Divida los grupos por proyectos, no por sitios. Dado que la reputación es evaluada por la red, "un grupo separado para cada dominio" no aísla nada. El aislamiento tiene sentido a nivel de proyecto y perfil: un proyecto — su propio grupo de direcciones, su propio conjunto de huellas, su propio ritmo.
- Preste atención al tipo y origen de la dirección. ASN y categoría de dirección son la entrada directa al scoring. Para objetivos sensibles, son razonables proxies residenciales y direcciones móviles; las tareas técnicas masivas (verificación de disponibilidad, sus propias API, trabajo con plataformas sin un anti-bot estricto) son más baratas y honestas de cerrar con proxies de centro de datos, sin desperdiciar tráfico costoso.
- No queme la subred. Los modelos de comportamiento detectan picos de actividad en la dirección. Un ritmo uniforme en un amplio grupo sobrevive mejor al scoring que un corto y agresivo ataque desde uno estrecho.
- Organice la huella en su totalidad. La huella TLS, el orden y composición de los encabezados, la versión HTTP, el comportamiento de JS — se evalúan juntos. Una IP residencial con la huella de un cliente HTTP desnudo da un peor resultado que una dirección de centro de datos ordenada con un stack de navegador legítimo.
- Distingue entre "nos bloquearon" y "tienen una falla". Regla simple: ante un aumento masivo de errores, primero verifique si todo ha caído al mismo tiempo en varios objetivos no relacionados y qué muestra la página de estado del proveedor. Los reintentos en medio de una falla global son una forma de quemar el grupo sin razón.
- Tenga un plan B para el día en que el filtro caiga. Una cola de tareas que puede esperar y recuperar lo perdido es más cara de desarrollar, pero sobrevive 25 minutos de inactividad sin pérdida de datos.
Conclusión
El número 89,6% no se trata de que Cloudflare sea malo, ni de que la web europea se haya cerrado. Se trata de que la diversidad de objetivos ya no significa diversidad de obstáculos. Un scoring, un modelo, una base de reputación — y, como consecuencia, un modo común de falla: tanto cuando te confunden con un bot, como cuando el proveedor cae rutas por sí mismo.
La conclusión para la práctica es aburrida, pero efectiva: dejar de optimizar el bypass "por sitio" y comenzar a optimizar el comportamiento — la calidad de las direcciones, un ritmo uniforme, una huella coherente, un diagnóstico honesto de fallas. Esto es lo único que funciona igual de bien tanto del lado del 89,6% como del otro.