Akamai Bot Manager v2: глубокий разбор системы обнаружения ботов в 2026

Akamai Bot Manager v2 глубокий разбор: как система оценивает автоматизацию в 2026

Если вы — инженер, отвечающий за легитимный мониторинг цен, сбор данных для исследования безопасности или автоматизированный QA, вы наверняка сталкивались с Akamai Bot Manager v2. Это одна из самых сложных систем обнаружения ботов на рынке, и в 2026 году она стала ещё агрессивнее. В этом глубоком разборе мы детально рассмотрим, как именно Akamai оценивает автоматизацию, какие сигналы собирает, и как настроить легитимную инфраструктуру так, чтобы она проходила проверки чисто.

Правовая оговорка: данный материал предназначен для авторизованного тестирования, исследования безопасности и легитимной автоматизации. Неправомерный обход систем защиты может нарушать Computer Fraud and Abuse Act (CFAA) и GDPR. Всегда получайте явное разрешение от владельца целевого ресурса и соблюдайте robots.txt и условия обслуживания.

Ключевая идея: Akamai Bot Manager v2 глубокий разбор показывает, что система не проверяет один параметр — она строит непрерывный серверный trust score на основе десятков сигналов. Если хоть один сигнал не совпадает с заявленным User-Agent, cookie _abck инвалидируется мгновенно. Именно поэтому обход Akamai Bot Manager в 2026 году — это не про обход одного фильтра, а о создании корректного, полностью согласованного браузерного профиля.

Стек сигналов: cookies _abck, ak_bmsc и телеметрический движок sensor.js

Akamai Bot Manager v2 использует многоуровневую архитектуру обнаружения. На верхнем уровне работают два ключевых cookie: _abck и ak_bmsc. Понимание того, как они взаимодействуют, — основа любой легитимной автоматизации.

Cookie ak_bmsc: первичный отпечаток

ak_bmsc — это cookie, которая устанавливается при первом запросе к защищённому ресурсу. Она содержит базовый отпечаток клиента: IP-адрес, User-Agent, поддерживаемые кодировки и заголовки. Akamai использует ak_bmsc для первичной классификации ещё до выполнения JavaScript. Если ваш IP принадлежит дата-центру с плохой репутацией, вы можете получить блокировку на этом этапе, даже до загрузки sensor.js.

Cookie _abck: основной механизм доверия

_abck — это зашифрованный токен доверия, который Akamai проверяет на каждом последующем запросе. Он содержит:

• Серверный trust score (0–1, где значения ниже определённого порога помечаются как бот)
• Хэш собранного sensor_data
• Временную метку создания
• Идентификатор сессии и привязку к IP

Важно: _abck — это не статичный токен. Akamai периодически переоценивает trust score на основе поведения пользователя. Если вы получили валидный _abck, но затем совершили запрос с несогласованным TLS-отпечатком или с другого IP, cookie будет помечена как подозрительная.

sensor.js и движок bmak

JavaScript-модуль, известный как sensor.js или bmak, — это ядро клиентской телеметрии Akamai. Он загружается как обфусцированный скрипт и собирает данные о браузере и устройстве. Движок bmak отвечает за:

• Сбор событий мыши, клавиатуры, прокрутки и touch
• Чтение свойств экрана и GPU через WebGL
• Вычисление временных характеристик (timing)
• Формирование payload sensor_data
• Отправку payload на сервер Akamai для валидации

Скрипт обфусцирован и регулярно обновляется — Akamai меняет структуру каждые 2–4 недели. Это означает, что ручной реверс-инжиниринг sensor_data — это игра в кошки-мышки, которую Akamai всегда выигрывает. Гораздо эффективнее использовать реальный браузерный движок, который генерирует sensor_data естественным образом.

Как собирается sensor_data и почему одно несовпадение ломает _abck

Payload sensor_data — это основа, на которой Akamai строит доверие к клиенту. Это структурированная строка, которая кодирует десятки сигналов, собранных bmak в браузере. Понимание её структуры критично для легитимной автоматизации.

Источники данных для sensor_data

sensor_data Akamai собирается из следующих источников:

