DataDome, Akamai и Cloudflare Bot Management — сравнение (2026)

Мы реселлим всю линейку hellworld.io — 14 резидентных брендов (ротационные, продаются за гигабайт), 3 пула 4G-mobile (FP-Mobile / ET-Mobile / HD-Mobile), Static ISP (за IP в месяц) и 2 безлимитных тарифа (Unlimited ISP / Unlimited Residential). На каждом из них мы зарабатываем свою маржу. Поэтому, когда мы пишем о том, какой прокси работает против какого антибот-вендора, честная рамка такая: нам всё равно, кто победит. Клиент, который покупает у нас Lumi, платит ту же розничную цену, что и при покупке напрямую, — и то же самое касается клиента, который берёт F-Oxylab или запускает FP-Mobile. Наш интерес лишь в том, чтобы вы быстро нашли нужный инструмент, перестали метаться между вариантами и остались с нами. Это и есть тот перекос, о котором стоит помнить при чтении.

Это второй материал из нашей серии 2026 года. Первым был 14 протестированных брендов, где мы сравнивали сами прокси-сети. Этот же смотрит на другую сторону баррикад: на антибот-стеки, которые эти прокси пытаются обойти. В будущих постах мы разберём каждого вендора по отдельности. Считайте этот материал картой местности.

Почему «антибот» — более полезная рамка, чем «WAF» в 2026 году

Многие гайды для покупателей всё ещё говорят о WAF. WAF — это web application firewall, файрвол уровня веб-приложений. Это слой, который смотрит на HTTP-полезную нагрузку и спрашивает: это SQL-инъекция? XSS-строка? Обход пути (path traversal)? Полезно, но в основном ортогонально той проблеме, которая реально есть у клиентов-покупателей прокси.

Антибот — это другой слой. Ему всё равно, что тело вашего запроса безобидно. Его волнует, кто вы такой. А именно три вещи: репутация IP, с которого вы пришли, отпечаток браузера или клиента, который вы используете, и поведенческие сигналы между вашими запросами. WAF появились раньше бот-экономики. Антибот-стеки были созданы потому, что WAF не умели отличить скрапер от покупателя.

Для клиентов-покупателей прокси в 2026 году WAF почти никогда не важен. Почти каждый тикет в поддержку из серии «мой прокси не работает» — это про антибот, а не про WAF. Сам HTTP-запрос в порядке. IP получил низкий скоринг, или TLS-отпечаток не совпал с user-agent, или цепочка cookie не содержала challenge-токен, который ожидал сайт. Ничего из этого не является поведением файрвола в классическом смысле.

Так что, когда вы выбираете прокси, WAF на целевом сайте — это в основном шум. Антибот-вендор перед ним — вот переменная, которая имеет значение. Об этом и весь гайд.

6 вендоров, которые имеют значение

Антибот-продуктов существуют десятки. Шесть из них покрывают подавляющее большинство высокозащищённого трафика, с которым реально сталкиваются наши клиенты. Вот этот состав:

Вендор	Где встречается	Стиль обнаружения	Стратегия по прокси (грубо)
Cloudflare Bot Management + Turnstile	Везде — крупнейший охват среди CDN	Репутация IP + JS-челлендж + TLS	Предпочтительны резидентные; датацентровые часто проваливаются
DataDome	E-commerce, медиа, доски объявлений	Многослойный скоринг: IP + фингерпринт + поведение	Mobile наиболее стабильны; бюджетные пулы часто проваливаются
Akamai Bot Manager (BMP)	Кроссовки, авиалинии, банки, крупный ретейл	Sensor data payload + цепочка cookie	Mobile / ISP для кроссовок; резидентные по-разному
PerimeterX (HUMAN)	Supreme, StubHub, тикетинг	Семейство cookie _px + JS + поведение	Mobile сильны; ротация резидентных часто слаба
Queue-it	Ticketmaster, дропы, госуслуги	Виртуальная комната ожидания (не антибот)	Sticky ISP / sticky mobile; ротация вредит
Kasada	Банки ANZ, Twitch, госуслуги	Клиентский WASM-челлендж	Менее чувствителен к IP; важнее солвер

