1 JavaScript Detection——Cloudflare 传统 Bot 防护体系的重要基础
一直以来，JavaScript Detection 都是 Cloudflare Bot 防护体系的重要组成部分。它通过让客户端浏览器执行 JavaScript，收集浏览器环境、运行状态以及访问特征等客户端信号，为 Cloudflare 判断访问主体是否更接近真实用户提供重要依据。
而 JavaScript Detection 之所以在传统 Web 环境中具有重要价值，是因为早期自动化程序与真实浏览器之间存在较明显的能力差异。
过去，大量自动化程序（例如早期爬虫）主要通过 curl、Python requests 等方式，以传统 HTTP 请求的形式访问网站。这类程序虽然能够完成基本的网络通信，但本质上只是模拟客户端与服务器之间的数据交换，并不具备完整浏览器运行环境。
与真实浏览器相比，这类自动化程序通常具有明显特征：使用简单 HTTP 客户端直接发送请求；无法执行 JavaScript；缺少完整浏览器环境；请求行为高度机械化等。
而对于服务器而言，最初能够获取的信息主要来自 HTTP 请求本身，包括：请求来源；客户端标识；请求参数；Header 和 Cookie 等数据。这些信息主要描述的是 HTTP 通信层面的特征，并不能可靠反映客户端真实运行环境。更别说，自动化程序还可以伪造 User-Agent、携带 Cookie，甚至模拟部分正常请求行为。
因此，仅依靠 HTTP 请求特征，服务器很难判断访问主体是否具备真实且完整的浏览器能力。
而 JavaScript Detection 的价值就在于补充这一层缺失的信息：通过让客户端执行 JavaScript，Cloudflare 可以进一步获取浏览器环境和运行状态等客户端信号，从而建立比单纯分析 HTTP 请求更丰富的访问判断依据。
需要注意的是，Cloudflare 的 Bot 防护并不会依赖某一个单独指标，而是综合多个维度进行判断，包括：
- IP 地址信誉；
- 请求频率；
- User-Agent 特征；
- 访问路径；
- 浏览器环境信息。
在这一体系中，JavaScript Detection 提供了客户端环境层面的重要信号，是 Cloudflare 传统 Bot 防护模型中的关键组成部分。
从技术演进角度看，JavaScript Detection 的意义在于：它让 Web 安全防护从过去主要分析“请求本身”，进一步扩展到分析“发出请求的客户端环境”。
对于大量传统自动化程序，例如简单爬虫、扫描工具以及缺少浏览器能力的脚本程序，客户端环境信号能够补充 HTTP 请求层面无法提供的信息，从而有效提高 Cloudflare 对访问主体的识别准确率。
在传统 Bot 防护模型中，JavaScript Detection 提供的客户端真实性信号会与其他风险判断因素结合，共同用于评估当前访问是否需要进一步验证。当 Cloudflare 判断某个访问具有较高风险时，Managed Challenge 可以进一步要求访问主体完成验证，从而形成从风险识别到主动验证的完整防护流程。
2 AI Agent 时代，真实浏览器能力不再等于真实用户
过去，Cloudflare 的 Bot 防护体系建立在一个重要前提之上：“具备真实浏览器能力”，可以作为判断访问主体可信度的重要依据。
这是因为在传统 Web 访问模型中，完整浏览器环境本身具有较高实现成本。真实浏览器不仅需要执行 JavaScript、管理 Cookie，还需要处理动态内容加载以及页面交互流程。对于大量简单爬虫和脚本程序而言，它们通常只能模拟 HTTP 请求，并不具备这些浏览器运行能力。
然而，随着浏览器自动化技术的发展，浏览器逐渐从用户专属的交互工具，变成了一种可以被程序控制的执行环境。现代自动化程序已经能够驱动真实浏览器完成页面加载、JavaScript 执行、Cookie 管理、页面元素交互以及多步骤操作流程。
这意味着，过去用于区分真实用户与自动化程序的重要信号——浏览器能力，正在逐渐失去区分价值。如今，“拥有浏览器”只能说明访问主体具备浏览器执行能力，而无法进一步判断其背后是否一定是真实用户。
而 AI Agent 的出现，又进一步放大了这一变化。与传统自动化程序相比，AI Agent 的最大区别在于：它不再完全依赖预先定义的执行流程，而是可以根据当前环境和目标动态调整访问行为。
传统 Bot 通常按照固定规则完成任务，例如批量抓取页面、遍历链接或提交固定请求。由于其访问路径和行为模式相对明确，网站可以通过请求频率、访问路径、参数特征等方式发现异常。
而 AI Agent 更接近一种新的访问主体。它可以理解页面内容，根据目标判断下一步操作，并通过浏览器完成连续任务：
理解页面
↓
分析目标
↓
决定下一步操作
↓
继续执行任务
这意味着，自动化访问正在从“执行预定义流程”转向“根据环境自主决策”。
因此，Bot 防护面临的核心问题也发生了变化，过去需要判断： “这个客户端是否具备真实浏览器能力？”而现在需要进一步判断：“这个访问主体是否值得信任？”
3 Cloudflare Precursor——从一次性挑战到动态风险评估
随着访问主体复杂度的提升，Bot 防护模型需要的不再只是判断某个客户端是否具备浏览器能力，而是综合更多信号评估访问主体的可信程度。这也意味着，挑战机制不能仅作为风险出现后的验证手段，而需要更深入地参与访问评估过程。
Cloudflare Precursor 正是在这一背景下推出的新一代挑战机制——它并不是简单替代 JavaScript Detection，也不是另一个版本的 Managed Challenge，而是重新定义了挑战机制在 Bot 防护模型中的作用方式。
传统挑战流程通常是：
发现风险
↓
触发 Challenge
↓
验证访问主体
↓
决定是否放行
在这种模式下，JavaScript Detection 和 Managed Challenge 通常承担不同但互补的角色：
- JavaScript Detection 通过客户端 JavaScript 执行获取浏览器环境信号；
- Managed Challenge 在风险较高时要求访问主体完成验证，并根据验证结果以及其他风险信号决定是否放行。
传统模式的核心逻辑是：先通过已有信号判断访问风险，当风险达到一定程度后，再触发挑战验证。
而 Precursor 改变的是挑战机制参与风险评估的方式：
访问开始
↓
持续收集访问信号
↓
结合会话状态评估风险
↓
动态决定是否需要挑战
它并不是取消客户端 JavaScript 信号，而是将 JavaScript Detection 一次性的检测模式，转变为基于访问过程的持续验证机制，并结合访问行为动态评估访问主体的可信程度，从而决定是否需要触发挑战。
换句话说，Precursor 关注的不再只是某一次请求是否异常，而是：“这个访问主体在整个访问过程中，是否持续表现出可信特征？”
这也是为什么Cloudflare 建议启用 Precursor 后关闭 JavaScript Detection：
因为两者都依赖客户端 JavaScript 获取访问信号，而 Precursor 在此基础上引入了基于会话状态的持续验证机制，因此能够提供更完整的访问主体评估能力。
从更大的技术演进角度来看，Precursor 代表了 Cloudflare Bot 防护模型的一次关键演进：从过去依靠单次客户端特征判断访问可信度，转向结合持续信号、会话状态以及访问行为，对访问主体进行动态评估。
另，想了解更多Precursor的技术细节请直接访问Cloudflare官方链接：https://developers.cloudflare.com/cloudflare-challenges/precursor/。
4 Precursor 对传统 Cloudflare 配置经验的影响
理解 Precursor 的工作方式后，可以发现它带来的影响并不仅仅是增加了一个新的安全选项，而是网站管理员过去针对 Bot 防护形成的一些配置经验，需要重新调整。
过去，Cloudflare 的 Bot 防护通常由自动检测能力和人工配置策略共同组成：一方面，Cloudflare 会基于自身的 Bot 检测模型，结合 IP 信誉、请求特征、客户端环境等信号，对访问进行风险评估；另一方面，网站管理员也会根据自身业务特点，通过自定义规则对特定场景进行强化保护。
例如，对于后台登录入口、敏感操作页面，或者某些明显异常的访问路径，管理员通常会手动设置更严格的 Challenge 策略；对于普通公开页面，则更多依赖 Cloudflare 自身的风险判断和自动防护机制。在传统 Web 访问模型下，这种组合方式已经能够覆盖大部分自动化访问场景。
但随着访问主体和访问行为逐渐复杂化，传统 Bot 防护模型所依赖的判断信号也需要进一步扩展——无论是 Cloudflare 自动检测，还是管理员基于固定特征配置的规则，都越来越需要更多上下文信息辅助判断。
Precursor 带来的最大变化在于：管理员不再需要首先针对大量潜在风险场景设计 Challenge 规则，而可以更多依赖 Cloudflare 在访问过程中持续评估访问主体，并根据风险程度动态决定是否需要进一步验证。
由于不同网站、不同业务场景对于安全性和访问体验的权衡并不相同，Precursor 并没有采用单一的挑战策略，而是提供了两种不同的安全策略模式：
- 最小化摩擦（Minimize Friction）
- 最大化安全（Maximize Security）
这两种模式的区别，并不只是挑战强度的高低，而是代表了网站管理员对于访问体验和安全验证之间不同的权衡。
在“安全性”-“设置”-“Precursor”中开启该功能后，整个 Zone 默认都会启用 Precursor，并处于“最小化摩擦”模式（默认模式可以手动修改成最大化安全，但是一定要非常慎重，除非你真的明白你在做什么）：
在该模式下，Precursor 更强调降低正常访问过程中的干扰，优先保证业务连续性。因此，对于大多数内容型网站、个人博客以及公开服务而言，只需要启用 Precursor 并保持“最小化摩擦”模式，即可让 Cloudflare 根据访问过程中的信号动态判断风险，而无需管理员提前针对大量页面设计 Challenge 规则。
从我的实际使用情况来看，所有的API 调用和公开服务场景都没有因为启用 Precursor 而受到明显影响。
而对于具有更高安全要求的入口，例如：后台管理入口，身份认证页面，高价值操作接口，则可以针对这些入口创建匹配规则，并将对应策略设置为“最大化安全（Maximize Security）”。这些位置本身具有较高安全价值，即使访问主体具备浏览器能力，也不一定应该直接信任，因此可以采用更严格的验证策略。以”WordPress身份认证页面”设置”最大安全”模式为例：
不过，这并不意味着所有访问入口都应该采用最高安全级别。对于部分存在合法程序化访问需求的接口，例如公开 API、第三方服务调用接口，或者 WordPress 中依赖前端 JavaScript 调用的 admin-ajax.php，如果强制要求访问主体完成 Challenge，很可能会影响正常功能调用。
因此，在配置 Precursor 时，仍然需要结合具体业务场景判断保护级别：
- 对需要保护的管理入口，可以采用更严格的安全策略；
- 对需要被合法程序访问的接口，则需要避免影响正常调用流程。
再次提醒：开启Precursor之后不要忘记按照官方要求在”安全性”-“设置”-“Super Bot Fight 模式”中关闭”JavaScript Detection “功能：
5 从传统 Bot 防护到访问主体可信评估
过去的网站安全体系，更多关注一个核心问题：如何识别并阻止异常自动化访问？
在传统 Web 环境中，这种思路是有效的。因为大量自动化程序具有较明显的行为特征，而真实用户与自动化程序之间也存在相对清晰的界限。
但随着浏览器自动化技术和 AI Agent 的发展，这种区分方式正在逐渐面临挑战。未来的网站访问环境中，自动化访问本身并不一定代表风险，一个访问主体可能来自真实用户操作，也可能是经过授权的 AI Agent，或者其他合法的程序化调用。
因此，网站安全需要关注的问题不再只是：”这是 Bot 还是用户？“，还需要进一步判断：这个访问主体是否可信？它是否具有合理的访问目的？它是否符合预期的行为模式？
Cloudflare Precursor 的出现，正体现了这种安全理念的变化——它并不是简单提升 Bot 检测能力，而是代表网站安全体系开始从“识别异常行为”，逐渐转向基于更多上下文信息评估访问主体可信程度。
对于网站管理员而言，未来的重点也不会只是不断增加规则、拦截更多自动化访问，而是在安全性、开放性和用户体验之间建立新的平衡。随着访问主体逐渐多样化，网站需要区分不同类型的自动化访问，而不是简单地将所有非人工访问视为风险。
这种变化背后的本质，是互联网访问关系正在发生改变——在 AI Agent 逐渐进入互联网基础设施之后，网站需要面对的问题已经不仅是“如何防 Bot”，而是：如何在一个人和机器共同参与的网站环境中，建立新的访问信任体系。