• События мыши: координаты движения, скорость, ускорение, интервалы между кликами, количество кликов
• События прокрутки: направление, скорость, паттерны (плавная прокрутка vs мгновенный скачок)
• Touch-события: для мобильных устройств — давление, площадь касания,多点 touch
• Свойства экрана: screen.width, screen.height, screen.colorDepth, window.devicePixelRatio
• GPU-свойства: WebGL-параметры (UNMASKED_VENDOR_WEBGL, UNMASKED_RENDERER_WEBGL), версия WebGL, поддерживаемые расширения
• Тайминги: performance.now(), Date.now(), время загрузки страницы, задержки между событиями
• Свойства браузера: navigator.platform, navigator.languages, navigator.hardwareConcurrency, navigator.deviceMemory

Структура payload

Payload sensor_data передаётся как часть POST-запроса к эндпоинту Akamai (обычно /_bm/...). Строка содержит последовательность значений, разделённых специфическими разделителями, и включает:

1. Версию сенсора (соответствует версии sensor.js)
2. Хэш собранных событий
3. Закодированные временные ряды движений мыши
4. Отпечаток GPU и экрана
5. Случайный nonce для защиты от повторного воспроизведения

Почему одно несовпадение инвалидирует _abck

Вот критический момент: Akamai использует перекрёстную валидацию всех полей. Если ваш User-Agent заявляет «Chrome 131 на Windows 10», но:

• TLS-отпечаток (JA4) соответствует Firefox — _abck инвалидируется
• WebGL-рендерер сообщает «Apple GPU» вместо ожидаемого «ANGLE (NVIDIA ...)» — _abck инвалидируется
• navigator.platform = «Linux x86_64» при UA «Windows NT 10.0» — _abck инвалидируется
• HTTP/2 SETTINGS frame не совпадает с Chrome — _abck инвалидируется

Это означает, что частичный stealth — бесполезен. Вам нужно полное согласование всех сигналов, от сетевого уровня до JavaScript API. Именно поэтому инструменты вроде puppeteer-stealth с плагинами, исправляющими только отдельные поля, часто недостаточны против Akamai v2.

Сигналы протокола 2026: пост-квантовый обмен ключами, JA4 и HTTP/2

В 2026 году Akamai Bot Manager v2 проверяет не только JavaScript-отпечатки, но и сетевые характеристики на уровне TLS и HTTP/2. Эти сигналы особенно важны, потому что они видны серверу до выполнения любого JavaScript.

X25519MLKEM768: пост-квантовый key share в Chrome 131+

С выходом Chrome 131 в конце 2024 года, Google включил по умолчанию пост-квантовый key share X25519MLKEM768 в TLS 1.3. Это гибридный механизм, объединяющий классический обмен X25519 с пост-квантовой инкапсуляцией ключей ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism) с размером ключа 768-бит, как определено в RFC 8446 и последующих спецификациях NIST.

Akamai проверяет наличие этого key share в ClientHello. Если ваш User-Agent заявляет Chrome 131+, но TLS ClientHello не содержит X25519MLKEM768 — это мгновенный красный флаг. Библиотеки вроде Python requests или urllib3 не поддерживают этот key share по умолчанию, что делает их непригодными для имитации современных браузеров.

JA4: TLS-отпечаток нового поколения

JA4 — это улучшенная версия JA3, разработанная FoxIO. В отличие от JA3, JA4 учитывает порядок шифров, расширений и поддерживаемых групп. Akamai использует JA4 для сопоставления TLS-отпечатка с заявленным User-Agent.

Например, Chrome 131 на Windows генерирует JA4 вида t13d1516h2_8daaf615522b_b0da82dd1658. Если ваш HTTP-клиент генерирует другой JA4, Akamai знает, что вы не используете настоящий Chrome, даже если UA строка совпадает.

HTTP/2 SETTINGS fingerprint

Помимо TLS, Akamai проверяет HTTP/2 SETTINGS frame — начальные параметры соединения, которые каждый клиент отправляет серверу. Chrome, Firefox и Safari имеют разные значения для:

• HEADER_TABLE_SIZE
• ENABLE_PUSH
• MAX_CONCURRENT_STREAMS
• INITIAL_WINDOW_SIZE
• MAX_FRAME_SIZE
• MAX_HEADER_LIST_SIZE

Эти значения формируют уникальный отпечаток, который Akamai сравнивает с заявленным браузером. Если вы используете requests с HTTP/2-адаптером, ваши SETTINGS будут отличаться от настоящих Chrome — и Akamai это заметит.

