Cookies Akamai Bot Manager: _abck, ak_bmsc, bm_sz и bm_sv

Через cookies Akamai Bot Manager запоминает, какое решение уже принято о вашем клиенте. Первой приходит bm_sz — обычно с первым HTML-ответом — и живёт около четырёх часов. ak_bmsc и bm_sv — короткие сессионные cookies примерно на два часа. _abck — постоянная, обычно выставляется на год: в ней записано, приняты ли клиентские проверки вашего браузера. Значения зашифрованы и не документированы. Прочитать из них можно другое: какие cookies у вас есть, когда они меняются и остаются ли они за одним клиентом на одном IP.

Cookies Akamai Bot Manager: краткий обзор

Akamai не публикует поштучной спецификации этих cookies. Самый надёжный публичный источник — описания cookies: документация продуктов и страницы о cookies самой Akamai, а также cookie-политики сайтов, на которых работает Bot Manager. Таблица ниже сводит их вместе. Где источники расходятся, это указано.

Источники: список cookies RIPE NCC приводит все пять, относит их к строго необходимым и указывает 1 год для _abck, 4 часа для bm_sz и 2 часа для ak_bmsc, bm_sv и bm_mi. cookie.is даёт те же сроки для _abck, bm_sz, ak_bmsc и bm_sv. Таблица cookies Akamai Identity Cloud содержит описание bm_sv и флаги HttpOnly/Secure/SameSite для ak_bmsc и bm_sv. Собственная страница настроек cookies Akamai относит _abck, ak_bmsc и bm_sv к строго необходимым, а bm_sz — к cookies производительности.

Два практических предупреждения. Во-первых, все эти атрибуты задаются для каждого развёртывания отдельно, так что сроки выше типичные, а не гарантированные. Смотрите реальные заголовки Set-Cookie на сайте, с которым работаете. Во-вторых, новые развёртывания выставляют дополнительные cookies, имена которых вы можете увидеть в DevTools. Надёжного публичного описания для них мы не нашли, поэтому здесь они не рассматриваются.

_abck: cookie, в которой хранится вердикт

_abck — постоянная cookie, отражающая, прошёл ли ваш браузер клиентские проверки Akamai. Сначала она выдаётся в невалидированном состоянии, а затем сервер перезаписывает её всякий раз, когда скрипт Bot Manager отправляет данные. Срок жизни обычно год, но «валидированное» состояние внутри неё длится гораздо меньше, чем сама cookie.

Значение — длинная зашифрованная строка из секций, разделённых тильдами. Обсуждаются только короткие маркеры вроде ~-1~ и ~0~. Всё, что ниже, — наблюдения сообщества. Akamai эти маркеры никогда не документировала, а один подробный разбор, от Scrapfly, прямо советует вообще не выводить фиксированные поля из значения. Независимые источники сходятся примерно в такой интерпретации:

• ~-1~ в начальной позиции: клиент ещё не прошёл клиентскую проверку. В этом состоянии приходит свежая _abck, и в нём же она остаётся, если приемлемая телеметрия так и не поступила.
• ~0~ в этой позиции: проверка пока пройдена. Обычно это описывают как клиентский «стоп-сигнал», сообщающий скрипту страницы, что телеметрию можно больше не отправлять.
• Валидированную cookie могут сбросить. Защищённые эндпоинты способны выдать новую _abck, которая возвращает вас в невалидированное состояние, например перед входом в аккаунт или оформлением заказа.

Разбор Crawlex даёт ту же интерпретацию и подчёркивает, что она получена «целиком из наблюдений за тем, как меняется cookie». Главное следствие — чего ~0~ не означает. Это не пропуск. Akamai по-прежнему оценивает каждый запрос по репутации IP, отпечаткам протоколов и паттернам запросов, и cookie с ~0~, предъявленная с другого клиента или из другой сети, может не пройти. В quick start по Bot Manager сама Akamai перечисляет детект Cookie Integrity Failed, который «гарантирует, что ни один оператор ботов не подделал cookie Bot Manager и не пытается её воспроизвести». То есть скопированная _abck — ровно то, что система создана ловить.

Поскольку скрипт страницы читает этот маркер, _abck, как правило, не HttpOnly; обычно её видно в document.cookie. Официального заявления Akamai на этот счёт мы не нашли, так что проверьте на сайте, который тестируете.

bm_sz: затравка сессии

bm_sz обычно выставляется в самом первом HTML-ответе защищённого хоста, ещё до запуска какого-либо JavaScript Bot Manager, и живёт около четырёх часов. Технические разборы вроде анализа bm_sz от Crawlex описывают её как посессионные входные данные, с которыми работает клиентский скрипт. Поэтому bm_sz из другой сессии или с другого origin ломает всё, что идёт дальше. Если клиент вообще не получает bm_sz, защищённая страница, вероятно, не проходила через Bot Manager — при отладке это полезно знать.

ak_bmsc: короткоживущая сессионная cookie

