Social Rocket
Teníamos Cloudflare Bot Fight Mode activado. Aun así, el tráfico sospechoso llegaba hasta el sitio web.
Según nuestra experiencia como operadores, los desafíos de navegador tampoco funcionaron de forma fiable. Lo mismo ocurrió con un enfoque probado antes llamado „precursor“. Al final, lo decisivo no fue otra función genérica contra bots, sino una regla ajustada exactamente a los patrones de petición que observamos.
Nuestros agentes de IA extrajeron del tráfico dos patrones de scraping distintos y los tradujeron en una estrategia de bloqueo específica en Cloudflare. Las reglas combinan características del navegador, Fetch Metadata, redes de origen, referrers, páginas de entrada y la marca de crawlers verificados de Cloudflare. Las peticiones coincidentes se terminan directamente en el edge con HTTP 403.
Deliberadamente no publicamos las huellas completas. Una regla anti-scraping no es un buen lugar para un changelog público dirigido a los scrapers.
Lo que nos llamó la atención
La primera señal no vino de un único evento de seguridad, sino de la combinación de varios puntos de medición.
Una instantánea de Minilytics mostró 544 sesiones directas con cero conversiones de salida medidas. Entre dos horas completas, las sesiones directas subieron de 24 a 163.
Al mismo tiempo, en una ventana de 30 minutos analizada, Cloudflare registró aproximadamente 17.700 peticiones HTTP, de las cuales unas 15.400 llegaron al origen. Un fragmento de cinco minutos del origen contenía 1.980 peticiones de 1.238 direcciones IP distintas.
Es importante separar las magnitudes: una petición HTTP no es una sesión. Y „cero conversiones“ significa en este contexto cero eventos de salida configurados disparados, no que se haya demostrado cero ventas o cero ingresos.
Aun así, teníamos señal suficiente para desglosar el tráfico con más detalle.
Patrón 1: el navegador decía Chrome, pero los metadatos de la petición no encajaban
El primer grupo grande rotaba de forma masiva entre direcciones IP y países. Los clientes se presentaban como navegadores Chrome en Windows y alternaban entre varias identidades de Chrome.
En el fragmento analizado, 1.628 peticiones de 1.120 direcciones IP en 100 países pertenecían a este patrón. Una parte importante de ellas también consultaba datos de página de Next.js.
Eso por sí solo todavía no es una prueba de bot. Las solicitudes RSC también aparecen al navegar normalmente por páginas de Next.js.
La contradicción resultó interesante en otro punto: las solicitudes afirmaban una identidad de navegador moderna, pero faltaba por completo una característica de Fetch Metadata que habríamos esperado en esta clase de solicitudes.
Nuestra primera nueva lógica de bloqueo combina, por tanto, varias condiciones:
- Solicitud a un host de Srocket
- GET
- identidad de Chrome en Windows acorde al patrón observado
- falta la cabecera Fetch Metadata
- no es un bot verificado por Cloudflare
- no son rutas internas de Next.js o de API
No publicamos la lista concreta de versiones.
Esa es la diferencia decisiva frente a una regla burda de «bloquear la versión X de Chrome»: no es una sola propiedad la que activa el bloqueo, sino la contradicción entre la identidad de navegador declarada y el contexto de la solicitud realmente enviado.
Cloudflare proporciona con `cf.client.bot` un campo que identifica a los bots buenos conocidos y a los rastreadores. Estos rastreadores verificados los excluimos de la lógica de bloqueo.
Patrón 2: esta vez la solicitud del navegador parecía plausible
Poco después apareció un segundo patrón.
Estas solicitudes tenían cabeceras similares a las de un navegador y también usaban un valor `Sec-Fetch-Site` normal. Por eso no caían bajo la primera huella.
Aquí la señal estaba en la combinación de origen, perfil de navegador y página de destino.
Observamos accesos directos al HTML procedentes de un grupo rotatorio de redes de origen. Las solicitudes usaban solo unos pocos perfiles de navegador exactamente repetidos, llegaban sin referrer y apuntaban de forma selectiva a un pequeño grupo de nuestras páginas de comparación.
Precisamente por estas redes de origen cambiantes, las direcciones IP por sí solas sirven poco como huella. Quien quiera entender mejor el aspecto técnico de fondo encontrará en nuestra comparativa de proxies las diferencias entre los tipos de proxy y proveedores más habituales.
Nuestra segunda lógica de bloqueo combina, por tanto:
- un grupo de origen observado
- uno de los perfiles de navegador exactamente repetidos
- GET
- referrer vacío
- un pequeño grupo definido de páginas de entrada afectadas
- no es un bot verificado por Cloudflare
Importante: no bloqueamos un ASN completo de forma generalizada ni a todos los visitantes sin referrer. Solo la combinación de características conduce al bloqueo.
También las redes concretas, los user agents y las combinaciones de páginas siguen siendo internos.
Por qué `Sec-Fetch-Site: none` no es una señal de bot
El segundo patrón muestra bien por qué los encabezados individuales pueden ser criterios de bloqueo muy malos.
Según MDN, `Sec-Fetch-Site: none` es un comportamiento completamente normal del navegador, por ejemplo cuando alguien escribe una URL directamente en la barra de direcciones o abre un marcador.
Por tanto, una solicitud con este valor no es automáticamente sospechosa.
Por eso solo bloqueamos este grupo cuando el pool de origen, el perfil exacto del navegador, el referrer vacío y la página de entrada afectada coinciden al mismo tiempo.
Esto es más estrecho que una regla genérica contra bots, y es intencionadamente así.
La IA no «detectó un bot»: construyó dos modelos de reglas a partir de ello
La parte que nos interesó no fue que un modelo mirara el tráfico y dijera «bot».
La IA solo resultó útil cuando, a partir de muchas solicitudes individuales, surgieron dos patrones técnicos distinguibles:
1. Contradicción de identidad: el perfil del navegador y los Fetch Metadata no encajan entre sí. 2. Huella de origen: procedencia, perfil del navegador, entrada directa y página de destino aparecen repetidamente juntos.
A partir de estos patrones, nuestros agentes de IA derivaron una estrategia de Cloudflare que luego comprobamos frente a solicitudes reales y accesos normales de navegador.
Para nosotros, esta es la forma de IA en funcionamiento mucho más interesante: no un chatbot que explica la seguridad, sino agentes que traducen telemetría real en una regla de borde controlada.
Ya hemos descrito en otro lugar por qué el tráfico de bots puede distorsionar la atribución y el retargeting. Al mismo tiempo, el debate actual sobre las obligaciones de transparencia para los rastreadores de IA muestra lo difícil que se ha vuelto atribuir limpiamente el tráfico automatizado.
Ningún despliegue adicional: la regla está directamente en Cloudflare
La solución final funciona como una regla personalizada de Cloudflare existente con la acción Bloquear.
No tuvimos que desplegar la aplicación ni consumir otro espacio de reglas. La regla de escáner/flood que ya existía se amplió con los dos patrones adicionales.
La lógica solo puede resumirse a nivel de principio:
- Los escáneres ya confirmados siguen bloqueados.
- El patrón 1 solo se activa si la identidad del navegador y los Fetch Metadata son contradictorios de la forma observada, la solicitud es un GET, no se detecta ningún bot verificado y no se ven afectadas rutas internas de framework o de API.
- El patrón 2 solo se activa con la combinación de un grupo de origen observado, un perfil de navegador exactamente recurrente, acceso directo sin referrer y una de las páginas de entrada afectadas.
- Solo cuando una rama coincide por completo, se ejecuta la acción Block.
No publicamos las redes concretas, las versiones de navegador, los user agents ni la expresión productiva de Cloudflare. Un scraper no necesita saber más sobre la regla.
Cloudflare recomienda por sí mismo las Custom Rules cuando hay que combinar varios campos de la solicitud. Una acción de bloqueo terminante ya se aplica a nivel de las Custom Rules y evita que las solicitudes coincidentes sigan pasando a mecanismos de bot posteriores.
Qué pasó después de activarla
No solo comprobamos si Cloudflare aceptaba la regla. Verificamos que realmente coincidiera con el patrón deseado y que el tráfico normal siguiera funcionando.
Las pruebas de control arrojaron:
- Solicitud de prueba con la primera huella: Cloudflare 403
- la misma familia de navegadores con características de navegación normales: 200
- página pública de comparación con acceso normal: 200
- evento real del segundo patrón: Custom rules / Block
- coincidencias de regla mostradas durante la prueba: unas 1.300
La evolución en el origen fue especialmente clara: con el primer patrón, las solicitudes coincidentes de 626 cayeron a cero en un minuto completo durante el último intervalo de 18 segundos del fragmento analizado.
En una comprobación posterior con Minilytics, durante 156 segundos no se añadieron nuevas sesiones directas sin conversión de salida.
Esto no demuestra que el tráfico no deseado haya desaparecido para siempre. Pero sí muestra que la nueva regla realmente interceptó en el edge los patrones observados.
Por qué no afirmamos que no pueda haber falsos positivos
Probamos la regla con accesos normales de tipo navegador y la acotamos deliberadamente.
Aun así, decir «garantizado sin falsas alarmas» sería poco serio.
Un visitante directo real podría, en teoría, cumplir también varias características del segundo patrón a la vez, por ejemplo desde una red de origen afectada, con uno de los perfiles de navegador recurrentes y en una de las páginas afectadas.
Por eso no tratamos la regla como una solución anti-bots universal, sino como una huella específica del incidente con posibilidad documentada de revertirla.
Lo mismo vale para el primer patrón. Si los scrapers cambian su identidad de solicitud, también una huella puede perder eficacia.
La ventaja está precisamente en que no afirmamos ninguna solución mágica permanente: podemos observar, volver a clasificar y ajustar la regla de borde de forma específica.
Lo que nos llevamos del incidente
Bot Fight Mode no fue inútil. Pero una defensa genérica contra bots no pudo frenar suficientemente, en nuestro caso, estos dos patrones de tráfico.
Solo la combinación de telemetría propia, análisis de patrones con IA y una Custom Rule de Cloudflare precisa marcó la diferencia.
Para otros sitios web, nuestras huellas concretas no son transferibles. El método sí lo es:
No persigas direcciones IP. No bloquees cabeceras individuales de forma aislada. Combina varias características independientes de la solicitud, excluye los crawlers verificados, prueba los accesos normales de navegador y mide el efecto después.
Así, nuestros agentes de IA convirtieron un problema de tráfico en una regla de borde verificable, sin entregar a los scrapers una guía universal.