Uma análise profunda do Akamai Bot Manager v2 é essencial para qualquer engenheiro de scraping sênior ou pesquisador de segurança que precisa de automação web confiável em 2026. O Akamai Bot Manager v2 não é um simples WAF que bloqueia por User-Agent — é um sistema de scoring contínuo que combina telemetria comportamental em JavaScript, fingerprinting de protocolo TLS, fingerprinting HTTP/2 e reputação de IP em um único score do lado do servidor. Este artigo cobre como cada camada funciona e como automação legítima e autorizada passa de forma limpa.
Aviso legal: Este conteúdo é para acesso autorizado — monitoramento legítimo, pesquisa de segurança com permissão explícita, testes de penetração contratados. Acessar sistemas sem autorização pode violar o CFAA nos EUA, o GDPR na Europa e leis equivalentes em outras jurisdições. Tudo aqui assume permissão explícita ou acesso a conteúdo público dentro dos termos de serviço.
Análise profunda do Akamai Bot Manager v2: o que é e por que importa em 2026
O Akamai Bot Manager é um dos sistemas anti-bot mais implantados na web, protegendo aproximadamente 30% do tráfego de e-commerce entre as empresas da Fortune 500. A versão 2, que se tornou padrão em 2024-2025, introduziu scoring contínuo do lado do servidor em vez de decisões binárias de bloqueio/liberação. Em vez de simplesmente retornar HTTP 403, o sistema agora atribui uma pontuação de confiança entre 0 e 100 que determina se o visitante recebe CAPTCHA, challenge JavaScript silencioso, ou acesso irrestrito.
Para profissionais de automação, isso significa que um akamai bot manager bypass não é mais uma questão de spoofar um cabeçalho ou resolver um challenge único. Você precisa manter consistência entre dezenas de sinais simultaneamente — TLS, HTTP/2, JavaScript, comportamento e IP — durante toda a sessão. Uma única inconsistência entre qualquer camada pode derrubar o score e invalidar o cookie _abck acumulado.
A pilha de sinais: _abck, ak_bmsc e o motor sensor.js/bmak
A detecção do Akamai Bot Manager v2 opera em quatro camadas que se reforçam mutuamente. Entender cada uma é pré-requisito para qualquer estratégia de automação que precise passar limpo.
O cookie _abck
O _abck cookie é o pilar da detecção Akamai. Ele é definido como um cookie HTTP-only na primeira resposta do servidor protegido, antes mesmo do JavaScript carregar. O valor contém dados codificados que o servidor usa para rastrear o estado de confiança da sessão. Inicialmente, o cookie está em estado "não resolvido" — o servidor aceita a requisição mas marca a sessão para challenge.
Quando o motor de telemetria JavaScript executa no cliente e envia o sensor_data akamai de volta, o servidor valida a resposta e atualiza o _abck para um estado "resolvido". A partir daí, requisições subsequentes com o cookie resolvido passam sem challenge adicional — desde que o score de IP e comportamento permaneça alto. Se o sensor_data contiver uma inconsistência, o _abck permanece não resolvido e o servidor pode silenciosamente degradar a experiência (preços diferentes, conteúdo incompleto) sem retornar erro explícito.
O cookie ak_bmsc
O ak_bmsc é um cookie de sessão de vida mais curta (tipicamente 1-7 dias) que complementa o _abck. Ele armazena metadados de sessão e tokens de challenge que o sensor.js referencia durante a montagem do sensor_data. Diferente do _abck, o ak_bmsc pode ser reemitido durante a sessão se o servidor detectar anomalias comportamentais.
O motor de telemetria sensor.js (bmak)
O Akamai serve um arquivo JavaScript ofuscado — tradicionalmente chamado de sensor.js — que define um objeto global bmak. Este script é responsável por coletar mais de 100 sinais do ambiente do navegador e codificá-los em uma string base64 chamada sensor_data. O script é atualizado frequentemente (às vezes semanalmente) para mudar a ordem dos campos, adicionar novos sinais e alterar a lógica de ofuscação.
O sensor.js coleta sinais em três categorias:
- Estáticos: propriedades do navegador que não mudam durante a sessão —
navigator.userAgent,navigator.platform,screen.width,screen.height,navigator.hardwareConcurrency,navigator.deviceMemory, string do renderer WebGL, lista de fontes instaladas,AudioContextfingerprint. - Comportamentais: eventos de mouse, teclado, scroll e touch capturados em tempo real — velocidade do mouse, aceleração, curvatura da trajetória, intervalos entre keystrokes, padrões de scroll, mudanças de direção.
- Temporais: timestamps de eventos, precisão de
performance.now(), tempo entre carregamento da página e primeiro evento, delta entreDate.now()eperformance.timing.
Como o sensor_data é montado e por que um único campo invalida _abck
O sensor_data akamai é uma string codificada que contém todos os sinais coletados pelo sensor.js, concatenados em uma ordem específica que muda entre versões do script. O servidor Akamai decodifica essa string e valida cada campo contra um modelo de consistência. A validação não verifica apenas se cada campo é plausível isoladamente — ela verifica se os campos são coerentes entre si.
Por exemplo, se o User-Agent afirma ser Chrome 131 no Windows 10, o servidor verifica:
- O renderer WebGL reporta um GPU compatível com Windows (ex: "ANGLE (NVIDIA, NVIDIA GeForce RTX 3060)" ou "ANGLE (Intel, Intel(R) UHD Graphics 630)") — não "Apple M2" ou "Mali-G78".
navigator.platformretorna "Win32" — não "Linux x86_64" ou "MacIntel".- A lista de fontes inclui fontes padrão do Windows (Arial, Calibri, Segoe UI) — não fontes exclusivas de macOS (San Francisco, Helvetica Neue).
navigator.hardwareConcurrencyé um valor plausível (4, 8, 12, 16) — não 1 ou 0.- O timezone do sistema (
Intl.DateTimeFormat().resolvedOptions().timeZone) é coerente com o IP geolocalizado.
Se qualquer campo for inconsistente — por exemplo, User-Agent Windows mas renderer WebGL reportando "Apple GPU" — o servidor invalida o _abck instantaneamente. Não há segunda chance na mesma sessão. O score cai para próximo de zero e requisições subsequentes recebem challenge ou bloqueio silencioso.
É por isso que ferramentas de automação que apenas spoofam o User-Agent mas não controlam o WebGL, as fontes, ou o navigator.platform falham consistentemente contra o Akamai Bot Manager v2. A consistência interna é mais importante que qualquer campo individual.
Sinais de protocolo em 2026: X25519MLKEM768, JA4 e HTTP/2 SETTINGS
Em 2026, o akamai bot detection 2026 vai além do JavaScript. O servidor Akamai inspeciona a camada de transporte e a camada de aplicação antes mesmo de o JavaScript carregar. Três sinais de protocolo se tornaram críticos:
X25519MLKEM768: o key share pós-quântico
A partir do Chrome 131+, o TLS 1.3 inclui por padrão o key share X25519MLKEM768, um híbrido de Diffie-Hellman clássico (X25519) e encapsulamento de chave pós-quântico (ML-KEM 768, anteriormente conhecido como Kyber768). Isso adiciona aproximadamente 1,184 bytes ao ClientHello. Se o seu User-Agent afirma ser Chrome 131+ mas o ClientHello não inclui o key share X25519MLKEM768, o Akamai detecta a inconsistência imediatamente — antes mesmo de enviar a página HTML.
Para automação com Playwright ou Puppeteer usando Chromium real, isso não é problema: o navegador envia o key share corretamente. Para bibliotecas HTTP que montam o ClientHello manualmente (como algumas implementações de TLS em Python/Go), é necessário garantir suporte a X25519MLKEM768 ou o fingerprint TLS não corresponderá ao User-Agent.
JA4: o fingerprint TLS estruturado
O JA4 é um método de fingerprinting TLS criado pela FoxIO que hashia de forma estruturada as cipher suites, extensões e algoritmos de assinatura do ClientHello. Diferente do JA3 (que concatenava tudo em uma string MD5), o JA4 usa um formato segmentado que permite comparar campos individuais.
O JA4 de um Chrome 131 real no Windows tem um valor previsível e estável. Se o seu cliente HTTP envia um JA4 que corresponde a Python requests ou urllib3 — que usa a stack TLS do OpenSSL com cipher suites em ordem diferente — o Akamai sabe que não é um navegador real, independentemente do User-Agent.
HTTP/2 SETTINGS fingerprint
Além do TLS, o Akamai inspeciona o frame SETTINGS do HTTP/2, que cada cliente envia no início da conexão. Os valores de HEADER_TABLE_SIZE, ENABLE_PUSH, MAX_CONCURRENT_STREAMS, INITIAL_WINDOW_SIZE e MAX_FRAME_SIZE diferem entre navegadores. Chrome, Firefox e Safari enviam conjuntos distintos de parâmetros SETTINGS. Bibliotecas como hyper (Python), http2 (Go) e clientes HTTP de baixo nível enviam valores completamente diferentes.
O resultado: o User-Agent, o JA4 e o HTTP/2 SETTINGS devem formar um conjunto coerente. Se qualquer um dos três não corresponder aos outros dois, o score de confiança cai antes mesmo de o sensor.js carregar.
Por que proxies residenciais são obrigatórios
O Akamai Bot Manager v2 pondera a reputação de IP de forma significativa no score final. Endereços IP originados de ASNs de datacenter — AWS (AS14618), Google Cloud (AS15169), Azure (AS8075), OVH (AS16276), DigitalOcean (AS14061) — recebem um score inicial próximo de zero, independentemente de quão perfeito seja o fingerprint do navegador. O sistema assume que tráfego de datacenter é automação até prova em contrário.
Proxies residenciais, por outro lado, usam IPs atribuídos por ISPs reais a consumidores reais. O ASN é o de uma operadora de telecom (ex: Comcast AS7922, AT&T AS7018, Vodafone AS3209). O score inicial desses IPs é neutro ou positivo, dando ao sensor.js a oportunidade de resolver o _abck normalmente.
| Característica | Residencial | Móvel | Datacenter |
|---|---|---|---|
| Reputação de IP no Akamai | Neutro/positivo | Muito positivo | Pre-scored como bot |
| Score inicial típico | 50-70 | 70-85 | 5-15 |
| Latência média | 200-800ms | 300-1200ms | 50-150ms |
| Sessões concorrentes | 100+ | 50+ | 1000+ |
| Custo relativo | Médio | Alto | Baixo |
| Recomendado para Akamai | Sim | Sim | Não |
Proxies móveis têm o score inicial mais alto porque o Akamai trata tráfego de operadoras móveis (T-Mobile, Verizon Wireless, Vodafone) como tráfego de dispositivos reais por padrão. No entanto, a latência mais alta e o custo elevado os tornam impraticáveis para volume alto. Para a maioria dos casos de uso, proxies residenciais com sessões sticky oferecem o melhor equilíbrio entre confiança e performance.
Abordagem prática com ProxyHat: automação legítima que passa limpo
A estratégia correta para passar pelo Akamai Bot Manager v2 não é "burlar" o sensor.js — é deixar o sensor.js executar naturalmente em um navegador real, com um IP residencial, e coletar o _abck resolvido. Em outras palavras: não tente forjar o sensor_data; deixe o motor do Akamai gerá-lo organicamente.
Para isso, usamos web scraping com Playwright (Chromium real) roteado através de proxies residenciais ProxyHat. O navegador executa o JavaScript do Akamai nativamente, gerando um sensor_data perfeitamente consistente com o ambiente.
Passo 1: Configurar o proxy residencial
# HTTP proxy via ProxyHat (residencial, geo-targeting EUA)
export HTTP_PROXY="http://user-country-US:sua_senha@gate.proxyhat.com:8080"
export HTTPS_PROXY="http://user-country-US:sua_senha@gate.proxyhat.com:8080"
# SOCKS5 (quando necessário para conexões UDP/WebRTC)
export ALL_PROXY="socks5://user-country-US:sua_senha@gate.proxyhat.com:1080"Passo 2: Playwright com Chromium real e proxy residencial
from playwright.sync_api import sync_playwright
proxy_config = {
"server": "http://gate.proxyhat.com:8080",
"username": "user-country-US",
"password": "sua_senha"
}
with sync_playwright() as p:
browser = p.chromium.launch(
headless=False,
proxy=proxy_config,
args=["--disable-blink-features=AutomationControlled"]
)
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"
)
page = context.new_page()
page.goto("https://exemplo-protegido-akamai.com")
# Aguardar sensor.js executar e resolver _abck
page.wait_for_timeout(5000)
# Verificar se _abck foi resolvido
cookies = context.cookies()
abck = next((c for c in cookies if c["name"] == "_abck"), None)
if abck:
print(f"_abck value: {abck['value'][:40]}...")
# Continuar scraping com o _abck resolvido
page.goto("https://exemplo-protegido-akamai.com/produtos")
content = page.content()
context.close()
browser.close()Passo 3: Manter sessão sticky para preservar o _abck
O _abck é vinculado ao IP e à sessão do navegador. Se o IP mudar a cada requisição (rotação per-request), o servidor Akamai vê o mesmo _abck sendo usado de IPs diferentes e invalida a sessão. Use sessões sticky para manter o mesmo IP durante toda a sessão de scraping:
# Sessão sticky: mesmo IP por 10-30 minutos
proxy_config = {
"server": "http://gate.proxyhat.com:8080",
"username": "user-country-US-session-minha-sessao-01",
"password": "sua_senha"
}Com a flag session-minha-sessao-01 no username, o ProxyHat mantém o mesmo IP residencial para todas as requisições dessa sessão. Quando precisar rotar (ex: após 50-100 requisições para evitar rate limiting), basta mudar o identificador da sessão.
Passo 4: Rotação de sessões para volume alto
import requests
import uuid
def scrape_with_fresh_session(url):
session_id = str(uuid.uuid4())[:8]
proxy = {
"http": f"http://user-country-US-session-{session_id}:sua_senha@gate.proxyhat.com:8080",
"https": f"http://user-country-US-session-{session_id}:sua_senha@gate.proxyhat.com:8080"
}
response = requests.get(url, proxies=proxy, timeout=30)
return responsePara volume alto, combine Playwright (para resolver _abck inicial) com requests (para requisições subsequentes reutilizando os cookies). Exporte os cookies do contexto Playwright e injete na sessão requests. Veja a documentação em docs.proxyhat.com para detalhes sobre gerenciamento de sessões.
Onde isso é apropriado — e onde não é
As técnicas descritas aqui são apropriadas para:
- Monitoramento autorizado: verificar seus próprios sites, preços de concorrentes em conteúdo público, ou dados de mercado com permissão.
- Pesquisa de segurança: testes de penetração contratados, auditoria de configurações anti-bot em sistemas que você protege.
- QA e teste de automação: validar fluxos de compra, cadastro e navegação em ambientes de staging protegidos por Akamai.
- Coleta de dados públicos: SERP tracking, agregação de dados públicos de governo, dados meteorológicos, resultados esportivos — desde que dentro dos termos de serviço e limites de rate.
Não é apropriado para: fraude de ingressos/sneakers, criação de contas falsas em massa, evasão de bans, scraping de dados pessoais sem consentimento (violação do GDPR/CCPA), ou qualquer atividade que viole os termos de serviço do site alvo. O fato de tecnicamente poder passar pelo Akamai não torna o acesso legítimo.
Erros comuns e casos extremos
1. Headless detection
Chromium em modo headless (headless=True) expõe sinais detectáveis: navigator.webdriver é true, a propriedade chrome não existe no objeto navigator, e o renderer WebGL reporta "SwiftShader" em vez de um GPU real. O Akamai Bot Manager v2 verifica esses sinais no sensor_data. Use headless=False com um display virtual (Xvfb) ou ferramentas como playwright-stealth.
2. Inconsistência de timezone
O Intl.DateTimeFormat().resolvedOptions().timeZone deve corresponder ao IP geolocalizado. Se o proxy está nos EUA mas o timezone do navegador é "Europe/London", o Akamai detecta a inconsistência. Configure timezone_id no contexto do Playwright para corresponder ao país do proxy.
3. Rotação de IP sem renovar _abck
Trocar o IP (mudando a sessão do proxy) sem limpar os cookies e resolver um novo _abck é o erro mais comum. O servidor vê um _abck resolvido para o IP A sendo reutilizado do IP B e invalida a sessão. Ao rotar IPs, sempre inicie uma nova sessão de navegador com cookies limpos.
4. Confiar em soluções "akamai bypass" prontas
Ferramentas que prometem akamai bot manager bypass gerando sensor_data sintético frequentemente quebram em dias ou horas, porque o Akamai atualiza o sensor.js regularmente. A abordagem robusta é sempre usar um navegador real com proxy residencial — o sensor.js gera o sensor_data correto naturalmente, sem necessidade de engenharia reversa.
5. Não respeitar rate limits
Mesmo com _abck resolvido e IP residencial, requisições em volume excessivo (ex: 500 requisições/min do mesmo IP) disparam detecção comportamental. Mantenha taxas plausíveis para navegação humana (10-30 requisições/min por IP) e rotacione sessões quando precisar de mais throughput.
Pontos-chave
- O Akamai Bot Manager v2 usa scoring contínuo (0-100), não bloqueio binário. O objetivo é manter o score alto, não apenas evitar 403.
- O cookie _abck só é resolvido quando o sensor_data é internamente consistente — todos os campos (WebGL, fontes, platform, timezone) devem coerir com o User-Agent.
- Em 2026, o fingerprint TLS (JA4 + X25519MLKEM768) e o HTTP/2 SETTINGS devem corresponder ao navegador claimado no User-Agent. Chrome 131+ inclui X25519MLKEM768 por padrão.
- Proxies datacenter são pre-scored como bot pelo Akamai. Proxies residenciais (e móveis) são obrigatórios para qualquer chance de passar limpo.
- A estratégia correta é usar um navegador real (Playwright/Chromium) com proxy residencial ProxyHat e deixar o sensor.js executar nativamente — não forjar sensor_data.
- Use sessões sticky (
user-session-XYZ) para preservar o _abck durante a sessão de scraping e rotacione sessões (não apenas IPs) para volume alto. - Tudo aqui pressupõe acesso autorizado. Violações do CFAA/GDPR são responsabilidade do usuário.
Pronto para implementar? Explore os locais de proxy disponíveis do ProxyHat, confira nossa página de preços, ou leia mais sobre casos de uso de web scraping com proxies residenciais.
