Akamai Bot Manager задеплоен более чем на 1.2 миллиона сайтов по данным BuiltWith — авиалинии, банки, тикетинговые сервисы, e-commerce, news. На большинстве из них старые техники обхода 2022-2023 годов больше не работают: TLS-fingerprint снимается ещё до отправки HTTP, sensor_data валидируется на сервере, датацентр-IP флагается по ASN. Ниже — что Akamai реально проверяет в 2026 и какие схемы обхода применяются на разных уровнях сложности.
Что детектит Akamai в 2026
Akamai Bot Manager сегодня — это пять параллельных слоёв детекта, каждый работает независимо. Запрос проходит, только если он чистый на всех пяти.
TLS fingerprint (JA3, JA4, JA4+). Главный вектор. Akamai снимает fingerprint TLS-handshake до того, как клиент отправит хоть один HTTP-байт. ClientHello содержит cipher suites, extensions, EC curves, версию TLS — всё это собирается в hash и сравнивается с базой реальных браузеров. Стандартный Python requests, urllib, httpx имеют свой характерный JA3, и Akamai моментально классифицирует его как «не браузер».
HTTP/2 fingerprint. SETTINGS-фрейм, WINDOW_UPDATE, PRIORITY-фреймы. Каждый клиент HTTP/2 в начале сессии передаёт набор параметров с конкретными значениями: SETTINGS_HEADER_TABLE_SIZE, SETTINGS_INITIAL_WINDOW_SIZE, SETTINGS_MAX_FRAME_SIZE. Chrome, Firefox, Safari имеют разные подписи, и стандартные HTTP-клиенты — третьи. Технически описано в работе Black Hat EU 2017 и развито в открытых исследованиях с тех пор.
sensor_data плюс _abck cookie. 58-элементный массив, который собирает JavaScript на странице: canvas fingerprint, motion trajectory (мышь, клики, scroll), hardware properties, browser capabilities. Массив шифруется проприетарным алгоритмом Akamai и отправляется POST-запросом. В ответ приходит cookie _abck. Если sensor_data убедительный, _abck даётся валидный, и дальнейшие запросы пропускаются. Если неубедительный — либо блок 403, либо запросы пропускают, но обрабатывают с задержкой 5-10 секунд.
Behavioral signals. Поведенческий слой смотрит на flow: с какой страницы пришёл, в каком порядке кликаешь, как двигается мышь, успеваешь ли смотреть на страницу перед действием. Боты обычно делают слишком быстро или слишком ровно. Этот слой работает поверх sensor_data и оценивает не отдельный запрос, а всю сессию.
IP reputation. ASN-скоринг. Akamai знает, что AS14061 (DigitalOcean), AS16509 (AWS), AS14618 (Amazon EC2), AS396982 (Google Cloud) и аналогичные — это датацентры. Запрос с такого ASN автоматически получает плохой score. Residential ISP-блоки и mobile-ASN получают хороший score.
Все пять слоёв работают одновременно и складываются в общий risk score. Akamai не блокирует на одном плохом сигнале, но не пропускает при нескольких.
Какие техники больше не работают
Стандартный Python requests, urllib, httpx. Падает на TLS fingerprint в первой же секунде. Никакой User-Agent header не спасает — TLS-слой проверяется до HTTP.
Selenium с puppeteer-extra-stealth или playwright-stealth. JS-патчи закрывают navigator.webdriver и фейковые plugins, но TLS-fingerprint остаётся «headless Chrome», canvas и audio дают свои аномалии. На сайтах с Akamai BMP детектится крайне ненадёжно.
Только датацентр-IP с любой ротацией. ASN-скоринг закроет вопрос на первом же запросе. Чистая ротация не работает.
Только User-Agent spoofing. Akamai смотрит TLS до того, как видит хедеры.
JA3Proxy в одиночку. Подделывает TLS, но не закрывает HTTP/2 fingerprint и behavioral.
Минимально рабочий стек
Для большинства Akamai-сайтов нужно одновременно закрыть три слоя из пяти своими руками: TLS, HTTP/2 и IP reputation. sensor_data и behavioral закрываются либо реальным браузером, либо коммерческим сервисом. Без правильного TLS+HTTP/2 ничего из остального не имеет смысла — запрос отбрасывается на первом слое.
TLS и HTTP/2 fingerprint. Решается библиотекой с native TLS-impersonation реальных браузеров. Самая распространённая — curl_cffi для Python (поддерживает Chrome, Firefox, Safari, Edge разных версий). Альтернативы: tls-client для Go, scrapy-impersonate для Scrapy, curl-impersonate как baseline-инструмент. Все они меняют сам TLS-handshake и HTTP/2 SETTINGS-фрейм, чтобы выглядеть как настоящий браузер указанной версии.
IP reputation. Residential прокси с sticky session. Sticky-сессия означает, что одна пользовательская сессия проходит через один IP — Akamai не любит, когда IP меняется в середине логина или checkout flow. Geo-локация прокси должна совпадать с заявленной локалью браузера: en-US headers + IP в Германии — повод для anomaly score.
Headers и navigation flow. Прогрев главной страницы перед target, Referer, Accept-Language под impersonated browser. TLS-impersonation библиотеки выставляют большую часть headers автоматически, но Referer и Accept-Language часто стоит подкрутить под целевой сайт.
На сайтах с базовым Akamai BMP без агрессивной sensor_data валидации этого стека достаточно. Akamai в таких конфигах выдаёт _abck в ответ на чистый TLS-handshake «от Chrome», и cookies в session-объекте автоматически идут с последующими запросами.
Когда нужно нагулять cookies в реальном браузере
На сайтах со строгой sensor_data валидацией (премиум-тикетинг, крупные авиалинии, банки) Akamai не выдаёт валидный _abck в ответ на голый TLS-handshake. Чтобы _abck был принят, нужен реальный POST sensor_data, а это значит canvas, motion trajectory, исполнение JS. TLS-impersonation библиотека такого не делает.
Решение — двухступенчатая схема. На первом шаге открываешь страницу в реальном браузере с binary-stealth-патчами, даёшь JS выполниться и сензору отработать. Получаешь cookies (_abck, ak_bmsc, bm_sz). На втором шаге переносишь cookies в TLS-impersonation сессию и продолжаешь скрейпить с её скоростью, без накладных расходов на браузер.
Принципиальный момент: браузерный движок на Шаге 1 и impersonate-цель на Шаге 2 должны совпадать. Akamai в собственной документации (techdocs.akamai.com/cloud-security/docs/detection-methods) явно перечисляет browser version mismatches как сигнал для anomaly detection. Если sensor_data был POSTан с Firefox-fingerprint, а subsequent requests идут с Chrome-impersonate TLS-handshake — это палится. Рабочие пары:
Camoufox (Firefox-based stealth-браузер) на Шаге 1, impersonate=firefox-NNN в TLS-impersonation библиотеке на Шаге 2.
Patchright (Chromium-based stealth-браузер) на Шаге 1, impersonate=chrome-NNN на Шаге 2.
Обычный Playwright или Puppeteer с JS-stealth-плагинами на Шаге 1 не годится — детектится Akamai на binary-уровне ещё до того, как успевает отправить sensor_data.
_abck cookie живёт ограниченное время и зависит от конфигурации сайта. Когда срабатывает 403 на повторный запрос, цикл обновляется: возвращаешься в реальный браузер, получаешь свежие cookies, переносишь в сессию.
Сложные сайты с агрессивным behavioral
Топ-уровень Akamai (Ticketmaster, премиум-тикетинг, крупные авиалинии, банки) применяют все слои детекта на максимуме. Кроме строгой sensor_data валидации, там работает behavioral-слой, который смотрит на timing и flow всей сессии. Просто перенос cookies из браузера в TLS-impersonation library там обычно не проходит — нужно либо держать сессию в браузере целиком, либо дополнительно симулировать поведение. Для этих сайтов есть три пути.
Open-source toolkits. На GitHub есть несколько живых проектов, которые делают reverse engineering sensor_data. Самые серьёзные — github.com/xiaoweigege/akamai2.0-sensor_data, github.com/luluhoc/akamai_v2_toolkit, github.com/glizzykingdreko/akamai-sensordata-decryptor, github.com/reverse-god/akamai-sensordata. Это путь для тех, кто умеет читать reverse-engineered Akamai алгоритмы и поддерживать код, когда Akamai обновляется.
Real browser плюс behavioral simulation. Camoufox через residential прокси, плюс библиотека для правдоподобной имитации мыши, клавиатуры и задержек. На выходе генерируется реальный sensor_data, который проходит даже жёсткие конфиги. Дороже по времени, но работает стабильно.
Commercial bypass-as-a-service. Scrapfly ASP, ScraperAPI bypass-akamai, Bright Data Web Unlocker. Они держат собственный parser Akamai и платят инженерам, которые догоняют каждое обновление. Платишь за запрос, получаешь готовый HTML.
Альтернатива для тех, кто не хочет DIY
Managed-сервисы стоят больше за запрос (порядка нескольких центов на сложных таргетах против долей цента за residential request), но снимают всю инженерию.
Scrapfly ASP, ScraperAPI bypass-akamai, Bright Data Web Unlocker — рабочие коммерческие решения. Имеет смысл, если стоимость инженера выше стоимости платного API.
Коротко
Akamai в 2026 — это пять параллельных слоёв: TLS fingerprint (JA3, JA4), HTTP/2 SETTINGS-фрейм, sensor_data + _abck cookie, behavioral signals, IP reputation. Запрос проходит, только если чистый на всех.
Базовые Akamai-конфиги: TLS-impersonation библиотека (curl_cffi или аналог) + residential proxy с sticky session + прогрев главной перед target. Этот стек закрывает TLS, HTTP/2 и IP, и проходит сайты, где sensor_data валидация мягкая.
Сайты со строгой sensor_data валидацией: cookies нагуливаются в реальном браузере с binary-stealth-патчами (Camoufox или Patchright), затем переносятся в TLS-impersonation сессию. Браузерный движок и impersonate-цель должны совпадать — иначе Akamai видит browser version mismatch.
Топ-сайты с агрессивным behavioral: open-source toolkits, реальный браузер с behavioral simulation, или коммерческий Scrapfly ASP / ScraperAPI / Bright Data Web Unlocker.
Что не работает в 2026: чистый Python requests, чистый Selenium-stealth, только датацентр, только UA-spoofing, JA3Proxy в одиночку.