DataDome vs Akamai vs Cloudflare 机器人管理对比(2026)

我们分销 hellworld.io 的全线产品——14 个住宅代理品牌(轮换、按 GB 计费)、3 个 4G 移动代理池(FP-Mobile / ET-Mobile / HD-Mobile)、静态 ISP(按 IP 月付),以及2 个无限量套餐(无限 ISP / 无限住宅)。每一款我们都赚一份差价。所以当我们写"哪种代理能对付哪家反机器人厂商"时,有句实话得先讲清楚:我们在这场较量里并没有偏向谁。从我们这儿买 Lumi 的客户,付的零售价和直接去原厂买是一样的;买 F-Oxylab 或者用 FP-Mobile 的客户也一样。我们的动机很简单——让你尽快找到对的工具,别来回折腾,继续续费。读这篇文章时,把这层立场记在心里。

这是我们 2026 系列的第二篇。第一篇是 14 个品牌实测,对比的是代理网络本身。这一篇看的是篱笆另一侧:那些代理正试图穿过的反机器人系统。后续文章会逐家深入剖析。这篇就当是一张地图。

为什么 2026 年"反机器人"比"WAF"是更有用的视角

不少采购指南到现在还在谈 WAF。WAF 指的是 Web 应用防火墙。它是审查 HTTP 载荷的那一层,要问的是:这是 SQL 注入吗?是 XSS 字符串吗?是路径穿越吗?有用,但和代理客户实际面对的问题基本上是两码事。

反机器人是另一层。它不在乎你的请求体是不是无害的,它在乎的是你是谁。具体说就是三件事:你来自的那个 IP 的信誉、你用的浏览器或客户端的指纹,以及你各次请求之间的行为信号。WAF 出现得比机器人经济早。反机器人系统之所以被造出来,正是因为 WAF 分不清爬虫和买家。

对 2026 年的代理客户来说,WAF 很少是问题所在。我们见到的几乎每一张"我的代理用不了"的工单,问题都出在反机器人,而不是 WAF。HTTP 请求本身没毛病。是 IP 被打了低分,或者 TLS 指纹和 user-agent 对不上,又或者 cookie 链里没带上站点期望的挑战令牌。这些都不是经典意义上的防火墙行为。

所以你挑代理的时候,目标站点上的 WAF 基本是噪声。站在它前面的反机器人厂商,才是真正起作用的变量。这就是本指南要讲的东西。

真正要紧的 6 家厂商

市面上的反机器人产品有几十种。其中 6 家覆盖了我们客户实际撞上的绝大多数高防护流量。名单如下:

厂商	你会在哪儿遇到	检测方式	代理策略(大致)
Cloudflare Bot Management + Turnstile	无处不在——CDN 覆盖最广	IP 信誉 + JS 挑战 + TLS	首选住宅;数据中心常失败
DataDome	电商、媒体、分类信息	多层评分:IP + 指纹 + 行为	移动代理最稳;低价池常失败
Akamai Bot Manager (BMP)	球鞋、航司、银行、大型零售	传感器数据载荷 + cookie 链	球鞋用移动 / ISP;住宅参差不齐
PerimeterX (HUMAN)	Supreme、StubHub、票务	_px cookie 家族 + JS + 行为	移动表现强;住宅轮换常偏弱
Queue-it	Ticketmaster、限量发售、政务服务	虚拟排队室(不是反机器人)	黏性 ISP / 黏性移动;轮换有害
Kasada	澳新银行、Twitch、政务	WASM 客户端挑战	对 IP 不太敏感;解算器更关键

关于这张表,有两点提醒。第一,"代理策略"是我们从工单里看到的大致规律,不是保证。每家厂商都会按客户逐个调配置。Nike 的 Akamai 不等于 Delta 的 Akamai。第二,厂商之间的界限是模糊的。站点叠加两套系统是家常便饭——前面 Cloudflare、后面 DataDome,或者商城用 Akamai、结账用 PerimeterX。"我该用什么代理"的正确答案,取决于实际拦你的是哪一层,而这是逐站变化的。

下面几节逐家来看。

Cloudflare Bot Management 与 Turnstile

