上了 WAF 还是挡不住爬虫？规则型防护与行为型防护的边界

直接回答： WAF 判断的是「这个载荷像不像已知攻击」，Bot 防护判断的是「这个调用方像不像真实用户」。能穿过 WAF 的流量通常格式完全正确，而这正是载荷检查无从下手的原因。套餐之间的差异主要不在拦截多少，而在你能拿什么字段写规则：Pro 与 Business 只能看到 bot 分组，只有购买了 Bot Management 的 Enterprise 才能把 1–99 的数值评分、JA3/JA4 指纹、bot 标签写进自定义规则。Bot Management 是由客户团队添加到 Enterprise 套餐上的付费产品，升套餐并不自带。

两件事要分开：WAF 判的是载荷，Bot 防护判的是调用方

两套系统检查的是同一个请求，但看的证据不同。

	WAF	Bot 防护
判断的问题	这个载荷像不像已知攻击？	这个调用方像不像真实用户？
依据	注入语法、利用载荷、扫描器指纹、请求异常	TLS 与 HTTP 指纹、会话行为、网络信誉、无头浏览器信号
产出	命中一条已知恶意特征的规则	1 到 99 的评分，以及分类标签
擅长	利用、注入、已知漏洞探测	语法上与真实客户端无法区分的自动化
不擅长	拿着正确凭证、行为正常的自动化	携带真实利用载荷的攻击

执行顺序上有一点是前提：两者叠加，不是替换。开启 bot 类产品之后，托管规则仍然在做它被写出来要做的那件事；反之，bot 类产品也不会降低你在注入和利用类攻击上的暴露面。

这个区分之所以有实用价值，是因为真实滥用流量在日志里长这样：撞库跑的是发往正确端点的正确 JSON，频率也合理；比价爬虫发的是格式完好的 GET，只是 User-Agent 在轮换；薅羊毛脚本按正常用户的顺序走完注册流程。三类流量里都没有可供 WAF 特征匹配的攻击载荷——能区分的证据在谁在调用，而不在他发了什么。

规则型手段为什么在分布式低频流量面前失效

三个结构性原因，没有一个是靠多加几条规则能解决的：

1. IP 已经不是稳定身份。 住宅代理池、运营商 NAT、廉价的云主机轮换，让一个操作方能拿出成千上万个源地址。任何以源 IP 为键的控制手段——包括限流——都可以被摊薄到阈值以下。
2. 请求本身是合法的。 请求头正确、JSON 正确、方法正确、间隔合理，没有畸形内容可匹配。
3. 阈值覆盖不了低频慢速。 攻击者每小时要 2 万次请求、手上有 5 千个地址，平均每个地址每小时 4 次。把全局阈值压到能抓住它的程度，会先挡住企业出口 NAT 后面的真实用户。

于是「规则能挡什么、漏什么」就有了清晰的形态：

自动化类型	规则型手段能挡什么	漏掉什么
简单脚本（curl、requests）	请求头与 TLS 异常、没有执行 JavaScript	基线检查开着的话漏得很少
无头浏览器（Playwright、Puppeteer）	能挡一部分，JavaScript Detections 专门针对这类	改过指纹、配置得当的驱动
住宅代理轮换	几乎挡不住——IP 轮换快过任何阈值	几乎全部；单地址频率看起来完全正常
真机群控与黑产农场	几乎挡不住——真实浏览器指纹、真实设备	几乎全部；只能靠行为信号与业务信号区分

下面两行才是升级决策真正发生的地方。如果你的事故流量属于前两行，多写规则有用；如果是后两行，规则本身就是错的仪器，因为你要的证据既不在载荷里，也不在地址里。

各套餐到底给了什么

可用性以 Cloudflare 的 bot 文档按套餐给出的说明为准，实际以你的控制台为准。

	Free	Pro	Business	Enterprise（未购 Bot Management）	Enterprise（已购 Bot Management）
产品	Bot Fight Mode	Super Bot Fight Mode	Super Bot Fight Mode	Super Bot Fight Mode	Bot Management
官方描述的范围	来自云主机与无头浏览器的简单 bot	简单 bot 与无头浏览器	简单 bot 与无头浏览器	简单 bot 与无头浏览器	启发式、机器学习与 JavaScript Detections
控制方式	Cloudflare 下发计算密集型挑战，作用于域名全部流量	可自选放行、拦截或挑战	可自选放行、拦截或挑战	可自选放行、拦截或挑战	完整的规则表达式字段
分析能力	—	Bot Report 中的有限分析	Bot Report 中的有限分析	Bot Report 中的有限分析	细粒度评分、bot 标签、检测 ID

文档里有两句话值得直接引用，因为它们决定架构：

