很多团队在用 Cloudflare WAF 时，最头疼的不是“有没有规则”，而是“为什么同样的请求，有时放行、有时阻断”。你看到了某条规则命中，却发现结果不是固定的；或者你明明加了例外，仍然出现误伤。
原因往往不在单条规则，而在“规则如何被评估、如何排序、如何合并成最终动作”。
这篇文章只解决一个问题：Cloudflare WAF 在实际拦截过程中，是如何根据规则优先级做出放行或阻断判断的？我不会提供任何绕过或规避验证的做法，只讲规则体系的工作方式、常见冲突形态，以及合规排查思路，帮助你把误伤变成可解释的工程问题。
一、先给结论：WAF 不是“命中一条就结束”，而是“多层规则叠加后的最终裁决”
很多人把 WAF 理解成：规则从上到下匹配，命中就拦。
现实更接近：同一次请求会经过多类安全组件与规则集合的评估；每一层可能产生命中、评分或处置建议；最后再按优先级、动作强度与策略分层合并成结果。
因此，真正决定放行或阻断的，往往不是“你看到的那一条”，而是：
哪一类规则先被评估；
谁拥有更高的优先级；
动作是否会被更强动作覆盖；
例外规则是否覆盖到了正确的范围。
你看到的“不一致”，经常来自规则之间的冲突与覆盖关系。
二、WAF 的“优先级”到底在比什么：顺序、范围、动作强度
理解优先级，通常要拆成三个维度，而不是只盯一个“排序数字”。
1、规则评估顺序：不同规则集可能在不同阶段生效
在真实链路里，请求可能先经过：
边缘层的快速过滤与基础风控；
再进入应用层的 WAF 规则评估；
同时还可能叠加 Bot/行为评分、速率策略等。
这意味着：你以为在 WAF 放行了，但如果更上游或并行组件判定为高风险，结果仍可能被收紧。
2、规则作用范围：是否命中“同一个请求对象”
一条例外规则没生效，最常见的原因是：它覆盖的对象不对。
例如：
你以为拦截发生在页面请求，实际发生在某个子资源/接口；
你放行了某个路径，但真实命中发生在不同 Host/子域；
你按 URL 放行，但命中发生在请求体/参数规则。
范围对不上，再高优先级也等于没写。
3、动作强度：同一请求命中多条时，通常以“更强的处置”收敛
当同一请求同时命中多条规则时，系统往往会做“保守合并”：
更强的动作（如阻断/挑战）可能覆盖较弱动作（如记录/放行）。
这也是为什么你会看到：
明明有“允许/跳过”的配置，却仍然被某条更强策略拦住。
因此排查时要关注：是否有另一条更强规则在你没注意的地方生效。
三、实际最常见的 4 类“优先级冲突”场景
下面这些冲突，是误伤与“规则不听话”的高发区。
1、例外规则写对了，但写得太窄：放行没覆盖到真实命中点
典型表现：
主页面放行了，但接口仍被拦；
GET 放行了，但 POST 仍被拦；
某个路径放行了，但同业务的另一路径被拦。
根因通常是：业务链路实际由多次请求组成，而例外只覆盖了其中一段。
2、托管规则与自定义规则叠加：你以为在管 A，实际 B 在管你
托管规则覆盖面广，常命中“边界输入”：复杂参数、长字符串、特殊字符、JSON body 变化。
自定义规则又常按路径、方法、国家地区做分流。
当两者叠加时，很容易出现：
自定义规则放行了路径；
托管规则在 body 上仍判定高风险；
最终动作仍然偏保守。
表现就是：你“看见的规则”不一定是最终裁决的那条。
3、规则动作不一致：记录/跳过 vs 阻断/挑战
很多团队为了可观测性，先用“记录/模拟”观察；同时又保留一些“硬阻断”的老规则。
结果是：你以为现在只是记录，实际请求仍被老规则阻断。
排查重点：同一请求是否命中两条以上规则；是否存在更强动作覆盖。
4、条件变量漂移：同样的业务请求在不同环境下不再“等价”
同样的业务动作，在不同网络、不同会话、不同设备下，请求细节可能不一样：
请求头组合不同；
参数顺序/编码不同；
Cookie 状态不同；
路径上下文不同。
这些差异会导致：
规则在某些环境命中、某些环境不命中；
看起来像“WAF 随机”，本质是输入已变。
四、为什么你会看到“没提示的限制”：WAF 结果可能以分层方式体现
很多人只盯“是否 403”，但实际处置可能更细：
直接阻断；
挑战/验证；
限速/延迟；
降级响应；
记录但放行。
因此你可能遇到：
状态码是 200，但内容被裁剪；
响应时间变长；
某些字段变空；
业务成功率缓慢下滑。
这通常意味着：你进入了更保守的处理层，而不是单纯的 WAF 硬拦截。
五、排查：如何判断“最终裁决”由谁做出、例外是否真正覆盖
下面步骤只用于定位规则优先级与覆盖关系。
第一步：先确定“拦截发生在哪个请求上”
做法：把一次业务动作拆成请求序列，定位真正失败的那一跳。
判断标准：
如果失败集中在接口/子资源，例外规则必须覆盖到那个对象；否则主页面放行没有意义。
第二步：用“内容完整度”判断是否存在降级分层
做法：对比多次响应的结构与关键字段，而不是只看状态码。
判断标准：
200 但内容波动，优先按分层/降级排查，而不是先怀疑解析。
第三步：检查是否存在“更强动作覆盖”
做法：聚合同一请求在同一窗口内的命中记录，看是否命中多条规则。
判断标准：
如果存在阻断/挑战类动作命中，记录/放行类动作往往不会成为最终结果。
第四步：让例外规则“可审计、可回收”
做法：例外要绑定边界：
限定路径范围；
限定方法与资源类型；
限定速率与失败冷却；
并保留审计记录与回收开关。
判断标准：
你能回答清楚：谁被放行、放行了什么、超出边界会发生什么。
六、穿云API作用
很多 WAF 误伤并不是单条规则写错，而是访问语义不稳定导致“输入漂移”：会话不连续、出口变化、请求头与节奏波动、失败后密集补救，会让同一业务动作在风控视角下变成不同的请求，从而触发不同规则组合与更保守的最终裁决。穿云API在访问层统一管理会话、出口与行为节奏，并对异常响应、内容完整度与单位成功成本做集中观测，更容易识别“规则覆盖没对上”还是“更强动作在覆盖”；从而让放行通道更稳定、更可审计、更可回收，减少误伤带来的不可解释波动。
这能帮助你把“WAF 不听话”变成“优先级与覆盖关系可验证”。
Cloudflare WAF 的放行或阻断，通常不是命中一条规则就结束，而是多类规则与组件叠加后的最终裁决：评估阶段不同、作用范围不同、动作强度不同，都会造成覆盖与冲突。
要降低误伤与不一致，不要只盯某条规则；更要定位真实命中请求、检查是否存在更强动作覆盖，并用内容一致性与单位成功成本判断是否进入分层处理。
把例外做成受控通道、把策略分层做清晰、把输入漂移收敛下来，才能让拦截结果长期稳定且可解释。