Cloudflare 是这头大象。它挡在现代网络一大块流量的前面,它的 Bot Management 产品是大多数代理客户最先撞上的那一个。

先讲公开的机制。Cloudflare 给每个请求打一个 0 到 99 的 BotScore。按 Cloudflare 自己的文档描述,1 表示几乎肯定是机器人,99 表示几乎肯定是人类,中间地带则是不确定。站点运营方在这个分数之上写规则:低于 30 拦截、低于 60 挑战、高于 80 放行,诸如此类。站点的 WAF 和限流器消费这个分数;Cloudflare 本身并不决定拦什么,是客户决定的。

这个分数由一堆信号叠出来。IP 的 ASN 信誉是一个输入。JA3 / JA4 TLS 指纹是另一个。HTTP/2 帧排序。浏览器端跑完后回报的 JS 挑战。一个会话期内的行为模式。这些都不单独起决定作用——Cloudflare 把它们综合起来。

Turnstile 是看得见的那块挑战界面。它就是在很多站点上取代 reCAPTCHA 的那个小组件,2022 年作为 v1 推出,2025 年更新到 v2。Turnstile 通过后,浏览器会拿到一个 cf_clearance cookie 为这个会话背书。这个 cookie 寿命很短,且绑定指纹,所以把另一个浏览器的 cf_clearance 拿来复用,基本就是以失败收场的那类操作。

现在说代理这一面。Cloudflare 公开声明,数据中心 ASN 默认携带更高的机器人风险——这写在他们自己的营销材料里,不是我们编的。所以一个来自已知数据中心 IP 的请求,在任何其他信号落地之前,就先背上了分数上的劣势。住宅和移动 IP 起点更高。ISP 代理在技术上是数据中心托管、但挂在住宅 ASN 上的,落在两者之间,且各供应商表现不一。

在我们的客服工单里,Cloudflare 防护的目标站是我们见得最多的那一类"为什么我的代理不灵"。套路反复出现。客户买了个低价住宅池去爬一个 Cloudflare 挡在前面的站,撞上挑战,换成高级池,过了。或者他们本来就用着高级住宅,问题其实出在 TLS 指纹上,而不是 IP。这两样 Cloudflare 都会惩罚。

我们通常的支持流程是这样的。如果客户在 Cloudflare 上栽了,我们先问他的 HTTP 客户端是不是发出了真实的浏览器 TLS 指纹。一个用默认 urllib3 的 python requests 脚本,不管 IP 多干净,指纹一看就是自动化的。如果指纹这边处理好了,那 IP 这一层才有意义,这时我们会倾向于 Lumi 或 F-Oxylab 住宅池——这两个我们看到客户重试切换进去的次数更多。两者都能在我们的代理对比页里找到链接。

Turnstile 本身比单看 BotScore 要难。它在浏览器里跑 JS、采集熵值、发出一个令牌。要跳过这个挑战,要么在真实浏览器里渲染它,要么用第三方解算器,要么走一个已经持有有效 cf_clearance cookie 的会话。严格来说,这几样都不是代理的问题——它们是客户端的问题。代理给你的是 IP 信誉;客户端给你的是挑战令牌。我们见过客户把这两者混为一谈,问题出在他们的无头浏览器配置上,却怪到代理头上。

关于 Cloudflare 绕过策略的深度剖析,本系列后面会单开一篇。

DataDome

DataDome 是我们工单里第二常见的厂商,尤其是爬电商、分类信息和媒体的客户。

他们的公开文档描述了一种多层评分方法。按 DataDome 自己材料里的说法,这些层是:IP 信誉、浏览器指纹、行为信号,以及在这之上的机器学习。每一层都喂给一个分数。站点看到的是一个裁定结果——放行、挑战、拦截——而看不到内部细节。

可见的那个 cookie 是 datadome。它在成功通过后被设置,并一直保留到分数掉下去为止。混杂了干净信号和脏信号的会话,往往会在中途丢掉这个 cookie,表现出来就是"我前一分钟还好好的,现在不行了"。

DataDome 的挑战是一个 JS 插页。它运行、采集,然后要么发放 cookie,要么弹出验证码。验证码本身是下游的症状——等你看到它的时候,分数早就把你压到放行阈值以下了。