Два предупреждения по поводу этой таблицы. Во-первых, «стратегия по прокси» — это грубый паттерн, который мы видим в тикетах поддержки, а не гарантия. Каждый вендор настраивает свою конфигурацию под конкретного заказчика. Akamai у Nike — это не Akamai у Delta. Во-вторых, грань между вендорами размывается. Сайты постоянно стекают по две системы: Cloudflare спереди, DataDome сзади, или Akamai на витрине и PerimeterX на оформлении заказа. Правильный ответ на вопрос «какой прокси использовать» зависит от того, какой слой реально занимается блокировкой, а это меняется от сайта к сайту.

Следующие разделы разбирают каждого вендора по очереди.

Cloudflare Bot Management и Turnstile

Cloudflare — это слон в посудной лавке. Они стоят перед огромной долей современного веба, и их продукт Bot Management — это то, с чем большинство клиентов-покупателей прокси сталкивается в первую очередь.

Сначала о публичной механике. Cloudflare присваивает каждому запросу BotScore от 0 до 99. Собственная документация Cloudflare описывает 1 как «определённо бот», 99 как «определённо человек», а среднюю полосу — как неопределённость. Операторы сайтов пишут правила поверх этого скора: блокировать ниже 30, бросать челлендж ниже 60, пропускать выше 80 — что-то в таком духе. Скор потребляют WAF и rate limiter сайта; сам Cloudflare не решает, что блокировать, — это решает заказчик.

Скор строится из целого стека сигналов. Репутация ASN, к которому относится IP, — один из входов. JA3 / JA4 TLS-фингерпринт — другой. Порядок HTTP/2-фреймов. Браузерные JS-челленджи, которые отправляют отчёт обратно. Поведенческие паттерны на протяжении сессии. Ни один из них по отдельности не является решающим — Cloudflare комбинирует их.

Turnstile — это видимая поверхность челленджа. Это виджет, который заменил reCAPTCHA на множестве сайтов; запущен как v1 в 2022 году и обновлён до v2 в 2025-м. Когда Turnstile пройден, браузер получает cookie cf_clearance, которая ручается за сессию. Эта cookie короткоживущая и привязана к фингерпринту, так что повторное использование cf_clearance из другого браузера — это как раз тот случай, который заканчивается провалом.

Теперь про прокси-ракурс. Cloudflare публично заявляет, что датацентровые ASN по умолчанию несут более высокий бот-риск — это есть в их собственном маркетинге, мы это не выдумываем. Так что запрос с известного датацентрового IP стартует с гандикапом по скору ещё до того, как приземлится любой другой сигнал. Резидентные и мобильные IP стартуют выше. ISP-прокси, технически размещённые в датацентре, но на резидентных ASN, оказываются где-то посередине и ведут себя по-разному в зависимости от провайдера.

В наших тикетах поддержки цели под защитой Cloudflare — это самый частый вопрос «почему мой прокси не работает», который мы видим. Паттерн повторяется. Клиент покупает бюджетный резидентный пул, чтобы скрапить сайт за Cloudflare, упирается в челлендж, переключается на премиум-пул и проходит. Или он уже был на премиальных резидентных, и проблема на самом деле была в его TLS-фингерпринте, а не в IP. Cloudflare наказывает и за то, и за другое.

Наш обычный поток поддержки выглядит так. Если клиент проваливается на Cloudflare, мы сначала спрашиваем, отдаёт ли его HTTP-клиент настоящий браузерный TLS-фингерпринт. Скрипт на python с requests и дефолтным urllib3 будет фингерпринтиться как автоматизация независимо от того, насколько чист IP. Если со стороной фингерпринта всё в порядке, тогда важен слой IP, и мы бы склонялись к резидентным пулам Lumi или F-Oxylab, на которые, по нашим наблюдениям, чаще всего переходят повторно. Оба упомянуты на нашей странице сравнения прокси.

