Precursor 是一种基于会话的客户端验证系统,随着时间的推移持续评估访问者的行为。Precursor 不是依赖于单个质询事件,而是在浏览器中运行持续验证,以检测在单个请求中看似合法但在整个会话中表现出非人类模式的自动化。
Precursor 作为持续的客户端验证循环运行:
- 将客户端脚本注入页面
- 脚本持续收集信号并执行验证
- 每次执行产生由 Cloudflare 评估的信号
- 结果用于更新存储在
cf_clearancecookie 中的会话状态 - 该过程在整个会话中重复进行
这使得 Cloudflare 能够随着时间的推移持续评估会话行为。
为您的区域启用 Precursor:
- 在 Cloudflare 仪表板中,选择您的区域。
- 转到 Security(安全性) > Settings(设置)。
- 找到 Precursor。
- 打开 Precursor。
-
选择一种模式: 要完全验证用户会话,访问者可能需要完成轻量级质询(Challenge)以建立有效的会话。根据您是希望优先考虑用户体验还是严格验证,Precursor 提供两种模式:
-
Minimize Friction(最小化摩擦)(默认) 不会向访问者显示插页式质询。相反,Precursor 会尝试在后台建立会话状态。 这提供了更流畅的用户体验,但无法保证每个会话都经过完全验证。
-
Maximize Security(最大化安全性)(推荐) 如果不存在有效会话,则显示轻量级插页式质询以建立有效会话。 这可确保在用户继续之前验证每个会话,但可能会引入额外的摩擦。
-
对于大多数客户,选择模式是唯一需要的配置。
Precursor 默认在您的整个区域上运行。Precursor 规则(Rules)不会启用或禁用 Precursor — 它们决定了哪种模式适用于每个请求。
例如:
- 在您的整个站点上运行最小化摩擦,但在
/checkout上运行最大化安全性以强制执行有效会话。 - 在所有页面上运行最大化安全性,除了您的主页。
如果您的区域同时服务浏览器页面和 API 端点,请使用 Precursor 规则来确定严格强制执行适用的范围。
当 Precursor 设置为最大化安全性时,请求必须提供有效的 cf_clearance cookie。这可能会影响:
- 非浏览器客户端调用的 API 端点(例如
curl、移动端后端、服务器到服务器的作业) - 不发送 cookie 的浏览器 API 调用
对于混合的 HTML/API 流量,请使用以下模式之一:
- 首先在全局使用最小化摩擦,然后仅通过 Precursor 规则将最大化安全性应用于敏感页面或路径。
- 首先在全局使用最大化安全性,然后为 API 主机名或 API 路径添加最小化摩擦 Precursor 规则。
对于必须访问在最大化安全性下的端点的浏览器 XHR/fetch 请求,请确保包含 cookie:
fetch("/api/search", {
credentials: "include",
});axios.get("/api/search", {
withCredentials: true,
});对不应要求质询式会话强制执行的端点使用最小化摩擦。Precursor 仍会评估会话行为并可以继续提供检测信号和机器人分数(bot score)上下文。
Precursor 取代了 JavaScript 检测(JSD):
- 从一次性执行转变为持续验证
- 引入了基于会话的状态
- 实现了动态运行时控制
如果您启用了 Precursor,则应禁用 JavaScript 检测(JSD)。
Precursor 和质询(Challenges)扮演着不同的角色:
- 质询提供时间点(point-in-time)验证
- Precursor 提供持续的、会话级别的验证
Precursor 不取代质询。相反,它通过以下方式强化它们:
- 确定何时需要额外的质询
- 在访问者已经通过质询后重新评估他们
- 识别随着时间的推移而出现的自动化
Precursor 与 cf_clearance 紧密集成。当运行 Precursor 时:
- 有效许可(clearance)可能会减少或失效
- 可能会触发额外的质询
- 访问者可能在同一会话期间被重新验证
一旦 Precursor 在一个区域上运行,它的检测结果就会出现在该区域的分析视图中。要打开它,请在 Cloudflare 仪表板中选择您的区域,然后转到 Security(安全性) > Analytics(分析) > Traffic(流量) > Bot analytics(机器人分析)。机器人分数的分布和 WAF 规则匹配计数现在包括 Precursor 的行为和生物识别检测结果。
有关更多信息,请参考 安全分析。