Решение: используйте настоящий браузерный движок (Chromium через Playwright или Puppeteer), который генерирует корректные TLS и HTTP/2 сигналы автоматически. Это единственный надёжный способ обеспечить согласованность на всех уровнях стека.

Почему residential-прокси обязательны для работы с Akamai

Даже с идеально согласованным браузерным профилем, один неверный IP-адрес может разрушить всю вашу инфраструктуру. Akamai взвешивает репутацию IP-адреса очень высоко — возможно, выше, чем любой другой сигнал.

Datacenter ASN — это мгновенный красный флаг

Akamai поддерживает обширную базу данных автономных систем (ASN). IP-адреса из дата-центров (AWS, Google Cloud, Azure, DigitalOcean, OVH и др.) предварительно помечаются как бот-трафик. Это не означает автоматическую блокировку, но ваш начальный trust score будет значительно ниже — часто ниже порога, необходимого для прохождения challenge.

По данным индустриальных отчётов, более 50% веб-трафика генерируется ботами, и значительная часть блокируется именно на этапе IP-фильтрации. Дата-центр IP-адреса — это самый быстрый путь к блокировке в рамках обнаружения ботов Akamai 2026.

Residential IP: доверие по наследству

Residential-прокси используют IP-адреса, выделенные реальным интернет-провайдерам (ISP). Эти адреса принадлежат обычным домашним сетям, и Akamai не может отличить их от реальных пользователей без дополнительных сигналов. Это даёт вам:

• Высокий начальный trust score
• Корректную геолокацию, согласованную с другими сигналами
• Возможность использования sticky-сессий для сохранения валидного _abck

Сравнение типов прокси для Akamai

Ознакомьтесь с тарифами ProxyHat и доступными локациями, чтобы выбрать оптимальный вариант для вашей задачи.

Практическая реализация: ProxyHat + stealth-браузер

Теперь соберём всё вместе. Ниже — рабочий подход для легитимной автоматизации через ProxyHat residential-прокси с реальным браузерным движком, который корректно генерирует sensor_data и _abck.

Шаг 1: curl для базовой проверки

Начнём с простого curl-запроса через ProxyHat residential-прокси с гео-таргетингом:

curl -x http://user-country-US-session-abc123:pass@gate.proxyhat.com:8080 \
  -H "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" \
  -H "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" \
  -H "Accept-Language: en-US,en;q=0.9" \
  "https://example.com/"

Параметр session-abc123 в имени пользователя обеспечивает sticky-сессию: все запросы в рамках сессии будут идти с одного и того же IP, что критично для сохранения валидного _abck.

Шаг 2: Python + Playwright для полного stealth-профиля

Для реальной работы с Akamai нужен браузерный движок. Playwright с Chromium — лучший выбор, потому что он генерирует корректные TLS, HTTP/2 и JavaScript сигналы:

from playwright.sync_api import sync_playwright

proxy_config = {
    "server": "http://gate.proxyhat.com:8080",
    "username": "user-country-US-session-abc123",
    "password": "pass"
}

with sync_playwright() as p:
    browser = p.chromium.launch(
        proxy=proxy_config,
        headless=False,
        args=[
            "--disable-blink-features=AutomationControlled",
            "--no-sandbox"
        ]
    )
    
    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"
    )
    
    # Удаляем webdriver-признаки
    context.add_init_script("""
        Object.defineProperty(navigator, 'webdriver', {get: () => undefined});
        Object.defineProperty(navigator, 'languages', {get: () => ['en-US', 'en']});
        Object.defineProperty(navigator, 'plugins', {get: () => [1, 2, 3, 4, 5]});
    """)
    
    page = context.new_page()
    page.goto("https://example.com/", wait_until="networkidle")
    
    # Ждём формирования и валидации _abck
    page.wait_for_timeout(5000)
    
    cookies = context.cookies()
    abck = [c for c in cookies if c["name"] == "_abck"]
    ak_bmsc = [c for c in cookies if c["name"] == "ak_bmsc"]
    
    print(f"_abck cookie: {abck}")
    print(f"ak_bmsc cookie: {ak_bmsc}")
    
    browser.close()

Ключевые моменты:

• headless=False — некоторые версии Akamai обнаруживают headless-режим
• session-abc123 — обеспечивает постоянный IP для всей сессии
• timezone_id должен соответствовать гео прокси (US → America/New_York)
• Ожидание 5000ms даёт sensor.js время на сбор и отправку sensor_data

Шаг 3: Node.js + Puppeteer для высокопроизводительной автоматизации

const puppeteer = require('puppeteer');

(async () => {
    const browser = await puppeteer.launch({
        headless: false,
        args: [
            '--proxy-server=http://gate.proxyhat.com:8080',
            '--disable-blink-features=AutomationControlled'
        ]
    });

    const page = await browser.newPage();
    
    await page.authenticate({
        username: 'user-country-US-session-abc123',
        password: 'pass'
    });
    
    await page.setUserAgent(
        'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36'
    );
    await page.setViewport({width: 1920, height: 1080});
    
    await page.evaluateOnNewDocument(() => {
        Object.defineProperty(navigator, 'webdriver', {get: () => undefined});
    });
    
    await page.goto('https://example.com/', {waitUntil: 'networkidle2'});
    await new Promise(r => setTimeout(r, 5000));
    
    const cookies = await page.cookies();
    const abck = cookies.filter(c => c.name === '_abck');
    console.log('_abck:', abck);
    
    await browser.close();
})();

Стратегия ротации сессий

Для масштабирования используйте уникальные session ID для каждого браузерного контекста. ProxyHat поддерживает до 100 concurrent sessions на стандартном тарифе. Пример паттерна ротации:

import uuid

def get_proxy_url(country="US"):
    session_id = str(uuid.uuid4())[:8]
    return f"http://user-country-{country}-session-{session_id}:pass@gate.proxyhat.com:8080"

Каждая сессия получает новый residential IP, что позволяет распределить нагрузку и избежать паттернов, которые Akamai может обнаружить при слишком высокой частоте запросов с одного IP. Подробности настройки см. в документации ProxyHat.

Частые ошибки при работе с Akamai

• Использование HTTP-клиентов вместо браузера: requests, axios, httpx не генерируют sensor_data и не имеют корректных TLS/HTTP2 отпечатков.
• Несогласованная геолокация: IP в США, timezone «Europe/Berlin», locale «ru-RU» — мгновенный флаг.
• Слишком частая ротация IP: каждый запрос с нового IP не даёт _abck сформироваться. Используйте sticky-сессии.
• Headless-режим без модификаций: navigator.webdriver=true и отсутствие GPU-рендеринга — явные признаки автоматизации.
• Игнорирование robots.txt: даже при технической возможности доступа, игнорирование robots.txt может быть нарушением условий обслуживания.

Где это уместно: авторизованный мониторинг и security research

Технологии, описанные выше, применимы исключительно в легитимных сценариях:

• Авторизованный мониторинг цен: сбор публично доступной информации о ценах с явного согласия или в рамках fair use
• Security research: тестирование собственных ресурсов или ресурсов, для которых у вас есть письменное разрешение (bug bounty, pentest)
• QA-автоматизация: тестирование собственных или клиентских сайтов
• Сбор данных для AI: сбор публично доступных данных в соответствии с robots.txt и условиями обслуживания

Использование этих методов для обхода систем защиты с целью мошенничества, создания фейковых аккаунтов, ticketing-ботов или любых других нарушений условий обслуживания — незаконно и неэтично. Подробнее о легитимных сценариях читайте в разделах web scraping и SERP tracking.

Ключевые выводы

• Akamai Bot Manager v2 использует непрерывный серверный trust score, а не статичные правила. Один несогласованный сигнал инвалидирует _abck.
• sensor_data собирается из десятков источников: мышь, прокрутка, touch, экран, GPU, тайминги. Частичный stealth бесполезен.
• В 2026 году критичны сигналы протокола: X25519MLKEM768 key share в Chrome 131+, JA4 TLS-отпечаток и HTTP/2 SETTINGS. Они должны быть согласованы с User-Agent.
• Residential-прокси обязательны: datacenter ASN предварительно помечаются как бот-трафик.
• Используйте настоящий браузерный движок (Playwright/Puppeteer) через ProxyHat residential-прокси для корректной генерации всех сигналов.
• Sticky-сессии необходимы для сохранения валидного _abck между запросами.
• Всегда получайте разрешение владельца ресурса и соблюдайте CFAA, GDPR и условия обслуживания.