Конкретно Turnstile сложнее, чем один только BotScore. Он запускает JS в браузере, собирает энтропию и отправляет токен. Пропустить челлендж означает либо отрендерить его в настоящем браузере, либо использовать сторонний солвер, либо проходить через сессию, у которой уже есть валидная cookie cf_clearance. Ничего из этого, строго говоря, не является проблемой прокси — это проблема на стороне клиента. Прокси даёт вам репутацию IP; клиент даёт вам challenge-токен. Мы видим, как клиенты путают эти две вещи и винят прокси, когда проблема в их headless-сборке.

Подробный разбор стратегии обхода Cloudflare получит отдельный пост позже в этой серии.

DataDome

DataDome — второй по частоте вендор, который мы видим в тикетах поддержки, особенно от клиентов, скрапящих e-commerce, доски объявлений и медиа.

Их публичная документация описывает многослойный подход к скорингу. Слои, как их описывает сам DataDome в своих материалах: репутация IP, отпечаток браузера, поведенческие сигналы и машинное обучение поверх всего этого. Каждый слой подпитывает скор. Сайт видит вердикт — пропустить, бросить челлендж, заблокировать — не видя внутренней кухни.

Видимая cookie — datadome. Она устанавливается после успешного прохождения и сохраняется, пока скор не упадёт. Сессии, которые смешивают чистые и грязные сигналы, как правило, теряют cookie на середине процесса, что выглядит как «минуту назад всё работало, а теперь нет».

Челлендж DataDome — это JS-интерстишал. Он запускается, собирает данные и либо выдаёт cookie, либо показывает капчу. Сама капча — это симптом, идущий ниже по цепочке: к моменту, когда вы её видите, скор уже опустил вас ниже порога пропуска.

Со стороны прокси грубый отраслевой консенсус таков: мобильные операторы, как правило, набирают лучший скоринг, чем резидентные, против DataDome, а резидентные, как правило, набирают лучше, чем датацентровые. Это не потому, что DataDome явно вносит операторов в белый список, — а потому, что операторские IP делятся между миллионами легитимных пользователей, и общий скоринг склоняется в их пользу. Мы не будем называть тут конкретных цифр. Этот паттерн всплывает в блогах вендоров, на скрапинг-форумах и в нашей собственной клиентской базе.

Бюджетные резидентные пулы — это стабильный режим провала, который мы наблюдаем. Клиенты регистрируются в дешёвом пуле, направляют его на цель под DataDome, и запросы проваливаются почти сразу. IP дешёвого пула быстро переиспользуются, часто делятся между множеством клиентов, гоняющих агрессивные скраперы, и слой репутации IP их флагует. Тот же клиент переходит на премиум-тариф — и доля успеха подскакивает. Стоит ли этот скачок разницы в цене, зависит от объёма: для разовых скрапов иногда дешёвого пула плюс ретраев достаточно; для продакшн-пайплайнов данных дешёвый пул сжигает на проваленных запросах больше, чем стоил бы премиум.

Для долгоиграющей работы с DataDome мы обычно направляем клиентов на мобильные пулы или премиальные резидентные. Оба перечислены на наших страницах продуктов residential и mobile. Выбор между ними в основном про объём запросов и потолок по стоимости.

Akamai Bot Manager (BMP)

Akamai — тяжеловес в крупном ретейле, авиалиниях и банках. Если вы скрапите или покупаете на Nike, Adidas, Footlocker, Delta, United или в большинстве крупных банков, то против вас работает именно Akamai.

Техническая поверхность хорошо задокументирована в публичных разборах реверс-инжиниринга. Akamai BMP собирает большой блоб данных отпечатка браузера через JS — движения мыши, размер экрана, перечисление плагинов, тайминги, события указателя, всё подряд. Этот блоб сериализуется, кодируется в base64 и отправляется обратно на сервер как «sensor data». Сервер оценивает его и устанавливает cookie _abck.