在代理这一面,行业大致的共识是:对付 DataDome,移动运营商 IP 的得分通常优于住宅,住宅又通常优于数据中心。这不是因为 DataDome 明确把运营商加进了白名单——而是因为运营商 IP 是和数百万合法用户共享的,共享评分会向它们倾斜。我们不会在这上面给出一个具体数字。这个规律在各家厂商的博客、爬虫论坛,以及我们自己的客户群里都反复出现。

低价住宅池是我们见到的那种稳定的失败模式。客户注册了一个便宜的池子,指向一个 DataDome 目标,请求几乎当即就失败了。便宜池子的 IP 回收得很快,常常被很多跑激进爬虫的客户共用,IP 信誉层直接把它们标记掉。同一个客户换到高级套餐,成功率立刻跳升。这种跳升值不值那个差价,取决于量——做一次性的爬取,有时便宜池加重试就够了;但跑生产级数据管道,便宜池在失败请求上烧掉的钱,会比高级池本来要花的还多。

对于长期运行的 DataDome 任务,我们一般会把客户指向移动池或高级住宅。两者都列在我们的住宅代理和移动代理产品页上。在两者之间怎么选,主要看请求量和成本上限。

Akamai Bot Manager (BMP)

在大型零售、航司和银行领域,Akamai 是重量级选手。如果你在 Nike、Adidas、Footlocker、Delta、United 或大多数主流银行上爬数据或下单,你面对的就是 Akamai。

它的技术面在公开的逆向工程文章里有详尽记录。Akamai BMP 通过 JS 采集一大坨浏览器指纹数据——鼠标移动、屏幕尺寸、插件枚举、时序、指针事件,无所不包。这坨数据被序列化、base64 编码,以"传感器数据"(sensor data)的形式回传到服务器。服务器给它打分,并设置 _abck cookie。

_abck cookie 的结构,球鞋圈已经拆解了好几年。cookie 值里面的 sec~ 字段就是那个可见的裁定。sec~-1~ 表示传感器校验失败。sec~7~(以及那个区间内的其他正整数)表示传感器通过了。还有别的字段,Akamai 也会轮换这些含义,但 -1 与正整数的区分足够稳定,解算器开发者就拿它当判据。

另一个信号是 sec-cpt 头部链。在某些挑战点之后,Akamai 会要求后续请求带上一个头部,证明完成了一个计算工作量证明。跳过这条 cpt 链,意味着即便最初的传感器通过了,后面的检查点也会失败。

Akamai 的代理策略高度依赖目标。对于 Akamai 防护的限量发售,球鞋圈已经把移动代理和 ISP 代理定为默认选择——那边的共识积累了好些年,我们不去跟它争。我们的球鞋代理页就体现了这一点,把移动和 ISP 品牌排在最前面。

对于非球鞋的 Akamai 目标——航司、银行、一般零售——情况就更模糊了。移动依然管用。住宅在有些目标上行、有些不行。数据中心几乎到处碰壁。ISP 是个中间地带,对于那些 Akamai 的 IP 层权重适中但不占主导的站点,表现良好。

要记住一点:Akamai BMP 的 IP 层只是众多输入之一。一个完美的 IP 配上一个坏掉的传感器载荷,照样失败。我们见过客户在高级 ISP 上花了钱,还是被拦——因为他们的无头浏览器没生成有效的传感器数据。代理是必要的;代理不是充分的。

本系列后面会有一篇更深入的 Akamai 文章。我们会讲到传感器结构、cpt 链,以及典型的解算器工具链长什么样。

PerimeterX (HUMAN)

PerimeterX 几年前和 HUMAN Security 合并了。这个产品在多数语境下仍以 PerimeterX 的名义出现,cookie 还是 _px*,但母公司的品牌已经转过去了。内部细节也随之变动,这一节我们会讲得保守些,因为合并后的产品迭代还在进行中。

公开机制。这个 cookie 家族是 _px、_pxhd、_pxvid,其中 _px 是短寿命的会话令牌,_pxhd 是一个寿命更长的头部值,_pxvid 是访客 ID。挑战基于 JS,模式和 DataDome 类似。行为信号在这里的权重比在某些其他厂商那里更重——鼠标移动和时序模式被明确纳入了模型。

