在 Cloudflare 上配置 WAF 规则时，许多开发者默认认为规则之间是「并行评估」或「公平竞争」的关系，实际上 Cloudflare 采用严格的分层顺序执行模型。理解这一评估顺序不仅关乎规则是否按预期生效，更直接影响请求延迟和安全性边界是否被意外突破。
规则评估的整体顺序
Cloudflare 对 HTTP 请求的规则检查按照固定的分层顺序进行。现代 WAF 堆栈的评估顺序如下：
第一层是 IP 访问规则（IP Access Rules），用于直接放行或阻止特定 IP 地址；第二层是传统防火墙规则（Legacy Firewall Rules），仅在已迁移遗留配置时生效；第三层是自定义 WAF 规则（Custom WAF Rules），这是大多数用户配置业务逻辑的核心区域；第四层是 WAF 速率限制规则；第五层是托管 WAF 规则（Cloudflare Managed Rulesets）；最后一层是传统的速率限制（Legacy Rate Limiting），已逐步废弃。
理解这个顺序的关键在于：一旦某个规则匹配到终止性动作（Terminating Action），评估立即停止，后续规则不再执行。这意味着如果第一条规则是「阻止来自某个 IP 段的请求」，即使后面有一条更宽松的「允许该 IP 段访问特定路径」的规则，后者也永远不会被触发。
终止性动作与非终止性动作的差异
规则动作分为两类，对评估流程有截然不同的影响。终止性动作包括 Block（阻止）、Challenge（挑战验证）、JS Challenge（JavaScript 挑战）、Managed Challenge（托管挑战）以及在特定上下文中的 Allow（允许）。一旦匹配到这些动作，Cloudflare 立即停止该阶段的所有后续规则评估。
非终止性动作的典型代表是 Log（记录日志）和 Bypass（绕过）。这些动作匹配后不会中断评估流程，请求会继续流向下游规则。这一特性在实际使用中容易被忽视：许多用户期望配置一条「记录日志但继续检查」的规则，但如果该规则的匹配条件过于宽泛，可能会与后续的终止性规则产生意外交互。
规则链排列导致的性能差异
规则顺序不仅影响功能正确性，还直接关联请求处理延迟。每条规则都需要 Cloudflare 对请求进行条件匹配计算，当规则数量较多时，排列顺序的优化可以显著降低平均处理时间。
实践中有两条核心原则：其一，将高匹配概率的规则置于更早的位置。由于规则从上到下依次评估，把最可能命中的规则放在前面，可以减少后续规则的计算量。例如，如果站点 90% 的流量来自已知 IP 段，将 IP 白名单规则置于最前可在第一层就放行请求，跳过后续所有 WAF 检查。其二，将具有终止性动作的宽松规则前置。如果希望某些请求绕过后续的严格检查，必须在严格规则之前放置允许规则，否则严格规则会先执行并阻止请求。
一个常见的性能陷阱是「Log 规则放错位置」。如果将一条匹配所有请求的 Log 规则放在自定义规则的最前面，它不会终止评估，但每次请求都会执行一次完整的条件检查，增加不必要的计算开销。正确的做法是将 Log 规则移至规则列表末尾，或者使用 Cloudflare 的独立日志功能而非自定义规则。
安全边界绕过场景
规则顺序配置不当可能导致预期的安全防护被意外绕过。最典型的场景是「Allow 规则置于 Block 规则之后」。假设管理员配置了两条规则：第一条阻止来自某个可疑 IP 段的请求，第二条允许该 IP 段访问 /api/public 路径。由于 Block 规则先执行，IP 段在第一层就被阻止，Allow 规则永远不会生效。解决方法是调换顺序，或者在 Block 规则中添加例外条件。
另一个危险场景涉及托管 WAF 与自定义规则的交互。自定义规则在托管 WAF 之前执行，这意味着可以通过自定义规则绕过托管 WAF 的防护。如果自定义规则配置了不恰当的 Bypass 动作，可能使请求跳过云端威胁检测。正确的安全架构应确保自定义规则仅用于业务逻辑放行，而非绕过安全检查。
速率限制规则的顺序同样需要谨慎设计。如果在速率限制规则之前放置了一个带有终止性 Block 动作的规则，恶意请求可能通过触发该 Block 来避免速率限制检查 —— 因为评估在第一层就终止了，速率限制规则根本没有机会执行。
账户级与区域级规则的阶段划分
在更复杂的场景中，还需要理解账户级（Account-Level）与区域级（Zone-Level）规则的相对顺序。请求依次经过：账户级自定义规则集（位于 http_request_firewall_custom 阶段），然后是区域级自定义规则，接着是账户级速率限制、区域级速率限制、账户级托管规则集、最后是区域级托管规则。
这种分层意味着账户级规则可以全局覆盖区域级配置。如果企业在账户级别配置了「禁止所有区域的特定 IP」的规则，该规则会在区域级规则之前生效，区域管理员无法通过区域级配置来覆盖这一限制。
工程实践建议
综合以上分析，生产环境中的规则配置应遵循以下可落地参数：首先，对自定义规则数量进行监控，单个域的自定义规则建议控制在 50 条以内，超过此数量应考虑拆分为多个规则集或使用表达式简化。其次，为关键业务路径配置独立的 Allow 规则，确保在托管 WAF 规则之前执行，示例表达式为 http.request.uri.path matches "^/api/public" 配合动作为 Allow。第三，使用优先级编号（而非拖拽排序）管理传统防火墙规则，优先级数值越低越先执行，建议关键安全规则优先级设置为 1-10，业务放行规则设置为 100-1000。第四，定期审计规则顺序，利用 Cloudflare 的规则模拟器功能验证规则命中顺序是否符合预期。
理解 Cloudflare 的规则评估顺序，本质上是理解一个明确的状态机如何处理每个请求。规则不是「建议」，而是具有严格执行优先级的防护链。正确的顺序设计可以让安全策略与性能优化兼得，而忽视这一细节则可能导致防护失效或产生意外的性能开销。
资料来源：Cloudflare 官方文档《Order and Priority》《WAF Concepts》《Custom Rules》《Firewall Rules Actions》《Phases List》