Cookie _abck имеет структуру, которую годами разбирало по косточкам кроссовочное сообщество. Поле sec~ внутри значения cookie — это видимый вердикт. sec~-1~ означает, что сенсор не прошёл валидацию. sec~7~ (и другие положительные целые числа в этом диапазоне) означает, что сенсор прошёл. Есть и другие поля, и Akamai ротирует их значения, но различие между -1 и положительным числом стабильно настолько, что разработчики солверов на него ориентируются.

Другой сигнал — цепочка заголовков sec-cpt. После определённых точек челленджа Akamai ожидает, что последующие запросы будут нести заголовок, доказывающий выполнение compute proof-of-work. Пропустить cpt-цепочку означает провалить более поздние чекпоинты, даже если первоначальный сенсор прошёл.

Стратегия по прокси для Akamai сильно зависит от цели. Кроссовочное сообщество остановилось на мобильных и ISP-прокси как на дефолте для дропов под защитой Akamai — там этот консенсус глубиной в годы, и мы не будем с ним спорить. Наша страница sneaker proxy это отражает: мобильные и ISP-бренды вынесены вперёд.

Для не-кроссовочных целей под Akamai — авиалинии, банки, общий ретейл — картина более размытая. Mobile по-прежнему работают. Резидентные работают на одних целях и не работают на других. Датацентровые проваливаются почти везде. ISP — это золотая середина, которая хорошо работает на сайтах, где слой IP у Akamai весит умеренно, но не доминирует.

Вот что стоит держать в голове: слой IP у Akamai BMP — это один вход среди многих. Идеальный IP со сломанной sensor data payload всё равно провалится. Мы видим, как клиенты тратятся на премиальные ISP и всё равно получают блок, потому что их headless-браузер не генерирует валидные sensor data. Прокси необходим; прокси недостаточно.

В этой серии будет более глубокий пост про Akamai. Мы разберём структуру сенсора, cpt-цепочку и то, как выглядит типичный тулчейн солвера.

PerimeterX (HUMAN)

PerimeterX несколько лет назад слился с HUMAN Security. Продукт по-прежнему поставляется как PerimeterX в большинстве контекстов, cookie всё ещё _px*, но брендинг материнской компании сместился. Вместе с ним сместились и внутренние детали, и мы будем держать этот раздел консервативным, потому что продуктовый цикл после слияния всё ещё в движении.

Публичная механика. Семейство cookie — _px, _pxhd, _pxvid, где _px — короткоживущий сессионный токен, _pxhd — более долгоживущее значение заголовка, а _pxvid — идентификатор посетителя. Челлендж основан на JS, по паттерну похож на DataDome. Поведенческие сигналы весят тяжелее, чем у некоторых других вендоров, — движения мыши и тайминговые паттерны явно входят в модель.

Где встречается PerimeterX: Supreme, StubHub, тикетинговые платформы и длинный хвост e-commerce. Кроссовочные дропы исторически тоже использовали PerimeterX, хотя некоторые мигрировали.

Стратегия по прокси из нашей истории тикетов. Мобильные пулы, как правило, хорошо держатся против PerimeterX. Ротация резидентных — то есть агрессивный скрапинг в стиле «новый IP на каждый запрос» — как правило, быстро роняет скор, потому что поведенческий слой PerimeterX флагует отсутствие непрерывности сессии. Sticky-резидентные или sticky-мобильные сессии, где IP держится несколько минут, набирают лучше. Это совпадает с более широким отраслевым паттерном «меньше ротации, больше похожести на человеческую сессию» против вендоров, которые весят поведение.

Конкретные горячие тезисы про внутренности PerimeterX — точные значения полей cookie, точные детали обхода челленджа — мы намеренно держим расплывчатыми. Слияние с HUMAN изменило достаточно внутренней кухни, чтобы любое конкретное утверждение имело короткий срок годности. Стабильный совет: mobile sticky, residential sticky, замедлите ротацию и заботьтесь о непрерывности сессии.

Queue-it

Queue-it — белая ворона в этом списке, потому что это не антибот в том же смысле, что остальные. Это виртуальная комната ожидания. Различие важно, и многие клиенты его путают.