你会在哪儿遇到 PerimeterX:Supreme、StubHub、票务平台,以及一长串电商。球鞋限量发售过去也用 PerimeterX,不过有些已经迁走了。

从我们的工单历史看代理策略。移动池对付 PerimeterX 通常扛得住。住宅轮换——也就是那种激进的每请求一 IP 式爬取——往往会让分数快速下滑,因为 PerimeterX 的行为层会标记出会话连续性的缺失。黏性住宅或黏性移动会话,即 IP 保持几分钟不变的那种,得分更好。这和更广义的行业规律一致:对付那些看重行为的厂商,“少轮换、更像真人会话”。

关于 PerimeterX 内部的具体论断——cookie 字段的确切含义、绕过挑战的确切细节——我们有意保持含糊。HUMAN 合并之后,内部变动够多,任何具体说法的保鲜期都很短。稳妥的建议是:移动黏性、住宅黏性,放慢轮换,在意会话连续性。

Queue-it

Queue-it 是这份名单里的异类,因为它和其他几家不是同一种意义上的反机器人。它是一个虚拟排队室。这个区别很要紧,很多客户搞错了。

反机器人试图识别并拦截自动化流量。Queue-it 其实不太在乎你是不是机器人,它在乎的是吞吐量。它的活儿是挡在一个扛不住峰值负载的站点前面——大型发售时的 Ticketmaster、报名季的政务服务门户、限量产品发布——把所有人,不管是人还是机器人,统统排进一个等候室。你排队。你拿到一个令牌。这个令牌让你在一段时间窗口内进入真正的站点。然后它过期。

公开机制。Queue-it 在你进入时设置一条 cookie 链,里面包含一个位次令牌。你在队列中的位置和这个令牌加上你的 IP 绑定在一起。站点按定时器轮询 Queue-it 的 API,检查你的位次是不是轮到了。轮到时,你会拿到一个重定向令牌证明你排过队,上游站点便接纳你。

正因为队列位次是和 IP 绑定的,这里的代理策略和对付大多数反机器人厂商的做法恰好相反。激进轮换——住宅爬取的默认模式——在这里会主动害你。每个新 IP 都开启一个新的队列位次。你被甩到队尾。那些带着 Cloudflare 或 DataDome 思路、想靠高轮换强攻 Queue-it 的客户,最后的处境比老老实实像真人那样排队还要糟。

管用的套路是黏性会话。在 ISP 或移动上跑长时间黏性会话,在整个排队期间保持同一个 IP,这是我们看到票务和限量发售客户最终采用的做法。移动好,是因为运营商 IP 不会被重罚;ISP 好,是因为这些 IP 稳定又安静。在票务客户的工单里,移动黏性会话出现的频率比任何其他池类型都高。

还有一种叠层套路。有些站点把 Queue-it 叠在 Akamai 或 Cloudflare 前面。你先被排队,过了队之后,反机器人层再启动。这种叠加意味着你需要一个能扛过两关的代理——黏到能守住队列位次,又干净到能通过之后的机器人评分。移动往往是答案,因为它在这两根轴上都强。

Queue-it 的深度剖析篇会讲到令牌链、轮询节奏,以及我们看到客户在试图跳过队列时常犯的错误。

Kasada

按部署数量算,Kasada 是这份名单里最小的厂商,但它在成长,而且和其他几家有实质性的不同。

这个产品的核心是一个客户端的 WebAssembly 挑战。当你访问一个 Kasada 防护的站点时,响应里会带上一小段在浏览器里运行的 WASM 载荷。这段 WASM 做一项计算任务——工作量证明、指纹采集、环境检查——并产出一个令牌。令牌被回传、在服务端校验,然后放行请求。

最大的架构差异:Kasada 给客户端证明的权重高于 IP 信誉。他们的公开材料对此一直很明确。这一押注背后的逻辑是,基于计算的挑战比基于指纹的挑战更难大规模伪造,因为伪造指纹很便宜,而伪造计算意味着真得把 WASM 正确跑一遍。

