Análisis profundo de Akamai Bot Manager v2: cómo funciona y cómo pasarlo limpiamente en 2026

Aviso legal: Este artículo está dirigido a investigadores de seguridad, equipos de QA autorizados y profesionales de automatización legítima. El acceso no autorizado a sistemas protegidos puede violar la Computer Fraud and Abuse Act (CFAA) y el RGPD europeo. Solo debes automatizar contra sitios donde tienes permiso explícito o donde los términos de servicio lo permiten.

Akamai Bot Manager v2 representa uno de los sistemas anti-bot más sofisticados del mercado en 2026. Si tu infraestructura de scraping se topa con un sitio protegido por Akamai, conoces los síntomas: respuestas 403 silenciosas, desafíos interminables y una cookie _abck que parece imposible de generar correctamente. Este análisis profundo de Akamai Bot Manager v2 desglosa cómo funciona el sistema a nivel técnico y qué necesitas para que tu automatización legítima pase limpiamente.

Análisis profundo de Akamai Bot Manager v2: arquitectura del sistema

Akamai Bot Manager v2 no es un simple WAF que filtra por User-Agent. Es un sistema de scoring continuo que combina señales del lado del cliente (navegador), señales de red (TLS, HTTP/2) y reputación de IP en un modelo server-side que asigna una puntuación de confianza a cada solicitud. El sistema se actualizó significativamente en 2025-2026 para incorporar nuevas señales post-cuánticas y un motor de telemetría más agresivo.

El flujo básico es el siguiente: cuando un navegador carga una página protegida, Akamai inyecta un script ofuscado (sensor.js o el payload bmak) que recolecta cientos de señales del entorno del navegador. Estas señales se empaquetan en un payload llamado sensor_data que se envía de vuelta al servidor. Akamai valida este payload, y si todo coincide, emite o actualiza la cookie _abck con un valor válido. Si algo no cuadra —un campo de GPU incorrecto, un timing imposible, un cipher TLS que no corresponde al User-Agent declarado— la cookie se marca como sospechosa y las solicitudes posteriores reciben desafíos o bloqueos.

Las cookies _abck y ak_bmsc: cómo funciona el trust score

Akamai utiliza dos cookies principales para gestionar el estado de confianza:

• _abck: Cookie de validación principal. Contiene un token firmado que indica si el cliente ha pasado el desafío del sensor. Un valor válido permite solicitudes normales; un valor inválido o ausente activa el desafío. La cookie se actualiza continuamente —no es un token one-shot— y cada interacción puede revalidarla. El _abck cookie es el primer indicador que los ingenieros revisan al diagnosticar bloqueos de Akamai.
• ak_bmsc: Cookie de sesión que rastrea el comportamiento del cliente a lo largo del tiempo. Se establece en la primera respuesta y se usa para correlacionar solicitudes posteriores. Si ak_bmsc cambia abruptamente o no coincide con el _abck esperado, el sistema incrementa el score de sospecha.

El aspecto crítico es que _abck no es estática. Akamai puede re-validar la cookie en cualquier momento mediante un desafío silencioso (un POST asíncrono a un endpoint de Akamai que re-evalúa el sensor_data). Esto significa que mantener una sesión requiere que el navegador siga generando señales válidas de forma continua, no solo en el momento del login inicial.

El motor sensor.js/bmak: cómo se ensambla el sensor_data

El corazón del sensor_data akamai es el script sensor.js, servido desde el dominio del cliente (normalmente ofuscado y minificado). En 2026, Akamai utiliza una versión significativamente más compleja del motor bmak que recolecta señales en tres categorías principales.

Señales de dispositivo y entorno

• Propiedades de pantalla: screen.width, screen.height, screen.availWidth, screen.availHeight, screen.colorDepth, devicePixelRatio. Un valor de colorDepth: 30 en un navegador que declara Windows es inmediatamente sospechoso —Windows usa 24 o 32.
• Propiedades de GPU: A través de WebGL, Akamai extrae el WEBGL_debug_renderer_info vendor y renderer. Si declaras Chrome en Windows pero tu GPU reporta Apple M2, el payload se invalida instantáneamente. La API de WebGL expone estos valores y Akamai los verifica contra el User-Agent declarado.
• Canvas fingerprinting: El motor renderiza texto y formas en un canvas off-screen y calcula un hash del resultado. Cualquier discrepancia entre el hash esperado y el real indica un entorno headless o modificado. Un navegador headless sin GPU produce un hash diferente a un navegador real con aceleración hardware.
• Fuentes del sistema: Detección de fuentes instaladas mediante medición de dimensiones de texto. Un sistema que reporta tener Segoe UI pero no Tahoma es inconsistente con Windows real, donde ambas vienen preinstaladas.