Антибот пытается идентифицировать и заблокировать автоматизированный трафик. Queue-it, по сути, всё равно, бот вы или нет. Его волнует пропускная способность. Его задача — стоять перед сайтом, который не выдерживает пиковую нагрузку (Ticketmaster на крупном дропе, портал госуслуг в сезон записи, запуск лимитированного продукта), и выстраивать всех — людей и ботов — в очередь в комнате ожидания. Вы ждёте. Вы получаете токен. Токен пропускает вас на настоящий сайт на некоторый промежуток времени. Затем он истекает.

Публичная механика. Queue-it при входе устанавливает цепочку cookie, которая включает токен позиции. Ваша позиция в очереди привязана к этому токену плюс вашему IP. Сайт по таймеру опрашивает API Queue-it, чтобы проверить, не подошла ли ваша позиция. Когда она подходит, вы получаете redirect-токен, доказывающий, что вы ждали, и вышестоящий сайт вас принимает.

Поскольку позиция в очереди привязана к IP, стратегия по прокси здесь противоположна тому, что работает против большинства антибот-вендоров. Агрессивная ротация — дефолтный режим для резидентного скрапинга — активно вам вредит. Каждый новый IP начинает новую позицию в очереди. Вы уходите в конец строки. Клиенты, которые приходят с менталитетом Cloudflare или DataDome и пытаются взять Queue-it в лоб высокой ротацией, оказываются в худшей позиции, чем если бы просто отстояли очередь как человек.

Работающий паттерн — sticky-сессии. Длинные sticky-сессии на ISP или mobile, удерживающие один и тот же IP на всю длительность очереди, — вот на чём, по нашим наблюдениям, клиенты останавливаются для тикетинга и дропов. Mobile хорош, потому что операторские IP не сильно штрафуются; ISP хорош, потому что IP стабильны и «тихие». Mobile sticky-сессии всплывают в тикетах поддержки тикетинговых клиентов чаще любого другого типа пула.

Есть и многослойный паттерн. Некоторые сайты стекают Queue-it перед Akamai или Cloudflare. Сначала вас ставят в очередь, а затем, после прохождения очереди, включается антибот-слой. Такой стек означает, что вам нужен прокси, переживающий оба слоя: достаточно sticky, чтобы удержать позицию в очереди, и достаточно чистый, чтобы пройти бот-скоринг после. Mobile, как правило, оказывается ответом, потому что силён по обеим осям.

Пост с глубоким разбором Queue-it разберёт цепочку токенов, частоту опроса и типичные ошибки, которые мы видим у клиентов, пытающихся проскочить очередь.

Kasada

Kasada — самый маленький вендор в этом списке по количеству развёртываний, но они растут и при этом существенно отличаются от остальных.

Продукт строится вокруг клиентского WebAssembly-челленджа. Когда вы заходите на сайт под защитой Kasada, ответ включает небольшую WASM-полезную нагрузку, которая выполняется в браузере. WASM выполняет вычислительную задачу — proof of work, фингерпринтинг, проверки окружения — и выдаёт токен. Токен отправляется обратно, валидируется на стороне сервера и пропускает запрос.

Большое архитектурное отличие: Kasada весит клиентское доказательство сильнее, чем репутацию IP. Их публичные материалы прямо об этом говорили. Ставка в том, что вычислительные челленджи труднее подделать в масштабе, чем основанные на фингерпринте, потому что подделать фингерпринт дёшево, а подделать вычисление означает реально корректно прогнать WASM.

Где встречается Kasada: банки ANZ (Westpac, ANZ и другие их использовали), Twitch, часть госуслуг. Охват плотный в Австралии и растущий в корпоративном сегменте США.

Стратегия по прокси здесь необычная. Поскольку Kasada менее чувствителен к IP, чем Cloudflare или DataDome, бюджетные резидентные пулы — которые жёстко проваливаются против IP-ориентированных вендоров — могут реально работать против целей под Kasada, если WASM-челлендж решается корректно. Узкое место смещается с прокси на солвер.

