Has recibido un 403 — y lo primero que normalmente se hace es intentar cambiar el proxy. A veces ayuda, pero más a menudo no. Porque "antibot" no es una sola tecnología, sino al menos seis sistemas diferentes con distintas mecánicas de detección, diferentes niveles de rigor y diferentes requisitos para tu tráfico. Lo que te salva de Imperva es inútil contra Kasada. Vamos a desglosar quién es quién en 2026, cómo identificar al proveedor en 30 segundos y qué cambiar específicamente en la pila de proxies para cada uno.
Por qué "simplemente cambiar el proxy" ha dejado de funcionar
La lógica clásica era simple: si bloqueaban la IP, tomábamos otra. Funcionaba mientras la detección se basaba en la reputación de la dirección. Hoy en día, la IP es solo una capa de cinco, y su peso es fundamentalmente diferente entre distintos proveedores.
El conjunto general de señales que todos utilizan de una forma u otra:
- Huella TLS (JA3/JA4) — el orden de los conjuntos de cifrado y extensiones en el handshake;
- orden y registro de los encabezados HTTP — en el cliente de Python no es igual que en Chrome;
- reputación de la IP — ASN, pertenencia a un centro de datos, historial de la dirección;
- huella del navegador — canvas, WebGL, sensores de hardware;
- biometría conductual — trayectorias del ratón, velocidad de desplazamiento, patrón de entrada.
La conclusión clave que repiten todos los investigadores del tema: es importante la coherencia de las señales. La combinación de User-Agent de Chrome con la huella TLS de Python te marca como un bot ante cualquiera de los proveedores, independientemente de cuán limpia sea tu IP. Una dirección residencial no "cubre" una capa de navegador defectuosa, y viceversa.
Paso uno: identificar al proveedor por las huellas
Antes de cambiar algo, observa los encabezados de respuesta y las cookies. Cada sistema deja una firma reconocible: esta es la forma más rápida de entender con qué estás tratando.
- Cloudflare — encabezado CF-RAY, cookies cf_clearance y __cf_bm, carga challenge.js; en nuevas versiones se encuentra el encabezado cf-mitigated.
- DataDome — cookies datadome y _dd_s, script tags.js.
- Akamai — cookie _abck, encabezado de referencia akamai-grn.
- PerimeterX (HUMAN Security) — cookies _px3, _pxvid, _pxhd, scripts px.js o d.js.
- Kasada — encabezados de la familia x-kpsdk-* (ct — token de desafío, dv — validación de dispositivo, cd — datos de desafío, v — versión), cookie KP_UIDz, scripts ips.js o p.js.
- Imperva (Incapsula) — cookies incap_ses_*, visid_incap_*, reese84.
- AWS WAF — cookie aws-waf-token, llamada al endpoint /challenge.js.
- F5 / Shape Security — cookies con prefijo TS (por ejemplo, TS01a2b3c4).
Un marcador adicional es la naturaleza misma de la denegación. Kasada responde con un 429 "desnudo" sin cuerpo de respuesta: si ves 403 o 429 junto con encabezados x-kpsdk-*, la cuestión está cerrada. DataDome a menudo devuelve 403 con una página CAPTCHA. Cloudflare — un desafío interactivo o Turnstile.
Cómo se diferencian realmente los sistemas por mecánica
La firma dice "quién", pero la táctica la define "cómo". Arquitectónicamente, los proveedores difieren significativamente.
Cloudflare — modelos globales en el borde de la red
Opera a nivel de CDN-edge: la decisión se toma antes de que la solicitud llegue a la aplicación. Los modelos son globales, entrenados en el tráfico de toda la red — aproximadamente una quinta parte de los sitios de Internet. Ventaja para ti: el comportamiento es predecible, la experiencia de un sitio se transfiere a otro. Desventaja: la red ve tu subred en miles de recursos simultáneamente, la reputación se acumula rápidamente.
DataDome — modelo personal para cada sitio
Diferencia clave: la plataforma mantiene alrededor de 85,000 modelos de ML de clientes, entrenados en el tráfico de un sitio específico, y procesa más de 5 billones de señales al día con un tiempo de respuesta de menos de 2 milisegundos. La consecuencia práctica es simple y desagradable: cada sitio protegido es una tarea separada. La combinación que funciona para Etsy no se transfiere a otro recurso bajo el mismo proveedor. En 2025 se añadió el análisis de intención (se evalúa el propósito de la visita, no solo el hecho de la automatización) y una categorización separada de los crawlers LLM.
Akamai — énfasis en TLS y telemetría
Verifica las señales del handshake y valida la telemetría conductual de su lado a través de la cookie _abck. Según mediciones independientes de 2026, Akamai e Imperva desafían a los clientes automatizados por defecto menos que Cloudflare y DataDome — pero eso no significa "más débil": donde se configura de manera agresiva, el bypass requiere una capa TLS correcta, no un cambio de IP.
PerimeterX / HUMAN — reputación de red
La reputación del cliente se extiende por toda la red del proveedor. Si te descubren en un sitio, llegas a otro ya marcado. Plataformas típicas: comercio electrónico y bienes raíces.
Kasada — interrogatorio activo del entorno
El sistema más estricto de los masivos. No solo recopila huellas, sino que interroga activamente el entorno: inspecciona el código del cliente a través de Function.prototype.toString(), aplica anti-deofuscación a sus propios scripts. Según evaluaciones agregadas de complejidad, recibe calificaciones extremas tanto en sofisticación de detección como en la dificultad de un bypass independiente. Se utiliza en ticketing y bienes raíces.
Imperva (Incapsula) — lógica WAF por defecto
Se basa en la IP y las reglas de WAF; las capas conductuales se activan en configuraciones más altas. Plataformas clásicas — sitios corporativos y bolsas de trabajo.
Quién es más estricto: números en lugar de sensaciones
Hay un benchmark independiente Scrapeway: ocho servicios contra once objetivos, más de 1000 solicitudes por servicio por objetivo, dos informes al mes. Los objetivos están asignados a los proveedores — Indeed bajo Cloudflare, Etsy bajo DataDome, Walmart y Zillow bajo PerimeterX, Realtor bajo Kasada.
Lo que muestran las mediciones de 2026:
- Alta estrictud — Cloudflare, DataDome, PerimeterX, Kasada: la abrumadora mayoría de los clientes automatizados por defecto y no configurados reciben un desafío.
- Moderada — Akamai e Imperva: desafían a los clientes por defecto notablemente menos.
- Contra los objetivos de Cloudflare, solo una pequeña fracción de los clientes no configurados recibió contenido de la página de manera constante.
Para comparación: en los servicios de bypass especializados, el éxito contra estos objetivos se mantiene en un rango del 94-100% dependiendo del proveedor — es decir, la tarea es resoluble, pero no con el cliente por defecto y no solo cambiando la IP.
Qué cambiar en la pila de proxies para cada uno
Ahora la práctica. A continuación — no es una receta de bypass, sino la lógica de selección de infraestructura según el tipo de detección.
- Imperva y AWS WAF. El peso de la IP es alto, las capas conductuales a menudo están desactivadas. Aquí los proxies de centros de datos aún son viables — siempre que las subredes sean limpias y la tasa razonable. Comienza desde aquí, es lo más barato en términos de tráfico.
- Akamai. El proxy resuelve menos que la capa TLS. Primero, ordena el handshake y el orden de los encabezados, y solo después eleva la clase de IP. Cambiar el proxy con una huella JA4 defectuosa no dará nada.
- Cloudflare. La reputación global significa que la subred se agota rápidamente y al instante en todas partes. Se necesitan proxies residenciales con un amplio pool y rotación razonable: no "nueva IP en cada solicitud", sino mantener la sesión durante el tiempo de la tarea lógica, de lo contrario se descompone el cf_clearance.
- DataDome. El modelo está entrenado en el tráfico de un sitio específico, por lo que lo más importante es la homogeneidad de tu comportamiento en él. Una IP residencial proporciona una puntuación de confianza positiva, porque las personas reales navegan desde conexiones residenciales — pero por sí sola, sin gestionar la huella del navegador, no garantiza nada. No transfieras ciegamente configuraciones de un sitio a otro. Detalles sobre la especificidad de este proveedor — en el análisis de proxies para DataDome.
- PerimeterX / HUMAN. Dado que la reputación es de red, la aislamiento es más importante que el volumen: diferentes proyectos — diferentes pools, para que la marca de un sitio no se transfiera a otros.
- Kasada. Las direcciones de centros de datos son bloqueadas en la entrada. El mínimo operativo — residenciales, y mejor aún proxies móviles: detrás de una IP móvil a través de CGNAT hay cientos de abonados vivos, y es más costoso para el sistema bloquear esa dirección. Además, es obligatorio que el User-Agent coincida con la versión actual del navegador — una cadena obsoleta revela la combinación instantáneamente.
El error principal: pila heterogénea
Repitamos lo que comenzamos, porque esta es la razón de la mayoría de los bloqueos "inexplicables". Todos los seis sistemas detectan desincronización entre capas. IP residencial de Alemania + zona horaria del sistema UTC + huella TLS de curl + Chrome actualizado en User-Agent — esto no es "casi pasó", es un perfil de bot listo. El proxy es responsable de exactamente una capa de cinco; las otras cuatro viven en tu cliente.
De aquí el orden práctico de trabajo: primero identifica al proveedor por la firma, luego evalúa qué capa es la más débil y repárala — y no la que sea más fácil de cambiar. Si después de ordenar la pila los objetivos siguen siendo inaccesibles, la cuestión pasa a ser "construir uno mismo o pagar por uno listo" — esta bifurcación la discutimos en el material proxies contra scraping API y desbloqueadores web.
En resumen
No existe un "antibot" único, y tampoco un bypass universal — ninguna técnica funciona contra los ocho sistemas a la vez. Identifica al proveedor por las cookies y encabezados (esto toma 30 segundos), comprende su mecánica — el peso de la IP en Imperva, TLS en Akamai, reputación global en Cloudflare, modelo personal del sitio en DataDome, etiqueta de red en PerimeterX, interrogatorio activo del entorno en Kasada — y selecciona el tipo de proxy según ello, no al azar. Los centros de datos son donde se mira la IP de manera formal; residenciales son donde se considera la confianza; móviles son donde la red bloquea estrictamente todo lo servidor. Y asegúrate de la coherencia de todas las capas: es precisamente en ella donde fallan la mayoría de los proyectos que parecen estar correctamente configurados.
```