• Bot Fight Mode 作用于域名下的全部流量。 Free 套餐没有按路径的控制能力，缓解手段是 Cloudflare 下发的计算密集型挑战。作为默认值它合理，但对一个接收机器流量的 API 来说很不合适。
• 在 bot settings 里处置「疑似自动」流量，Pro 上不可用。 Cloudflare 自己的分工表把这项能力标注为需要 Bot Management。Free、Pro、Business 客户在 Bot Analytics 里看到的是分组——自动程序、疑似自动、疑似真人、已验证 bot——而更精细的那件工具是付费产品。

真正的差异：你能拿什么字段写规则

团队比较套餐时常问「哪个挡得更多」，这个比较轴是错的。真正的选择轴是你的规则能用到哪些字段。

Security Settings 里的 bot settings 会自动处理一批场景，Cloudflare 也明确列出了哪些场景必须改用自定义规则：

能力	bot settings 是否处理	是否需要自定义规则
拦截或挑战「确定自动」流量	是	仅在需要按路径区分或调整阈值时
拦截或挑战「疑似自动」流量	Pro 上不可用	是，需要 Bot Management
放行或拦截已验证 bot	是	不需要
拦截 AI 爬虫	是	仅在需要针对单个 AI 爬虫时
保护静态资源	是	不需要

