如何识别正常用户、恶意爬虫和自动化 Bot？

先纠正一个误区：Bot 不等于坏人

类型	典型例子	应该拦吗
搜索引擎爬虫	主流搜索引擎、收录型 AI 抓取器	不该，但要验证身份后放行
商业 API 调用方	合作伙伴、客户系统集成	不该，走独立令牌与配额
可用性与监控	拨测、健康检查	不该，加白名单
恶意爬虫与采集	剧集/商品/内容批量抓取	应该
滥用脚本	刷量、薅额度、撞库、刷票	应该

把「自动化」当成恶意会误伤搜索引擎与合作伙伴；把「自动化」当成无害会让账单和版权一起失控。真正的任务不是分辨人还是机器，而是分辨「已授权的自动化」和「未授权的自动化」。

判据的三层结构

凭据层：你说你是谁。 签名令牌、mTLS 证书、API Key、OAuth 声明。这一层最强，也最容易被工程团队忽略——因为大多数系统的凭据只用于鉴权，不参与风控判定。

环境层：你从什么环境来的。 TLS 指纹（握手参数组合）、HTTP/2 帧序、浏览器环境完整性、是否执行了 JS 挑战。脚本直接发请求时，这些特征与真实浏览器不同，几乎无法靠改 UA 掩盖。Cloudflare 的边缘 Bot 防护采集这类信号并输出评分。

行为层：你在做什么。 请求节奏是否机械均匀、是否只访问生成类端点、会话是否只有开始没有心跳、端点访问序列是否符合真实播放或浏览路径。行为层最难伪造，但需要足够长的观察窗口。

bot score 必须写对的三个细节

1. 分数方向是反的。 bot score 是 1–99 的整数：1 表示 Cloudflare「高度确定该请求是自动化的」，99 表示「高度确定来自人类」。如果把它理解成「自动化置信度」，规则会直接写反。

2. 细粒度分数不是默认可得。 官方文档明确：细粒度 bot score 只对购买了 Bot Management 的 Enterprise 客户开放。其余套餐只能在 Bot Analytics 里看到分组：

分组	分数区间	含义
Not computed	0	Bot Management 未评估该请求（例如被 Redirect Rules 提前处理）；0 不代表安全或人类
Automated	1	高置信度判定为自动化
Likely automated	2–29	疑似自动化
Likely human	30–99	疑似人类
Verified bot	—	已验证的非恶意自动化流量（搜索引擎等）

3. 套餐决定了能怎么用。 Free 套餐是 Bot Fight Mode，只针对云主机与无头浏览器的简单 Bot，动作是「计算密集型挑战」，且按域名全流量生效；Pro 与 Business 是 Super Bot Fight Mode，可自行选择放行/阻断/挑战，但 Pro 的分析能力限于 Bot Report，且**「疑似自动化」这一分组在 Pro 上不可用**；只有 Enterprise 的 Bot Management 订阅才能在自定义规则与 Workers 里使用 bot score、JA3/JA4 指纹、bot tags 与 detection IDs。

三层判据的可靠性对比

判据层	伪造难度	典型绕过方式	建议权重
凭据层	高（需要真凭据）	凭据泄露、共享	高，但只适用于已接入鉴权的接口
环境层	高（需改协议栈）	无头内核、真实浏览器驱动	高，作为主要打分依据
行为层	最高（需模拟真人）	慢速分布式、真人打码	中高，需要观察窗口
来源层（IP/UA）	低	代理池、UA 伪造	低，只作辅助信号

来源层（IP、User-Agent、Referer）几乎是所有团队最先想到、也最不可靠的一层：UA 一行就能改，Referer 由客户端控制，而家庭宽带与移动网络是共享出口。把 IP 当主判据，必然同时产生高误杀和高漏过。

一个可落地的判定顺序

1. 先放行已验证的好 Bot。 主流搜索引擎有可验证的反向 DNS 与公开的抓取声明，验证后加入允许列表；合作伙伴与健康检查走独立令牌或固定出口 IP。这一步的意义是把噪声从判定样本里剔除，后面的阈值才能收紧。

2. 凭据校验。 有令牌就验令牌，没有令牌的请求直接进入下一层判定，而不是直接拒绝。

3. 环境指纹打分。 用边缘采集的信号输出自动化置信度。这一步是主力，但它给出的是概率，不是结论；你当前套餐能拿到的信号粒度决定了这一步能做多细（见上文关于 bot score 的说明）。

4. 行为分析补位。 对中分区域的请求延长观察：请求节奏、端点组合、会话完整性。让可疑流量自己暴露。

5. 分级处置，而不是二选一。 按上面的阶梯执行：先允许可验证者，再对中分区用无感挑战、降级或排队，只有明确恶意才封禁。

另外要记住一个分界：当流量「看起来正常但量太大」，那是配额问题而不是 Bot 问题——交给额度与告警处理，不要用挑战去解决它。

Cloudflare 能力 vs 应用层职责

事项	Cloudflare 能给到的	应用层必须做的
自动化评分	bot score / 分组（取决于套餐）	结合自有业务信号做最终判定
好 Bot 放行	Verified Bots、Skip 规则、robots.txt 管理	合作方令牌签发与合同额度
挑战形式	托管挑战、JS 挑战、Turnstile	服务端校验与幂等处理
额度与结算	限流规则（条数与维度受套餐限制）	全局配额账本与超量告警
降级决策依据	—	演进策略：缓存 → 降级 → 挑战 → 拒绝

边界与不适用情况

• 依赖长尾爬虫的 SEO不要一刀切拦截未知 UA，先按行为与消耗分级；误杀新抓取器等于放弃新渠道的收录。
• 已授权但超量的合作方属于配额问题而不是 Bot 问题，用配额与告警处理，不要靠挑战解决。
• 隐私合规限制了指纹采集范围时，应提高凭据层与行为层的权重，而不是完全依赖环境。
• 低套餐的现实约束：拿不到细粒度 bot score 时，「按分数写规则」这条路径不成立，替代方案是按分组处置 + 应用层的行为分析叠加。

FAQ

Bot Score 该按多少分拦截？ 不要全局定一个死阈值。先按端点分组看分数分布：登录、领额度、生成类接口各自定阈值，因为不同接口的误杀代价完全不同。另外 bot score 会随模型更新而变化，应定期回看规则是否仍然有效。

误伤了搜索引擎爬虫怎么办？ 把它们加入允许列表，或用 Skip 规则对特定路径放行已验证的好 Bot，而不是调低整体阈值。后者等于为了放行爬虫而把恶意流量也放进来，是典型的本末倒置。

为什么加了 JS 挑战还是被刷？ 因为高级自动化会用真实浏览器内核执行 JS。JS 挑战挡的是脚本直连，不是无头浏览器；这一层要和环境指纹、行为分析叠加才有意义。Cloudflare 也有专门的 JavaScript Detections 引擎用于识别无头浏览器与自动化工具。

无头浏览器能完全识别吗？ 不能。识别的目标是抬高攻击者的工程成本，让它规模化不划算。接受「有少量漏过」，把精力在限额、降级和成本熔断上，比追求完美识别更实际。

相关阅读

• AI SaaS 如何防止 API 被恶意调用？
• AI 应用如何防止用户批量注册和薅免费额度？
• Bot Management 能力页
• 完整解决方案