Señales de comportamiento

• Eventos de mouse: mousemove, mousedown, mouseup, click. Akamai registra coordenadas, timestamps de alta resolución (performance.now()) y deltas entre eventos. Un mouse que se mueve en línea recta perfecta con intervalos exactos de 50ms es detectado como sintético. Los humanos producen curvas bezier con jitter natural.
• Eventos de scroll: scroll y wheel con coordenadas y timestamps. La ausencia total de scroll en una sesión de 5 minutos es una señal negativa fuerte.
• Eventos táctiles: touchstart, touchmove, touchend con force, radiusX/radiusY en dispositivos móviles. Akamai verifica que estos eventos existan cuando el User-Agent declara un dispositivo táctil.
• Eventos de teclado: keydown, keyup con timing entre teclas. La distribución de timing humano sigue una distribución log-normal; los bots tienden a tener distribuciones uniformes o constantes.

Señales de timing

• Tiempo de carga del script: Cuánto tarda sensor.js en ejecutarse. Un tiempo de 5ms indica un entorno sin renderizado real; 200-800ms es típico de un navegador real con JIT compilation.
• Tiempo entre eventos: Delta entre el primer mousemove y el primer click. Los humanos tardan 1-5 segundos; los bots suelen ser instantáneos o tener deltas de exactamente 0ms.
• Performance API: performance.timing y PerformanceObserver para validar que la navegación ocurrió de forma realista. Akamai verifica que navigationStart, domLoading y domComplete tengan valores coherentes entre sí.

Todas estas señales se serializan en una cadena codificada que constituye el sensor_data. El formato incluye delimitadores específicos, checksums y un timestamp. Un solo campo que no coincida con lo esperado para el User-Agent declarado invalida el _abck cookie inmediatamente. No hay tolerancia parcial —es un sistema de validación estricta, no probabilística.

Señales de protocolo 2026: X25519MLKEM768, JA4 y HTTP/2

En 2026, Akamai Bot Manager v2 incorpora señales de red que van más allá del navegador. Estas señales son particularmente importantes porque se capturan antes de que cualquier JavaScript se ejecute —son tu primera impresión ante el sistema.

X25519MLKEM768: el key share post-cuántico

Desde Chrome 131 (lanzado a finales de 2024), el navegador incluye por defecto el grupo X25519MLKEM768 en la extensión key_share de TLS 1.3, como parte de la migración a criptografía post-cuántica según el RFC 9180 (ML-KEM). Esto significa que el ClientHello de Chrome 131+ contiene un key share adicional que navegadores anteriores y librerías HTTP no incluyen.

Akamai verifica la presencia de este key share. Si tu User-Agent declara Chrome 131+ pero tu ClientHello no incluye X25519MLKEM768, el sistema marca la conexión como sospechosa antes de que se sirva ninguna página. Esto afecta a:

• Librerías HTTP como requests, httpx, urllib3 en Python que usan OpenSSL y no incluyen key shares post-cuánticos por defecto.
• Herramientas como curl compiladas con versiones antiguas de OpenSSL/BoringSSL sin soporte ML-KEM.
• Navegadores headless como Puppeteer/Playwright si no se configuran correctamente los flags de TLS o se usan versiones de Chromium anteriores a 131.

JA4: el fingerprint TLS que reemplaza a JA3

El fingerprint JA4 es el estándar de facto en 2026 para clasificar clientes TLS. A diferencia del JA3 original (que solo usaba cipher suites), JA4 incluye:

• Versión de TLS y número de extensiones en el ClientHello.
• Algoritmos de firma (signature_algorithms).
• Orden de cipher suites (preservado, no ordenado alfabéticamente).
• Presencia/ausencia de SNI.

Akamai mantiene una base de datos de fingerprints JA4 conocidos por navegador, versión y sistema operativo. Un JA4 de t13d1516h2_8daaf6152771_b186095e22b6 corresponde a Chrome 131 en Windows; cualquier desviación se flagged. El problema es que librerías HTTP generan fingerprints JA4 completamente diferentes a los de navegadores reales, incluso si usan la misma versión de TLS subyacente. OpenSSL 3.x produce un JA4 distinto a BoringSSL de Chrome.

HTTP/2 SETTINGS fingerprint

El frame SETTINGS de HTTP/2 es otra señal que Akamai utiliza. Cada cliente envía un frame SETTINGS con parámetros específicos:

• HEADER_TABLE_SIZE — Chrome usa 65536, Firefox usa 65536, pero nghttp2 (usado por muchas librerías) usa 4096.
• ENABLE_PUSH — presente o ausente según implementación.
• INITIAL_WINDOW_SIZE — Chrome usa 6291456, nghttp2 usa 65535.
• MAX_FRAME_SIZE — Chrome usa 16384, otros varían.
• MAX_CONCURRENT_STREAMS — 1000 en Chrome, ausente en algunos clientes.