你会在哪儿遇到 Kasada:澳新银行(Westpac、ANZ 等用过)、Twitch、一些政务服务。它在澳大利亚布得很重,在美国企业市场也在扩张。

这里的代理策略不太一样。因为 Kasada 不像 Cloudflare 或 DataDome 那样对 IP 敏感,低价住宅池——那些在重 IP 的厂商面前硬碰硬就败下阵的池子——只要 WASM 挑战被正确求解,反倒可能对付 Kasada 目标管用。瓶颈从代理转移到了解算器。

解算器这一边才是更难的部分。WASM 是动态混淆且会轮换的。有处理 Kasada 令牌的商业解算服务,也有开源的尝试,这些尝试在 Kasada 更新混淆之前能管用一段时间。我们不卖解算器;我们卖代理。但我们要提一句这个,因为我们见到的那些在 Kasada 上栽跟头的客户,通常心智模型就错了——他们花钱买高级住宅,指望拿到 Cloudflare 式的结果,而这笔钱本该投到解算器算力上去。

深度剖析篇会讲 Kasada 的挑战结构、典型的解算器版图,以及如何从响应码判断失败到底是出在 IP、指纹还是令牌上。

这对你选代理意味着什么

人们常犯的错,是去找一个一一对应的映射。"Cloudflare 用住宅。Kasada 用数据中心。Akamai 用移动。"事情不是这么运作的。

一个更有用的视角是两根轴:这家厂商在 IP 信誉上压了多少分量,又在客户端指纹和挑战求解上压了多少分量。

重 IP 的厂商:Cloudflare Bot Management、DataDome、Akamai BMP(大体上)、PerimeterX。对付这几家,你买什么品牌的代理是真的有讲究。其他条件不变,低价池失败的地方,高级池能成功。IP 信誉的差别是实打实的。这正是我们的对比页发挥价值的地方——14 个品牌之间的"性价比"确实会改变对付重 IP 厂商时的胜率。

重指纹的厂商:Kasada、Akamai 计算证明层的一部分、Cloudflare Turnstile 的一部分。对付这几家,代理品牌没那么要紧,而客户端这一侧——TLS 指纹、浏览器隐身、挑战解算器——更要紧。在这儿买昂贵住宅的客户,是在为错误的那一层付钱。

Queue-it 自成一类。它根本不是反机器人。正确答案是黏性会话,与品牌无关。移动黏性和 ISP 黏性都行。在这里付高级价钱买不来多少东西。

关于地理这一角度——当目标站点在机器人检测之外,还在乎 IP 来自哪个国家时——14 个品牌那篇逐个品牌讲过实际的地理锁定边界。对付那些既重 IP、又在乎地理的反机器人厂商(对地区锁定内容来说几乎全都是),两层会叠加放大,而那篇正是该从那里入手的地方。

对于 AI agent 流量和无头浏览器驱动的流程,同样的逻辑成立。agent 的 TLS 指纹和行为,和 IP 一样要紧。给一个指纹一看就是自动化的 agent 砸高级代理,救不了它。

对于 ISP 产品线,适用场景是黏性的中间地带:比轮换住宅干净,比移动更黏,每 GB 又比高级住宅便宜。对付那些对 IP 质量略有讲究、但不会惩罚稳定会话的厂商,它很合适。

本系列接下来

这篇支柱文按"足够用来选代理"的颗粒度覆盖了这六家厂商。每家厂商接下来几周都会有自己的深度剖析篇。当前计划,按顺序:

• C1:Cloudflare 绕过——BotScore 机制、Turnstile 内部、cf_clearance 到底校验什么
• C2:DataDome——多层评分、行为信号、什么会触发 JS 挑战
• C3:Akamai BMP——传感器数据结构、_abck cookie 内部、sec-cpt 链
• C4:PerimeterX (HUMAN)——当前的 cookie 链、行为指纹、合并后的变化
• C5:Queue-it——令牌机制、轮询节奏、黏性会话策略
• C6:Kasada——WASM 挑战结构、解算器版图、代理选择何时不再重要

我们大致会按这个顺序发布,但会根据读者的诉求调整优先级。如果有某家厂商你更想先看到,来我们的 Discord 告诉我们。我们每个频道都看,顺序不是定死的。