ak_bmsc — сессионная cookie примерно на два часа. Описания говорят, что она отличает людей от ботов, а документация Akamai Identity Cloud добавляет, что она «используется для оптимизации производительности». О флаге HttpOnly разборы спорят. Собственная таблица Akamai Identity Cloud указывает HttpOnly: false, а несколько блогов о скрапинге пишут, что она HttpOnly, — видимо, настройка зависит от развёртывания. Если cookie исчезла посреди сессии, обычно причина в том, что прошло два часа или ваш клиент потерял cookies.

bm_sv и bm_mi

bm_sv — единственная cookie, которую Akamai описывает напрямую («used by Akamai Bot Manager to help differentiate between web requests generated by humans and web requests generated by bots or other automated processes»). Живёт около двух часов. В quick start Akamai также упоминает детект Session Validation, который «считает количество HTML-страниц и AJAX-запросов, поступающих от клиента». Название намекает на связь с bm_sv, но публично это ничем не подтверждено, так что полагаться на это не стоит. bm_mi встречается в описаниях некоторых развёртываний со сроком жизни два часа и без других подробностей.

Как в общих чертах работает поток сенсорных данных

Bot Manager работает слоями. Edge оценивает каждый запрос сам по себе, а JavaScript-слой в браузере добавляет клиентские данные, результат которых записывается в _abck. Quick start Akamai называет основные детекты:

• Имитаторы известных ботов: поддельный Googlebot и подобные.
• Детект по user agent и обнаружение аномалий в запросах: несоответствия внутри одного запроса.
• Репутация веб-скраперов: «плохая оценка репутации IP-адресам, которые недавно занимались скрапингом».
• Целостность cookies, валидация сессии и валидация браузера: «подтверждает, что запросы идут из настоящего веб-браузера».
• Обнаружение поведенческих аномалий: только в Premier, на транзакционных эндпоинтах вроде входа и оформления заказа.

Текущая страница методов детекта Akamai описывает то же разделение: прозрачный детект ловит «заголовки не в том порядке и несоответствия версий браузера», а активный детект «использует взаимодействие, чтобы подтвердить, что запрос идёт из веб-браузера».

Жизненный цикл cookies вытекает из этой схемы:

1. Первый ответ защищённого хоста выставляет bm_sz и невалидированную _abck, а страница загружает скрипт Akamai.
2. Скрипт собирает в браузере клиентские сигналы (окружение, тайминги, а на некоторых страницах и взаимодействие) и отправляет их на first-party эндпоинт того же сайта.
3. Akamai оценивает отправленные данные вместе с сигналами уровня запроса и возвращает Set-Cookie, обновляющий _abck.
4. Последующие запросы несут эти cookies. Edge проверяет, что они целы, принадлежат этой сессии и согласуются со всем остальным, что он видит.

За рамками статьи: мы не описываем сенсорный payload, способы его генерации или построения значений cookies. Подделка телеметрии Akamai — ровно то, для чего существуют Cookie Integrity и связанные детекты, и с этим мы не помогаем. Общую картину сигналов, включая TLS- и HTTP/2-отпечатки, смотрите в нашем подробном разборе Akamai Bot Manager.

Почему HTTP-клиенты застревают с невалидной _abck

HTTP-библиотеки вроде requests, httpx или net/http в Go не выполняют JavaScript, поэтому скрипт Bot Manager не запускается и _abck никто не обновляет. Клиент продолжает отправлять невалидированную cookie, полученную в первом ответе. На страницах, где Akamai требует валидации браузера, это ожидаемый результат.

Исправление TLS этого не меняет. Библиотека-имитатор может сделать рукопожатие и фреймы HTTP/2 похожими на Chrome, но не может выдать клиентские данные, которые выдал бы скрипт. На практике обычно происходит так: страницы, использующие только прозрачный слой, продолжают работать, а страницы, требующие активной валидации (вход, корзины, поисковые API на некоторых сайтах), начинают отдавать 403 или страницы с челленджем.

Прежде чем выбирать инструменты, спросите себя, какие страницы вам действительно нужны. Много публичных данных доступно без активного слоя, а официальный API сайта или фид данных часто оказывается лучшим решением, чем автоматизация браузера.

Что иначе делает настоящий браузер на чистом и стабильном соединении

Настоящий браузер выполняет скрипт, хранит свои cookies, отправляет один согласованный TLS- и HTTP/2-отпечаток и всю сессию остаётся в одной сети. Именно это сочетание переводит _abck в валидированное состояние и удерживает её там. Важна каждая часть:

• Храните cookie jar всю сессию. Если вы теряете cookies между запросами, каждый запрос выглядит как первый визит: новая bm_sz, невалидированная _abck, и скрипт должен отработать снова. В Playwright один контекст браузера — это один cookie jar. Не открывайте новый контекст на каждую страницу.
• Держите один выходной IP на сессию. Cookies, выданные сессии на одном IP и воспроизведённые с другого, выглядят как то самое копирование, которое ловит Cookie Integrity. Если вы меняете IP посреди сессии, cookies перестают соответствовать сети, в которой были выданы. Для всего, что имеет состояние (просмотр категории, корзина, сценарий с авторизацией), используйте sticky-сессию и ротируйте IP только между сессиями. Как подобрать их длительность, рассказано в нашем руководстве по sticky- и ротационным сессиям.
• Начинайте с чистого IP. Web Scraper Reputation считается по IP. Диапазон дата-центра с историей скрапинга оказывается под подозрением ещё до того, как выставлена хоть одна cookie. У резидентных и мобильных IP разные базовые уровни репутации; как строятся эти оценки, объясняет наш подробный материал о репутации IP.
• Делайте запросы в правдоподобном для человека темпе. Session Validation буквально считает HTML- и AJAX-запросы на клиента. Валидная _abck не спасёт сессию, которая делает сотни запросов страниц в минуту.

Минимальная конфигурация Playwright, соблюдающая эти правила, выглядит так. Один постоянный контекст, один sticky резидентный выход и сохранённое состояние, чтобы следующий запуск продолжил ту же сессию, а не начинал заново:

from pathlib import Path
from playwright.sync_api import sync_playwright

STATE = Path("state.json")
PROXY = {
    "server": "http://gate.proxyhat.com:8080",
    "username": "USERNAME-sid-abc123-ttl-10m",   # sticky: один и тот же выходной IP на всю сессию
    "password": "PASSWORD",
}

with sync_playwright() as p:
    browser = p.chromium.launch(proxy=PROXY)
    context = browser.new_context(
        storage_state=str(STATE) if STATE.exists() else None
    )
    page = context.new_page()
    page.goto("https://www.example.com/", wait_until="load")
    # ... немного переходов в человеческом темпе ...
    names = sorted(c["name"] for c in context.cookies())
    print(names)                                # какие cookies Akamai у вас есть
    context.storage_state(path=str(STATE))      # сохраняем jar для следующего запуска
    browser.close()

Привязывайте сохранённое состояние к ID его сессии. Если вы продолжите с state.json через другой выходной IP, то воссоздадите ту самую проблему смены IP, которой пытались избежать.

Диагностика: симптом, вероятная причина, что проверить

Проверяйте по одной переменной за раз. Большинство жалоб «меня блокирует Akamai» в итоге сводятся к одной из первых трёх строк. В этой таблице есть место и неудобному, но честному ответу: иногда сайт решил не обслуживать автоматизированный трафик на этом пути, и правильная реакция — остановиться или запросить доступ.

Владельцам сайтов: как читать эти cookies в своих логах

Если у вас работает Bot Manager, логируйте имена cookies и маркер состояния _abck, а не значения, и принимайте решения на основе собственных бот-результатов Akamai. Значения зашифрованы, а формат может измениться без предупреждения. Закономерности, которые можно извлечь из обычного access log:

• Запросы к глубоким URL вообще без bm_sz или _abck. Это клиенты без cookies: либо первые заходы, либо инструменты, выбрасывающие cookies. Высокая доля таких запросов на URL товаров или поиска без соответствующих заходов на посадочные страницы указывает на скриптовый доступ.
• Одно и то же значение _abck с множества IP или ASN. Это совместное использование или воспроизведение cookies. Для этого и создан детект Cookie Integrity в Akamai. Ваши логи позволяют оценить масштаб проблемы и затронутые пути.
• Сессии, которые остаются невалидированными на протяжении многих запросов. Обычно это клиенты, которые вообще не выполняют JavaScript ваших страниц. Проверьте это до ужесточения правил: то же самое вызывают расширения для приватности и сбои в доставке скриптов.
• Бот-результаты на стороне origin. Akamai может пересылать свой вердикт на ваш origin в заголовках запроса. Руководство по интеграции Auth0 документирует заголовки akamai-bot и akamai-user-risk и ссылается на настройку Akamai «Forward Bot Results to Origin». Поддерживаемое поле вроде этого лучше, чем разбор внутренностей cookies.

О приватности: эти cookies — идентификаторы, привязанные к устройству. Описания вроде RIPE NCC относят их к строго необходимым, что в ЕС обычно означает отсутствие необходимости в согласии. Но логи, хранящие сырые значения вместе с IP, всё равно содержат персональные данные, поэтому хешируйте или удаляйте значения, как только получили маркер и набор имён.

Чего эти cookies не говорят

Cookie может показать, что клиентская валидация ещё не произошла. Она не может показать, что запрос будет пропущен. Детекты на уровне запроса (репутация IP, отпечатки протоколов, аномалии в заголовках, темп) работают независимо от _abck, а владельцы сайтов задают для отдельных путей политики, которых снаружи не видно. При отладке используйте cookies как один сигнал, а коды ответов, страницы челленджей и тайминги — как другие.