Aviso legal: este análisis profundo de Akamai Bot Manager v2 se publica para investigación de seguridad autorizada, pentesting con consentimiento del propietario y automatización legítima sobre sitios donde tienes permiso explícito. Eludir controles anti-bot sin autorización puede violar la CFAA (EE. UU.), el Reglamento GDPR (UE) y los términos de servicio del sitio. ProxyHat no respalda el fraude, el bypass no autorizado ni la evasión de controles de seguridad.
Si has llegado hasta aquí es porque tu automatización legítima —monitorización de precios, auditoría SERP, investigación de seguridad— choca con un muro opaco: la cookie _abck se invalida sin razón aparente, tus sesiones rotan a un challenge infinito y ningún nivel de cabeceras HTTP parece suficiente. Este artículo explica, a nivel de ingeniería, cómo Akamai Bot Manager v2 puntúa tu tráfico en 2026 y qué necesita una sesión residencial para pasar limpiamente.
Qué es Akamai Bot Manager v2 y por qué importa este análisis profundo
Akamai Bot Manager v2 es la segunda generación del sistema de gestión de bots de Akamai, desplegado en el edge de su CDN. A diferencia de un WAF clásico basado en reglas, v2 combina telemetría de cliente (el motor bmak/sensor.js), huellas de protocolo (TLS, HTTP/2) y reputación de IP en un modelo de puntuación continua del lado del servidor. El resultado es un trust score que se recalcula en cada request, no una decisión binaria de allow/block.
El cambio clave respecto a la v1 es que el score ya no vive solo en la cookie _abck: el servidor mantiene un estado paralelo por sesión y por IP, de modo que manipular la cookie sin reproducir la telemetría correcta genera una inconsistencia inmediata. Por eso el akamai bot manager bypass de 2026 no es un truco de cabeceras: es la reproducción fiel de toda la pila de señales en cada request.
La pila de señales: _abck, ak_bmsc y el motor sensor.js/bmak
Akamai emite dos cookies coordinadas:
_abck: cookie de sesión cifrada que codifica el trust score actual, el identificador de challenge y metadatos de entorno. Se reescribe en cada respuesta. Un valor con el sufijo~-1~-1~-1indica challenge pendiente; un valor con~0~-1~-1indica sesión validada.ak_bmsc: cookie de persistencia que vincula la sesión HTTP con el challenge server-side. Su ausencia o inconsistencia con_abckfuerza un nuevo challenge.
El motor que alimenta estas cookies es sensor.js, ofuscado y servido dinámicamente por Akamai. Internamente expone el objeto bmak, que recoge eventos del navegador y los empaqueta en un payload opaco llamado sensor_data. Este payload es la prueba criptográfica de que el cliente es un navegador real ejecutando JavaScript con interacción humana plausible.
El flujo es:
- El navegador carga la página;
sensor.jsse ejecuta y comienza a capturar eventos. - Tras un intervalo (normalmente 1–3 segundos de actividad),
bmakensamblasensor_datay lo envía al endpoint de challenge. - El servidor valida el payload, recalacula el trust score y reescribe
_abck. - Si el score es bajo, el servidor devuelve un challenge secundario (visual o invisible) o bloquea directamente.
La documentación pública de Akamai TechDocs describe Bot Manager a nivel conceptual; los detalles internos de sensor_data no están documentados oficialmente y se reconstruyen por análisis de tráfico autorizado.
Cómo se ensambla sensor_data: eventos, GPU, timing y el campo que invalida todo
El payload sensor_data akamai es una cadena codificada (base64 con transformaciones propias) que empaqueta cientos de campos. Las categorías principales son:
- Eventos de interacción: coordenadas de mouse (con precisión sub-píxel en navegadores que lo soportan), timestamps de cada evento, scroll vertical/horizontal, eventos touch y teclas. Akamai mide la distribución estadística de estos eventos: un mouse que se mueve en línea recta perfecta o con intervalos exactos de 50 ms es inmediatamente sospechoso.
- Propiedades de pantalla y render: dimensiones
screen.width,screen.height,window.devicePixelRatio,colorDepth,availWidth/Height. La huella denavigatorincluyeuserAgent,platform,hardwareConcurrency,deviceMemory,languagesy la lista deplugins. - GPU y canvas:
WEBGL_debug_renderer_infoexpone el vendor y renderer reales de la GPU (por ejemploANGLE (NVIDIA, NVIDIA GeForce RTX 4060)). La huella de canvas —el hash del render de texto y formas— se incluye como campo derivado. - Timing de ejecución:
performance.now()en momentos clave, tiempo de carga desensor.js, latencia deXMLHttpRequest. Akamai detecta entornos headless porque el timing de operaciones criptográficas internas debmakdifiere entre V8 real y motores embebidos. - Estado del entorno: presencia de
webdriver,Notification.permission,navigator.permissions, estado deWebGL,AudioContexty diferencias entrescreenywindow.
El punto crítico: Akamai no valida campos aislados, valida consistencia cruzada. Si tu userAgent dice Chrome 131 en Windows pero tu navigator.platform dice Linux x86_64, o si tu GPU reporta SwiftShader (el renderer software de Chrome headless), el trust score colapsa. Un solo campo contradictorio invalida _abck y fuerza un nuevo challenge, incluso si el resto del payload es perfecto. Esto es lo que hace que el bypass naïf con cabeceras falle sistemáticamente.
Señales de protocolo 2026: X25519MLKEM768, JA4 y HTTP/2 SETTINGS
En 2026 la pila de señales de red pesa tanto como la telemetría de cliente. Tres vectores son los que más discriminan:
Post-quantum key share: X25519MLKEM768
Desde Chrome 131, el navegador envía por defecto el key share híbrido post-cuántico X25519MLKEM768 en el ClientHello de TLS 1.3, según el anuncio del equipo de Chromium. Esto añade ~1.2 KB al ClientHello y cambia el orden de extensiones. Cualquier cliente HTTP que use una librería TLS estándar (OpenSSL sin parchear, BoringSSL antiguo) no enviará este key share, lo que delata inmediatamente que no es un Chrome real. Akamai compara el key share declarado con el User-Agent: si el UA dice Chrome 131+ pero el ClientHello no incluye X25519MLKEM768, el score baja.
JA4 TLS fingerprint
JA4, desarrollado por FoxIO, es el sucesor de JA3 y hash el conjunto (versión TLS, extensiones ordenadas, curvas elípticas, formatos de firma) en un formato legible como t13d1516h2_8daaf6152771_b186095e22b6. A diferencia de JA3, JA4 ordena las extensiones alfabéticamente, lo que lo hace estable entre versiones menores de navegador. Akamai mantiene una base de datos de hashes JA4 legítimos por versión de navegador. Un cliente Python requests con urllib3 produce un JA4 que no coincide con ningún Chrome real, sin importar qué UA envíes.
HTTP/2 SETTINGS y orden de frames
El fingerprint HTTP/2 captura el frame SETTINGS inicial (valores de HEADER_TABLE_SIZE, INITIAL_WINDOW_SIZE, MAX_CONCURRENT_STREAMS), el orden de pseudo-headers (:method, :authority, :scheme, :path) y los frames WINDOW_UPDATE posteriores. Chrome, Firefox y Safari tienen órdenes distintos y Akamai los compara con el UA declarado. Un cliente que use HTTP/1.1 cuando el UA implica HTTP/2, o que envíe SETTINGS con valores por defecto de hyper/h2, queda marcado.
| Señal | Chrome 131 real | requests/urllib3 | Headless sin parchear |
|---|---|---|---|
| Key share PQ | X25519MLKEM768 presente | Ausente | Ausente |
| JA4 hash | Coincide con UA | No coincide con ningún navegador | No coincide |
| HTTP/2 SETTINGS | Orden Chrome nativo | Por defecto de librería | Variable |
| GPU renderer | GPU física real | N/A (sin JS) | SwiftShader |
| webdriver flag | false | N/A | true (detectable) |
La conclusión operativa: para pasar akamai bot detection 2026 necesitas un cliente cuyo stack TLS y HTTP/2 sea indistinguible de un navegador real, no solo cabeceras que lo imiten.
Por qué los proxies residenciales son obligatorios
Akamai pondera la reputación de IP de forma agresiva. Los rangos ASN de datacenter conocidos (DigitalOcean, OVH, Hetzner, AWS, Google Cloud, Azure) están pre-puntuados como bot con un score base bajo antes de evaluar cualquier otra señal. Esto significa que incluso con un navegador perfecto, sensor_data impecable y JA4 correcto, una IP de datacenter arrastrará el trust score global por debajo del umbral.
Los proxies residenciales asignan IPs de proveedores de ISP reales (Movistar, Comcast, Vodafone, Deutsche Telekom), con ASN residencial y registros WHOIS consistentes. Akamai no puede pre-marcar estos rangos como bot sin generar falsos positivos masivos sobre usuarios reales, por lo que la IP residencial empieza con un score neutro y la decisión recae en la telemetría.
Los proxies móviles son aún mejores para casos de alto riesgo: el tráfico móvil legítimo tiene patrones de rotación de IP naturales (cambios de torre, NAT de operador) que Akamai tolera. Sin embargo, para la mayoría de automatización autorizada, los residenciales ofrecen el mejor equilibrio coste/éxito.
| Tipo de proxy | Reputación ASN | Score base Akamai | Adecuado para |
|---|---|---|---|
| Datacenter | Baja (pre-marcado) | Bot por defecto | No recomendado |
| Residencial | Neutra (ISP real) | Neutro | Scraping, SERP, monitoring |
| Móvil | Alta (operador) | Favorable | Casos de alto riesgo |
Implementación práctica con ProxyHat y un contexto de navegador stealth
El enfoque legítimo y robusto no es falsificar sensor_data a mano (frágil, se rompe en cada actualización de sensor.js), sino ejecutar un navegador real con stealth patches sobre una IP residencial de ProxyHat. De este modo bmak se ejecuta nativamente, recoge eventos reales y genera _abck válida sin ingeniería inversa.
Paso 1: configurar el proxy residencial
ProxyHat expone el gateway gate.proxyhat.com en el puerto 8080 (HTTP) o 1080 (SOCKS5). La geo-selección va en el usuario:
# HTTP residencial, IP de EE. UU.
http://user-country-US:pass@gate.proxyhat.com:8080
# HTTP residencial, ciudad específica (Berlín)
http://user-country-DE-city-berlin:pass@gate.proxyhat.com:8080
# SOCKS5 residencial
socks5://user-country-US:pass@gate.proxyhat.com:1080
# Sesión sticky para mantener _abck coherente
http://user-country-US-session-abc123:pass@gate.proxyhat.com:8080La sesión sticky es crítica: _abck está vinculada a la IP. Si rotas IP en cada request, el servidor detecta el cambio de IP con la misma cookie y invalida la sesión. Usa session-abc123 para fijar la IP durante toda la sesión de navegación.
Paso 2: lanzar un navegador stealth con Playwright
Ejemplo en Python con Playwright y el plugin playwright-stealth, que parchea navigator.webdriver, chrome.runtime, permissions y otras señales comunes:
from playwright.sync_api import sync_playwright
PROXY = "http://user-country-US-session-abc123:pass@gate.proxyhat.com:8080"
with sync_playwright() as p:
browser = p.chromium.launch(
headless=False, # headless=True con stealth patches; False para debug
proxy={"server": PROXY},
args=[
"--disable-blink-features=AutomationControlled",
"--disable-features=IsolateOrigins,site-per-process",
],
)
context = browser.new_context(
user_agent="Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
"AppleWebKit/537.36 (KHTML, like Gecko) "
"Chrome/131.0.0.0 Safari/537.36",
viewport={"width": 1920, "height": 1080},
locale="en-US",
timezone_id="America/New_York",
)
# Aplicar scripts stealth aquí (playwright-stealth o equivalentes)
page = context.new_page()
page.goto("https://example-protected-site.com")
page.wait_for_timeout(3000) # dejar que sensor.js capture eventos
# Simular interacción humana plausible
page.mouse.move(100, 200)
page.mouse.move(150, 230, steps=5)
page.mouse.click(150, 230)
page.wait_for_timeout(2000)
# _abck ahora debería estar validada
cookies = context.cookies()
abck = [c for c in cookies if c["name"] == "_abck"]
print(abck[0]["value"] if abck else "_abck no emitida")
browser.close()Puntos clave:
- Headless con cuidado: Chrome headless antiguo expone
SwiftShadercomo GPU renderer. Usa--headless=new(Chrome 112+) que renderiza con GPU real cuando hay una, o ejecuta con un framebuffer virtual (xvfb). - Espera activa:
sensor.jsnecesita eventos reales antes de ensamblarsensor_data. Esperar 2–3 segundos y simular movimiento de mouse con pasos interpolados (steps=5) produce una distribución plausible. - Sesión sticky: el flag
session-abc123en el usuario ProxyHat mantiene la misma IP. Cambia el identificador solo cuando quieras rotar deliberadamente. - Timezone y locale coherentes: si tu IP es de EE. UU. pero
timezoneesEurope/Berlin, Akamai detecta la inconsistencia. Haz coincidir geo-IP, timezone y locale.
Paso 3: extracción de datos tras la validación
Una vez _abck está validada (valor con ~0~-1~-1), el contexto del navegador puede hacer requests subsecuentes sin re-challenge. Para scraping a escala, reutiliza el contexto para múltiples páginas del mismo dominio antes de rotar sesión:
# Reutilizar contexto para N páginas, luego rotar sesión
pages_to_scrape = ["/category/a", "/category/b", "/category/c"]
for path in pages_to_scrape:
page.goto(f"https://example-protected-site.com{path}")
content = page.content()
# procesar content
page.wait_for_timeout(1000)
context.close() # rotar sesión en la siguiente iteraciónErrores comunes y casos límite
- Rotar IP por request: el error más frecuente.
_abckestá ligada a IP; rotar rompe la sesión. Usa sticky sessions y rota solo entre sesiones lógicas completas. - Cabeceras sin navegador real: enviar
requestscon cabeceras de Chrome no reproduce JA4 ni HTTP/2 SETTINGS. Akamai lo detecta en el primer request. - Headless sin GPU:
SwiftShadercomo renderer es una señal roja. Usa--headless=newoxvfbcon GPU. - Timezone/geo incoherentes: IP de Alemania con timezone de Tokio genera inconsistencia inmediata.
- Velocidad inhumana: navegar 50 páginas en 5 segundos sin eventos de mouse entre ellas.
sensor.jsmide la densidad temporal de eventos. - Reutilizar _abck entre IPs: copiar una cookie
_abckvalidada a otra IP no funciona; el estado server-side está ligado a la IP original.
Configuración específica de ProxyHat
ProxyHat ofrece proxies residenciales, móviles y datacenter. Para Akamai Bot Manager v2, recomendamos residenciales con sesiones sticky. Puedes consultar precios en /es/pricing y la lista de ubicaciones en /es/locations.
Para casos de uso de scraping y monitorización SERP, consulta /es/use-cases/web-scraping y /es/use-cases/serp-tracking. La documentación técnica completa está en docs.proxyhat.com.
Parámetros de conexión resumidos:
| Parámetro | Valor |
|---|---|
| Gateway HTTP | gate.proxyhat.com:8080 |
| Gateway SOCKS5 | gate.proxyhat.com:1080 |
| Geo-selección | user-country-XX:pass |
| Ciudad | user-country-XX-city-name:pass |
| Sesión sticky | user-country-XX-session-ID:pass |
Cuándo es apropiado esto y cuándo no
Este enfoque es legítimo en:
- Investigación de seguridad autorizada: pentesting con scope firmado, bug bounty dentro del programa del objetivo.
- Monitorización de tu propia infraestructura: comprobación de disponibilidad y precios en sitios que controlas o donde tienes acuerdo.
- Scraping de datos públicos con permiso: sitios que permiten acceso programático en sus términos o robots.txt.
- Auditoría SERP de tu propia marca: seguimiento de posicionamiento con consentimiento implícito del motor.
No es apropiado para fraude, evasión de límites de compra en ticketing/sneaker bots, scraping de datos privados sin consentimiento, ni ninguna actividad que viole los términos del sitio, la CFAA o el GDPR. La diferencia entre automatización legítima y abuso no es técnica: es de consentimiento y propósito.
Puntos clave
Key Takeaways:
- Akamai Bot Manager v2 usa un modelo de puntuación continua server-side, no una decisión binaria.
_abckyak_bmscson coordenadas de un estado que también vive en el servidor.sensor_dataempaqueta cientos de campos con consistencia cruzada. Un solo campo contradictorio (GPU, platform, timezone) invalida la sesión.- En 2026, Chrome 131+ envía
X25519MLKEM768por defecto. Cualquier cliente sin este key share no puede impersonar Chrome real.- JA4 y HTTP/2 SETTINGS deben coincidir con el UA declarado.
requests/urllib3nunca pasarán.- Las IPs de datacenter están pre-marcadas como bot. Los proxies residenciales con sesión sticky son obligatorios.
- El enfoque robusto es un navegador real con stealth patches sobre IP residencial ProxyHat, no ingeniería inversa de
sensor_data.- Usa
gate.proxyhat.com:8080(HTTP) o:1080(SOCKS5) conuser-country-XX-session-IDpara sesiones coherentes.
Preguntas frecuentes
¿Qué es el análisis profundo de Akamai Bot Manager v2?
Es el estudio técnico de cómo Akamai Bot Manager v2 puntúa el tráfico automatizado en 2026: la cookie _abck, el motor sensor.js/bmak, el payload sensor_data, las huellas de protocolo (JA4, HTTP/2 SETTINGS, key share post-cuántico X25519MLKEM768) y la reputación de IP. El objetivo es entender qué señales evalúa el sistema para que la automatización legítima y autorizada pase de forma limpia.
¿Por qué importa Akamai Bot Manager v2 para usuarios de proxies?
Porque Akamai pondera la reputación de IP de forma agresiva y pre-marca los ASN de datacenter como bot. Sin un proxy residencial con sesión sticky, incluso un navegador perfecto obtiene un trust score bajo. La IP residencial proporciona un score base neutro que permite que la telemetría del navegador decida el resultado, en lugar de un rechazo automático por reputación.
¿Qué tipo de proxy funciona mejor para Akamai Bot Manager v2?
Proxies residenciales con sesiones sticky. Los residenciales ofrecen ASN de ISP real con score neutro; los móviles (operador) son aún mejores para casos de alto riesgo pero más caros. Los datacenter están pre-marcados como bot y no son viables. La sesión sticky es imprescindible porque _abck está ligada a la IP: rotar IP por request invalida la cookie inmediatamente.
¿Cómo evitar bloqueos al implementar Akamai Bot Manager v2?
Usa un navegador real (Playwright/Puppeteer con stealth patches) sobre IP residencial ProxyHat con sesión sticky, haz coincidir timezone/locale/geo-IP, simula interacción humana plausible (mouse con pasos interpolados, espera de 2–3 segundos para que sensor.js capture eventos), evita headless con SwiftShader y nunca rotes IP dentro de una misma sesión lógica. No intentes falsificar sensor_data a mano: se rompe en cada actualización.
¿Qué es la cookie _abck y por qué se invalida?
_abck es la cookie de sesión cifrada de Akamai que codifica el trust score actual. Un sufijo ~-1~-1~-1 indica challenge pendiente; ~0~-1~-1 indica sesión validada. Se invalida cuando el servidor detecta inconsistencia entre el payload sensor_data, la reputación de IP y el estado server-side: cambio de IP, campo de entorno contradictorio, JA4 que no coincide con el UA, o ausencia del key share post-cuántico en Chrome 131+.