El orden y los valores de estos parámetros son específicos por implementación. Akamai compara el fingerprint HTTP/2 con el User-Agent declarado. Si declaras Chrome pero tu SETTINGS frame coincide con nghttp2, la inconsistencia se registra como señal de automatización.

La conclusión es clara: tu stack de red debe coincidir exactamente con tu stack de navegador declarado. No basta con enviar el User-Agent correcto; cada capa del protocolo —TLS ClientHello, JA4, HTTP/2 SETTINGS— debe ser consistente con ese User-Agent.

Por qué los proxies residenciales son obligatorios

Incluso con un navegador perfecto, señales de sensor correctas y fingerprints TLS/HTTP/2 consistentes, Akamai puede bloquearte si tu IP tiene mala reputación. El sistema de akamai bot detection 2026 pondera la reputación de IP de forma significativa en el score total.

Akamai mantiene una base de datos de ASNs (Autonomous System Numbers) que clasifica por tipo. Puedes consultar la lista de ASNs conocidos en recursos como Wikipedia:

Tipo de proxy	Reputación IP	ASN pre-scored	Rotación	Costo aprox.	Recomendado para Akamai
Residencial	Alta	No (ISP real)	Por sesión o por request	$3-8/GB	Sí — obligatorio
Datacenter	Baja	Sí (AWS, GCP, OVH, etc.)	Por request	$0.5-2/GB	No — bloqueado casi siempre
Móvil	Muy alta	No (operador móvil)	Por sesión	$5-15/GB	Sí — óptimo pero costoso

Los ASNs de datacenter como AWS (AS14618), Google Cloud (AS15169), OVH (AS16276) o DigitalOcean (AS14061) están pre-scored como bots. No importa qué tan perfecto sea tu navegador —si tu IP pertenece a uno de estos ASNs, Akamai asigna un score de sospecha alto desde el primer paquete. Esto es un akamai bot manager bypass fallido antes de que el JavaScript se ejecute.

Los proxies residenciales, por el contrario, usan IPs asignadas por ISPs reales a hogares reales. Akamai no puede pre-scored estas IPs como bots sin generar falsos positivos masivos, lo que sería inaceptable para sus clientes. Esto hace que los proxies residenciales sean el único tipo viable para automatización contra Akamai Bot Manager v2.

Implementación práctica con ProxyHat

Para que tu automatización legítima pase Akamai Bot Manager v2, necesitas tres cosas: un navegador real (no headless básico), proxies residenciales, y consistencia entre todas las capas de red y navegador.

Paso 1: Configurar el proxy residencial

Usa ProxyHat con proxies residenciales a través del gateway HTTP en gate.proxyhat.com:8080:

# Proxy HTTP residencial con geo-targeting (EE.UU.)
http://user-country-US:PASSWORD@gate.proxyhat.com:8080

# Proxy HTTP residencial con ciudad específica (Berlín, Alemania)
http://user-country-DE-city-berlin:PASSWORD@gate.proxyhat.com:8080

# Sesión sticky para mantener la misma IP durante toda la sesión
http://user-session-abc123:PASSWORD@gate.proxyhat.com:8080

# SOCKS5 si necesitas protocolo SOCKS
socks5://user-country-US:PASSWORD@gate.proxyhat.com:1080

La sesión sticky es crítica para Akamai: necesitas mantener la misma IP durante toda la sesión para que _abck y ak_bmsc se mantengan válidos. Si rotas IPs en cada request, las cookies se invalidan porque la reputación de IP cambia y Akamai requiere regenerar el sensor_data.

Paso 2: Lanzar un navegador real con Playwright

No uses headless: true básico. Necesitas un navegador que genere señales reales:

from playwright.async_api import async_playwright

PROXY = "http://user-country-US-session-abc123:PASSWORD@gate.proxyhat.com:8080"

async def run_akamai_session():
    async with async_playwright() as p:
        browser = await p.chromium.launch(
            headless=False,  # Headless es detectable por Akamai
            proxy={"server": PROXY},
            args=[
                "--disable-blink-features=AutomationControlled",
                "--no-sandbox",
            ]
        )
        context = await browser.new_context(
            viewport={"width": 1920, "height": 1080},
            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"
            ),
            locale="en-US",
            timezone_id="America/New_York",
        )

        page = await context.new_page()

        # Navegar a la página protegida
        await page.goto("https://ejemplo-protegido.com",
                       wait_until="networkidle")

        # Esperar a que _abck se establezca
        cookies = await context.cookies()
        abck = next(
            (c for c in cookies if c["name"] == "_abck"), None
        )
        if abck and "~-1~" not in abck["value"]:
            print(f"_abck válida: {abck['value'][:50]}...")
        else:
            print("_abck no válida o pendiente")

        # Simular interacción humana antes de scraping
        await page.mouse.move(500, 300)
        await page.wait_for_timeout(500)
        await page.mouse.move(800, 400)
        await page.wait_for_timeout(300)
        await page.mouse.click(700, 350)

        await browser.close()