Сторона солвера — более трудная часть. WASM динамически обфусцируется и ротируется. Существуют коммерческие сервисы-солверы, которые обрабатывают токены Kasada, и есть open-source-попытки, которые работают какое-то время, пока Kasada не обновит обфускацию. Мы не продаём солверы; мы продаём прокси. Но мы это упомянем, потому что у клиентов, которых мы видим проваливающимися против Kasada, обычно неверная ментальная модель — они тратятся на премиальные резидентные, ожидая результатов в стиле Cloudflare, тогда как деньги должны были уйти на мощность солвера.

Глубокий разбор охватит структуру челленджа Kasada, типичный ландшафт солверов и то, как по кодам ответа понять, в чём провал — в IP, фингерпринте или токене.

Что это значит для выбора прокси

Ошибка, которую совершают люди, — искать взаимно-однозначное соответствие. «Cloudflare использует резидентные. Kasada использует датацентровые. Akamai использует мобильные». Так это не работает.

Более полезная рамка — две оси: сколько веса вендор кладёт на репутацию IP и сколько — на фингерпринт клиента и решение челленджей.

IP-ориентированные вендоры: Cloudflare Bot Management, DataDome, Akamai BMP (в основном), PerimeterX. Против них бренд прокси, который вы покупаете, по-настоящему имеет значение. Бюджетный пул провалится там, где премиум-пул пройдёт, при прочих равных. Разница в репутации IP реальна. Вот где наша страница сравнения отрабатывает своё — соотношение цена/качество по 14 брендам действительно сдвигает долю успеха против IP-ориентированных вендоров.

Фингерпринт-ориентированные вендоры: Kasada, части compute-proof-слоя Akamai, части Turnstile у Cloudflare. Против них бренд прокси имеет меньшее значение, а сторона клиента — TLS-фингерпринт, browser stealth, солвер челленджа — большее. Клиенты, которые покупают здесь дорогие резидентные, платят не за тот слой.

Queue-it — своя отдельная категория. Это вообще не антибот. Правильный ответ — sticky-сессии, независимо от бренда. Mobile sticky и ISP sticky оба годятся. Премиальная цена здесь мало что вам даёт.

Что касается гео-ракурса — когда целевой сайт волнует, из какой страны IP, поверх бот-детекции, — пост 14 брендов разбирал практические лимиты гео-локинга по каждому бренду. Против IP-ориентированных антибот-вендоров, которым вдобавок важно гео (а это почти все они для контента с региональными ограничениями), оба слоя накладываются друг на друга, и с того поста стоит начать.

Для трафика ИИ-агентов и потоков на базе headless-браузера действует та же логика. TLS-фингерпринт и поведение агента важны не меньше IP. Кидать премиальные прокси на агента, который фингерпринтится как автоматизация, его не спасёт.

Для линейки продуктов ISP сценарий — это sticky-золотая середина: чище, чем ротационные резидентные, более sticky, чем мобильные, дешевле за гигабайт, чем премиальные резидентные. Хорошо против вендоров, которым умеренно важно качество IP, но которые не наказывают стабильную сессию.

Что дальше в этой серии

Этот опорный пост охватывает шесть вендоров на уровне, нужном для выбора прокси. Каждый вендор получит свой пост с глубоким разбором в ближайшие недели. Текущий план, по порядку:

• C1: Обход Cloudflare — механика BotScore, внутренности Turnstile, что на самом деле проверяет cf_clearance
• C2: DataDome — многослойный скор, поведенческие сигналы, что триггерит JS-челлендж
• C3: Akamai BMP — структура sensor data, внутренности cookie _abck, цепочка sec-cpt
• C4: PerimeterX (HUMAN) — текущая цепочка cookie, поведенческий фингерпринтинг, изменения после слияния
• C5: Queue-it — механика токенов, частота опроса, стратегия sticky-сессий
• C6: Kasada — структура WASM-челленджа, ландшафт солверов, когда выбор прокси перестаёт иметь значение

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