所以实际触发升级的不是「我们被打了一」，而是「不同路径需要不同处置，而且阈值要由我们来定」。域名级的开关无法表达「/login 要比 /catalogue 更严」，也无法表达「评分 2–29 之间挑战、命中 1 就拦截、/public/* 放行已验证爬虫」。

解锁这些规则的字段是被门控的。Cloudflare 明确写道：细粒度 bot score 只对购买了 Bot Management 的 Enterprise 客户提供，其余客户只能通过 Bot Analytics 里的 bot 分组获取这层信息。限流规则里的 Bot Management 字段受同样的门控——字段表里把它标注为「仅限已购 Bot Management 的 Enterprise」。

评分是怎么算出来的，以及为什么它不是结论

bot score 的取值是 1（Cloudflare 相当确定请求是自动化的）到 99（相当确定来自真人）。官方给出的分组如下：

分组	取值范围
未计算	0
自动程序	1
疑似自动	2–29
疑似真人	30–99
已验证 bot	非恶意的自动化流量

四个细节决定你的规则是否按预期工作：

• 评分为 0 不等于安全。 它表示 Bot Management 没有评估这条请求——可能是 Cloudflare 内部服务请求，也可能是请求在 Bot Management 执行前就被其他功能（例如 Redirect Rules）重定向或处理掉了。0 应该理解为「没有证据」，而不是「是真人」。
• 检测引擎属于 Enterprise Bot Management。 启发式拿已知恶意指纹库做匹配，高置信度判定给 1，Cloudflare 还在评估流量重叠时偶尔给 29；Adaptive Intelligence 是承载大部分判定的机器学习模型，重新训练的频率更高而不是按固定周期；JavaScript Detections 针对无头浏览器；Anomaly Detection 仍在，但 Cloudflare 已宣布弃用且不再接入新客户。
• 评分会漂移。 模型更新不会改你的配置，但会改评分，所以按评分阈值写的规则要定期复核。
• __cf_bm cookie 会在会话内平滑评分以降低真实用户的误杀。按单条请求而不是按会话写规则，噪声会明显更大。

这正是处置梯度要先挑战后拦截的原因：挑战把一个概率判断变成可观察的结果，代价只是调用方多一次往返。

五条信号：规则型手段已经用尽

出现两条以上时，才值得讨论升级：

1. 限流被摊薄。 你调高阈值，流量跟着涨；你调低阈值，运营商 NAT 或企业出口后面的真实用户先投诉。
2. 流量分布式、慢速。 总量可观，单地址量低于你能设定的任何阈值。
3. 特定端点被定向。 登录、注册、找回密码、领券、搜索、价格页之所以招自动化，是因为每次调用都有价值。通用规则表达不出这种差异。
4. 粗放规则已经在伤害转化。 你只能按国家、ASN 或 User-Agent 家族整体拦截，因为那是你仅有的粒度。
5. 你需要按路径分档处置，而手上只有域名级开关。

如果一条都不成立，诚实的结论是：把现有控制手段配置好，比买新产品更有用。

从 bot settings 开始的落地顺序

第一步：先开启 Security Settings 里的基线能力。 确定自动的流量、已验证 bot 处置、AI 爬虫控制、静态资源保护，这些都自动生效，不需要自定义规则。先做这一步，再谈写规则。

第二步：只在基线表达力不够的地方补自定义规则。 Cloudflare 自己的建议是，自定义规则用于「按路径区分」或「调整阈值」的场景。一条作用于 /login、动作为挑战的规则，和一条全域名拦截是两种完全不同的工具。

第三步：沿处置梯度往上走，不要直接跳到顶端。 放行 → 记录 → 挑战 → 拦截。套餐支持时先用 Log 跑一遍，看清它会抓到什么，再升级动作。注意 Free、Pro、Business 的 WAF 自定义规则没有 Log 动作，它是 Enterprise 才有的——这让「先观察后执行」的节奏在这些套餐上更难实现，规划之前值得先知道。

第四步：把限流放在有价值的位置，并尊重计数器的工作方式。 限流规则按数据中心计数，所以它是「每个接入点」的控制而不是全局上限；Cloudflare 也说明从检测请求到更新计数之间存在最多几秒的延迟。可用维度随套餐扩展：Free 与 Pro 只有 IP；Business 起支持 IP 与带 NAT 支持的 IP；订阅 Advanced Rate Limiting 后才有 query、header、cookie、ASN、国家、path、JA3/JA4 指纹、JSON 字段值与 body。

第五步：应用层控制不要撤。 Bot 防护判断的是调用方像不像人，它判断不了这个调用方能不能读某个对象、这个租户本月还能用多少、这次注册是不是带来了一个真实客户。这些留在你自己的代码里——判据层次可以参考如何识别正常用户、恶意爬虫和自动化 Bot。

Bot 管理解决不了什么

• 业务风控。 薅羊毛、虚假交易、推荐返利作弊、团伙串谋都是业务逻辑问题：请求可能来自真实设备甚至真人，判据在账号历史、资金关系与活动规则里，边缘信号只能作为输入。
• 应用层身份与配额。 对象级授权、按租户的上限、成本闸门属于你的系统；按数据中心累加的限流计数器不是全局配额。
• 零误杀。 任何行为判断都带置信度。挑战与 Turnstile 是缓冲手段，不是保证。
• 你自己规则带来的 SEO 副作用。 Cloudflare 明确提示，把限流规则施加到已验证 bot 上可能影响搜索引擎优化。
• 源站暴露。 如果源站 IP 从公网可达，自动化可以完全绕开边缘——那是另一类问题，有另一套解法。

常见问题

升级到 Enterprise 就自动包含 Bot Management 吗？ 不包含。Bot Management for Enterprise 是由 Cloudflare 客户团队添加到 Enterprise 套餐上的，升 zone 套餐并不会自带。未购买 Bot Management 的 Enterprise 拿到的是 Super Bot Fight Mode，和 Business 拿到的是同一个产品。

有了 Bot Management 还需要 WAF 吗？ 需要。两者回答不同问题，在同一个请求上分别执行。托管规则继续覆盖注入、利用和已知漏洞探测，这些都不是 bot 检测被设计来替代的。

bot score 到多少该拦？ 没有通用阈值。官方分组是起点——1 是自动程序、2–29 是疑似自动、30–99 是疑似真人——稳妥的做法是对 2–29 区间挑战、命中 1 才拦截，再按路径微调。两点要注意：评分 0 表示请求未被评估，不等于安全；评分会随模型重训漂移，按评分写的规则要定期复核。

Business 套餐能在限流规则里用 bot score 吗？ 限流规则里的 Bot Management 字段在文档中标注为「仅限已购 Bot Management 的 Enterprise」。Business 上可用的计数维度是 IP 与带 NAT 支持的 IP，表达式可用字段是 host、URI、path、完整 URI、query、方法、源 IP、User Agent 与已验证 bot。

拦 bot 会影响搜索排名吗？ 有可能。Cloudflare 明确提示，把限流规则施加到已验证 bot 上可能影响 SEO，而已验证 bot 里包含驱动搜索引擎的爬虫。已验证 bot 建议通过 bot settings 处置，只在需要针对单个爬虫时才写自定义规则。

什么情况下 Bot Management 不值得买？ 你的流量是简单脚本和无头浏览器、JavaScript Detections 与 Super Bot Fight Mode 已经能处理；没有被定向的高价值端点；损失来自任何流量分类都识别不了的业务滥用。这几种情况下，范围更准的自定义规则、一条挑战与拦截的梯度、以及按路径的限流，能带来的收益比这个产品更大。

相关阅读

• 如何识别正常用户、恶意爬虫和自动化 Bot？
• 如何防止恶意爬虫批量抓取网站数据？
• AI 应用如何防止用户批量注册和薅免费额度？
• 海外网站遭遇 CC 攻击怎么办？

如果你在判断行为型检测对自己的流量是否划算，最有用的起点是你自己的日志：哪些端点被定向、单地址频率是多少、现有规则已经抓到了什么——和我们一起评估现有架构。