Paso 3: Verificar consistencia de fingerprints

Antes de automatizar a escala, verifica que tus fingerprints de red coincidan con tu navegador declarado:

# Verificar JA4 con curl a través del proxy ProxyHat
curl -v --proxy "http://user-country-US:PASSWORD@gate.proxyhat.com:8080" \
  -H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) ..." \
  "https://ejemplo-protegido.com" 2>&1 | grep -i "TLS\|JA4"

Si tu JA4 no coincide con Chrome 131, necesitas ajustar tu stack TLS. Considera usar curl-impersonate o una librería como curl_cffi en Python que emula los fingerprints TLS de navegadores reales, incluyendo el orden exacto de cipher suites y extensiones.

Paso 4: Mantener la sesión activa

Akamai puede re-validar _abck en cualquier momento mediante desafíos silenciosos. Para sesiones largas:

• Mantén el navegador abierto (no cierres y reabras el contexto).
• Genera eventos periódicos (mouse, scroll) cada 30-60 segundos para simular actividad.
• No cambies de IP a mitad de la sesión —usa user-session-xxx para mantener la misma IP residencial.
• Maneja los desafíos silenciosos: si detectas un POST asíncrono a un endpoint de Akamai, déjalo completar sin interceptarlo.

Errores comunes y casos límite

Error 1: Usar proxies datacenter "premium"

Algunos proveedores venden proxies datacenter como "indetectables". Esto es falso para Akamai —el ASN se verifica en tiempo real contra bases de datos actualizadas. Un IP de AWS pagado premium sigue siendo AWS. No hay cantidad de dinero que cambie el ASN.

Error 2: Headless sin modificaciones

Puppeteer/Playwright en modo headless expone señales como navigator.webdriver = true y window.chrome ausente. Akamai detecta esto en el primer sensor_data. Solución: usa headless=False con un display virtual (Xvfb en Linux) o usa herramientas como undetected-chromedriver que parchean estas señales.

Error 3: Inconsistencia entre TLS y User-Agent

Declarar Chrome 131 en el User-Agent pero enviar un ClientHello de OpenSSL 1.1.1 es el error más común. El JA4 no coincide y Akamai lo detecta inmediatamente. Usa librerías que emulen el stack TLS completo del navegador declarado, incluyendo X25519MLKEM768 si declaras Chrome 131+.

Error 4: Rotar IPs por request

Con Akamai, la rotación por request es contraproducente. Cada IP nueva requiere un _abck nuevo, lo que significa un nuevo desafío de sensor completo. Usa sesiones sticky de al menos 10-30 minutos por IP residencial.

Error 5: Ignorar el ak_bmsc

Muchos desarrolladores se centran en _abck y olvidan ak_bmsc. Si ak_bmsc no se mantiene consistente entre solicitudes, Akamai incrementa el score de sospecha incluso con un _abck válido. Ambas cookies deben viajar juntas en cada solicitud.

Conclusiones clave

Key Takeaways:

• Akamai Bot Manager v2 usa un sistema de scoring continuo que combina señales de navegador, red e IP. No hay un solo punto de falla —todas las capas deben ser consistentes.
• El sensor_data se ensambla desde cientos de señales de dispositivo, comportamiento y timing. Un solo campo incorrecto invalida el _abck.
• En 2026, las señales de protocolo (X25519MLKEM768, JA4, HTTP/2 SETTINGS) se verifican antes de que se ejecute JavaScript. Tu stack TLS debe coincidir exactamente con tu User-Agent.
• Los proxies residenciales son obligatorios. Los ASNs de datacenter están pre-scored como bots y no hay forma de evitar esto.
• Usa sesiones sticky para mantener _abck válido. La rotación por request es contraproducente con Akamai.
• Solo automatiza contra sitios donde tienes autorización. El CFAA y el RGPD aplican a la automatización no autorizada.

Para empezar con proxies residenciales que funcionan contra Akamai, consulta nuestra página de precios o revisa las ubicaciones disponibles. Si necesitas más contexto sobre casos de uso legítimos, visita nuestras guías de web scraping y SERP tracking. La documentación técnica completa de ProxyHat está en docs.proxyhat.com.