A análise profunda do Akamai Bot Manager v2 revela que a detecção de automação evoluiu muito além de listas simples de IP ou User-Agent. Em 2026, o Akamai combina telemetria de navegador em tempo real, fingerprints de protocolo criptográfico e reputação de ASN para atribuir uma pontuação de confiança contínua a cada sessão. Para engenheiros de scraping sênior e pesquisadores de segurança que precisam de automação legítima, entender cada camada desse stack é a diferença entre uma taxa de sucesso de 95%+ e bloqueios sistemáticos.
Aviso legal: Este artigo é destinado a pesquisa de segurança autorizada, monitoramento legítimo e automação em conformidade com os Termos de Serviço do site alvo. Técnicas de evasão de detecção de bots não devem ser usadas para fraude, evasão de pagamento ou acesso não autorizado. O Computer Fraud and Abuse Act (CFAA) nos EUA e o GDPR na União Europeia penalizam acesso não autorizado a sistemas computacionais. Sempre obtenha permissão explícita antes de automatizar interações com sites de terceiros.
Se você está construindo pipelines de web scraping ou sistemas de SERP tracking que enfrentam o Akamai, este guia técnico cobre cada sinal de detecção e como automação autorizada passa de forma limpa usando proxies residenciais de alta qualidade.
Análise Profunda do Akamai Bot Manager v2: O Stack de Sinais
O Akamai Bot Manager v2 opera em três camadas complementares: cookies de sessão, telemetria de comportamento do navegador e fingerprints de protocolo de rede. Nenhuma camada isolada é suficiente — todas precisam ser consistentes entre si para que a sessão receba uma pontuação de confiança aceitável.
Cookies _abck e ak_bmsc
O cookie _abck é o mecanismo central de sessão do Akamai Bot Manager. Ele é definido pelo servidor Akamai na primeira resposta HTTP e contém um token que codifica o estado de verificação da sessão. O valor do _abck cookie muda ao longo do ciclo de vida da sessão: inicialmente carrega um flag de challenge pendente, e após o sensor_data ser validado com sucesso, o servidor emite um novo _abck com um timestamp atualizado que indica sessão verificada.
O cookie ak_bmsc é complementar: funciona como um cookie de curta duração que rastreia a sessão entre requisições antes que o _abck seja totalmente validado. Ele tem tipicamente um TTL de 5 a 7 minutos e é renovado continuamente.
O problema crítico: se o sensor_data enviado contiver qualquer inconsistência — um campo de timing impossível, uma propriedade de tela que não corresponde ao User-Agent declarado, ou um padrão de eventos que parece sintético — o Akamai atualiza o _abck com um valor que parece válido, mas marca a sessão como suspeita server-side. O cliente não recebe um erro explícito; simplesmente encontra CAPTCHAs, desafios JavaScript ou HTTP 403 em requisições subsequentes.
O motor de telemetria sensor.js / bmak
O sensor.js (também referido como bmak no código ofuscado) é um script JavaScript pesado — tipicamente 15 a 25 KB minificado — que o Akamai injeta em cada página protegida. Este script coleta mais de 200 sinais do navegador em tempo real e os empacota em um payload criptografado chamado sensor_data.
O bmak é deliberadamente ofuscado e muda frequentemente. Versões diferentes do script podem coletar sinais diferentes, e a ordem dos campos no payload criptografado varia entre builds. Isso significa que ferramentas que tentam gerar sensor_data sintético sem executar o JavaScript real frequentemente quebram após atualizações do Akamai, que ocorrem a cada 2 a 4 semanas.
Pontuação contínua server-side
Ao contrário de sistemas de regra simples, o Akamai Bot Manager v2 mantém um score de confiança contínuo no servidor. Cada interação — cada requisição HTTP, cada envio de sensor_data — ajusta este score. Uma sessão pode começar com score neutro, receber um boost após validar sensor_data corretamente, e depois ser penalizada se o padrão de navegação for roboticamente consistente demais.
Segundo a documentação oficial do Akamai Bot Manager, o sistema categoriza tráfego em três buckets: humano, bot automatizado e bot suspeito. A categorização é probabilística, não binária, e o score é recalculado a cada interação.
Como o sensor_data Akamai é Montado
O sensor_data é o payload criptografado que o bmak envia de volta ao servidor Akamai. Entender sua composição é essencial para diagnosticar por que automação legítima às vezes falha.
Eventos de mouse, scroll e touch
O bmak registra coordenadas de mouse, timestamps de eventos, deltas de scroll e eventos de touch em dispositivos móveis. O payload inclui:
- Sequência de posições de mouse com timestamps em microssegundos
- Velocidade e aceleração calculadas entre eventos
- Eventos de scroll com direção e magnitude
- Eventos de touch (em mobile) com área de contato e pressão
O Akamai procura por padrões naturais: humanos têm jitter, curvas não-lineares e intervalos irregulares entre eventos. Movimentos perfeitamente lineares ou intervalos exatamente regulares são flagged imediatamente. Um movimento de mouse que vai de (0,0) a (500,300) em uma linha reta perfeita com intervalos de exatamente 16ms é trivialmente detectável.
Propriedades de tela e GPU
O sensor_data inclui propriedades como screen.width, screen.height, window.devicePixelRatio, e a string navigator.userAgent. Também coleta informações de GPU via WebGLRenderingContext.getParameter() — especificamente o vendor e renderer strings, que revelam o hardware de vídeo.
Se o User-Agent declara Windows mas o WebGL renderer retorna Apple M2 Pro, o Akamai invalida a sessão instantaneamente. Esta é uma das razões pelas quais automação headless sem configuração cuidadosa falha.
Timing e relógio do navegador
O bmak mede performance.now(), Date.now() e diferenças entre eles. Também mede o tempo de execução de operações matemáticas específicas para detectar VMs e sandboxes. Se o performance.now() tiver resolução anormalmente baixa (comum em alguns ambientes headless), ou se os tempos de execução forem consistentemente mais rápidos que o esperado para o hardware declarado, o score é penalizado.
Uma única inconsistência em qualquer um destes mais de 200 campos é suficiente para invalidar o _abck. Não há parcialmente correto — ou todos os sinais são consistentes, ou a sessão é marcada.
Sinais de Protocolo 2026: X25519MLKEM768, JA4 e HTTP/2
Para akamai bot detection em 2026, sinais de protocolo de rede são verificados antes mesmo de qualquer JavaScript executar. O Akamai Bot Manager v2 incorpora fingerprints que vão muito além do User-Agent, e estes são particularmente desafiadores porque operam no nível do TLS e HTTP/2.
X25519MLKEM768 e o handshake pós-quântico
Desde o Chrome 131 (lançado em novembro de 2024), o Google habilitou por padrão o key share híbrido pós-quântico X25519MLKEM768 no handshake TLS 1.3. Este algoritmo combina X25519 (ECDH clássico) com ML-KEM-768 (Module-Lattice-Based Key Encapsulation Mechanism, padronizado pelo NIST como FIPS 203).
O impacto para detecção de bots é direto: o ClientHello de um Chrome 131+ real inclui o key share x25519_mlkem768 na extensão key_share. Bibliotecas HTTP que não suportam pós-quântico — como versões mais antigas de requests, httpx ou urllib3 — produzem um ClientHello que parece ser de um navegador antigo ou de uma ferramenta não-navegador, mesmo que o User-Agent diga Chrome 131.
O IETF está padronizando este mecanismo no draft-ietf-tls-hybrid-design, e a adoção está se tornando universal em navegadores modernos. O Akamai verifica se o key share no ClientHello é consistente com a versão do navegador declarada no User-Agent.
JA4 e HTTP/2 SETTINGS
O fingerprint JA4 é a evolução do JA3 e captura a ordenação de cipher suites, extensões TLS e curvas suportadas no ClientHello. Diferente do JA3, o JA4 é mais granular e inclui o ALPN (Application-Layer Protocol Negotiation), permitindo distinguir HTTP/1.1 de HTTP/2 e HTTP/3.
Além do JA4, o Akamai inspeciona os HTTP/2 SETTINGS frames. Cada cliente HTTP/2 envia um frame SETTINGS com parâmetros como HEADER_TABLE_SIZE, ENABLE_PUSH, MAX_CONCURRENT_STREAMS, INITIAL_WINDOW_SIZE e MAX_FRAME_SIZE. A ordem e os valores destes parâmetros são específicos por implementação: Chrome, Firefox, Safari e bibliotecas como okhttp ou hyper têm assinaturas distintas.
Se o User-Agent declara Chrome 131 mas o JA4 e os HTTP/2 SETTINGS correspondem a Python/httpcore, o Akamai marca a sessão como bot antes mesmo de receber o sensor_data. Esta é uma das razões pelas quais bibliotecas HTTP puras frequentemente falham contra o Akamai, mesmo com headers perfeitos.
Por Que Proxies Residenciais São Obrigatórios
O Akamai Bot Manager v2 pesa fortemente a reputação do IP de origem. Não é apenas uma lista de bloqueio — é um sistema de scoring que considera múltiplas dimensões:
- ASN (Autonomous System Number): Datacenter ASNs (como AWS AS14618, OVH AS16276, DigitalOcean AS14061) recebem score inicial de bot por padrão.
- Geolocalização vs. idioma do navegador: Se o IP está em Frankfurt mas o
Accept-Languageéja-JP, o score é penalizado. - Histórico do IP: IPs que fizeram volume anormal de requisições em janelas de 24 horas recebem score reduzido.
- Tipo de conexão: IPs residenciais (ISP) recebem score inicial mais alto que IPs de hosting.
Isso significa que mesmo com sensor_data perfeito e JA4 correto, um IP de datacenter ainda pode resultar em score de bot. O akamai bot manager bypass eficaz requer que o IP de origem tenha reputação residencial genuína.
| Tipo de Proxy | Score Inicial Akamai | Risco de Bloqueio | Custo por GB | Ideal para Akamai? |
|---|---|---|---|---|
| Datacenter | Bot (pré-classificado) | 90%+ | $0.50–$1.50 | Não |
| Residencial | Humano (potencial) | 5–15% | $3.00–$8.00 | Sim |
| Mobile (4G/5G) | Humano (alto) | 2–8% | $5.00–$12.00 | Sim (premium) |
Proxies residenciais rotativos fornecem IPs de ISPs reais (Comcast, AT&T, Vodafone, etc.), que o Akamai classifica como tráfego humano por padrão. Confira os planos e preços da ProxyHat para opções de proxies residenciais com rotação automática.
Implementação Prática com ProxyHat
Para que o sensor_data e o _abck sejam mint corretamente, você precisa de um navegador real (ou um contexto de navegador suficientemente instrumentado) que passe por todos os checks do bmak, combinado com um proxy residencial que forneça um IP de boa reputação.
Passo 1: Configurar o proxy residencial
O gateway da ProxyHat aceita flags de geo-targeting e sessão no próprio username. Para tráfego residencial nos EUA:
# HTTP proxy — residencial, geo US
curl -x http://user-country-US:pass@gate.proxyhat.com:8080 \
https://example.com/Para sessões sticky (mesmo IP por sessão), adicione um identificador de sessão:
# Sessão sticky — mesmo IP residencial
curl -x http://user-country-US-session-mysess123:pass@gate.proxyhat.com:8080 \
https://example.com/Para SOCKS5, use a porta 1080:
# SOCKS5 proxy residencial
curl -x socks5://user-country-US:pass@gate.proxyhat.com:1080 \
https://example.com/Passo 2: Lançar um contexto de navegador stealth
Usando Playwright com Python, o exemplo abaixo configura um contexto Chromium com proxy residencial ProxyHat e parâmetros que permitem que o sensor.js do Akamai execute naturalmente:
from playwright.sync_api import sync_playwright
PROXY = {
"server": "http://gate.proxyhat.com:8080",
"username": "user-country-US",
"password": "pass",
}
with sync_playwright() as p:
browser = p.chromium.launch(
headless=False,
args=[
"--disable-blink-features=AutomationControlled",
"--no-sandbox",
],
)
context = browser.new_context(
proxy=PROXY,
viewport={"width": 1920, "height": 1080},
locale="en-US",
timezone_id="America/New_York",
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"
),
)
# Sobrescrever navigator.webdriver
context.add_init_script(
"Object.defineProperty(navigator, 'webdriver',"
"{ get: () => undefined })"
)
page = context.new_page()
page.goto("https://example-protected.com/")
# Esperar o sensor.js carregar e o _abck ser validado
page.wait_for_timeout(3000)
# Verificar se _abck foi mintado corretamente
cookies = context.cookies()
abck = next(
(c for c in cookies if c["name"] == "_abck"), None
)
if abck:
print(f"_abck value: {abck['value'][:40]}...")
else:
print("_abck nao encontrado — possivel bloqueio")
browser.close()Passo 3: Rotação de IP entre sessões
Para scraping em volume, alterne o identificador de sessão a cada N requisições para obter um novo IP residencial:
import uuid
import requests
GATEWAY = "gate.proxyhat.com:8080"
def get_proxy(session_id=None, country="US"):
sid = session_id or str(uuid.uuid4())[:8]
auth = f"user-country-{country}-session-{sid}:pass"
return {
"http": f"http://{auth}@{GATEWAY}",
"https": f"http://{auth}@{GATEWAY}",
}
# Nova sessao = novo IP residencial
proxies = get_proxy()
resp = requests.get("https://example.com/", proxies=proxies)
print(f"Status: {resp.status_code}")Consulte a documentação da ProxyHat para detalhes completos sobre parâmetros de geo-targeting e rotação. Você também pode explorar a lista de localizações disponíveis para segmentação por país e cidade.
Erros Comuns e Casos Limite
1. User-Agent inconsistente com JA4
O erro mais comum: usar uma biblioteca HTTP (como requests ou httpx) com um User-Agent de Chrome, mas o JA4 revela Python/urllib3. O Akamai detecta a inconsistência no handshake TLS, antes mesmo de processar headers HTTP.
Solução: Use um navegador real (Playwright, Puppeteer) ou uma biblioteca que mantenha fingerprints TLS consistentes com o User-Agent, como cycletls ou utls em Go.
2. sensor_data gerado sinteticamente
Ferramentas que tentam gerar sensor_data sem executar o bmak real frequentemente falham após atualizações do Akamai. O script muda a cada 2 a 4 semanas, e campos são adicionados ou reordenados.
Solução: Sempre execute o JavaScript real em um contexto de navegador. Não tente forjar sensor_data.
3. Concorrência excessiva no mesmo IP
Mesmo com proxy residencial, 100+ requisições simultâneas do mesmo IP em poucos segundos dispara o sistema de rate limiting do Akamai. O score de confiança cai rapidamente.
Solução: Limite a 3 a 5 requisições concorrentes por IP. Use rotação de sessão para distribuir carga entre múltiplos IPs residenciais.
4. Resolução de tela impossível
Declarar screen.width = 1920 mas rodar em um container com DISPLAY virtual de 1024x768 cria uma inconsistência que o bmak detecta via window.innerWidth vs screen.width.
Solução: Garanta que viewport, window.screen e devicePixelRatio sejam todos consistentes com o ambiente declarado.
5. Fuso horário inconsistente com geolocalização do IP
Se o proxy residencial está em Nova York (timezone America/New_York) mas o navegador está configurado com timezone Asia/Tokyo, o bmak detecta a inconsistência via Intl.DateTimeFormat().resolvedOptions().timeZone.
Solução: Sempre configure o timezone_id do contexto do navegador para corresponder à localização geográfica do proxy.
Principais Takeaways
- O Akamai Bot Manager v2 usa mais de 200 sinais combinados — não existe bypass de camada única.
- O
_abcké mintado apenas quando osensor_dataé 100% consistente; uma única inconsistência invalida a sessão. - Em 2026, sinais de protocolo como X25519MLKEM768, JA4 e HTTP/2 SETTINGS são verificados antes do JavaScript executar.
- Proxies residenciais são obrigatórios — ASNs de datacenter são pré-classificados como bot pelo Akamai.
- Use um navegador real (Playwright/Puppeteer) com proxy residencial ProxyHat para que o
bmakexecute naturalmente. - Automação deve ser legítima e autorizada — pesquisa de segurança e monitoramento em conformidade com ToS, CFAA e GDPR.
Perguntas Frequentes
O que é a análise profunda do Akamai Bot Manager v2?
É o estudo técnico detalhado de como o Akamai Bot Manager v2 detecta automação. O sistema combina cookies _abck, telemetria do sensor.js (bmak), fingerprints de protocolo TLS como JA4 e X25519MLKEM768, e reputação de IP para atribuir um score de confiança contínuo a cada sessão. Compreender cada camada é essencial para construir automação legítima que passe sem bloqueios.
Por que o Akamai Bot Manager v2 importa para usuários de proxy?
Porque o Akamai pesa a reputação do IP de origem como um dos sinais mais importantes. IPs de datacenter são pré-classificados como bot, independentemente de quão perfeito seja o sensor_data. Proxies residenciais fornecem IPs de ISPs reais que recebem score inicial de humano, tornando-os essenciais para qualquer automação que enfrente sites protegidos pelo Akamai.
Qual tipo de proxy funciona melhor para o Akamai Bot Manager v2?
Proxies residenciais são o padrão mínimo. Eles fornecem IPs de ISPs reais como Comcast e Vodafone, que o Akamai classifica como tráfego humano. Proxies mobile 4G/5G oferecem score ainda mais alto, mas a um custo maior. Proxies de datacenter não funcionam contra o Akamai Bot Manager v2 porque seus ASNs são pré-classificados como bot.
Como evitar bloqueios ao implementar automação contra o Akamai Bot Manager v2?
Use um navegador real com proxies residenciais, garanta que o JA4 e HTTP/2 SETTINGS correspondam ao User-Agent declarado, configure timezone e viewport consistentes com a geolocalização do proxy, limite a 3 a 5 requisições concorrentes por IP, e nunca tente forjar sensor_data sinteticamente — sempre deixe o bmak executar no navegador real.
