多条规则命中时听谁的
一个请求可能同时符合多条规则：既命中通用注入特征，又落在某条业务白名单里。最终动作由引擎的处理顺序决定——不同产品、不同引擎各有自己的阶段划分与优先级规则。以常见的 ModSecurity 为例，规则按阶段（phase 1 至 5）分组执行，同一阶段内按规则在配置中的顺序与异常评分阈值判定动作。结论是：判断实际行为不能只读配置面板，要用测试请求验证最终动作。
基本信息
| 处理顺序 | 按引擎定义的阶段分组，阶段内按配置顺序执行 |
|---|---|
| 白名单机制 | 多数实现中例外或白名单优先于通用规则，但优先级随产品而异 |
| 评分型规则 | 基于异常评分的规则累计分数，超过阈值才触发拦截动作 |
| 验证方式 | 构造测试请求，查看实际动作与命中规则 ID |
| 记录要求 | 记录命中规则 ID 有助于还原是哪条规则决定了结果 |
典型使用场景
- 加白名单后仍被拦截：确认是否被更高优先级的规则先行阻断
- 误报调优：判断应该针对性加例外，还是调整规则集的评分阈值
- 规则集升级后行为变化：新版规则顺序或评分阈值变动导致放行/拦截结果不同
- 排查漏防：被绕过的请求是否因为白名单过宽而跳过了检测
- 上线新规则前验证顺序：确保放行规则不会遮挡应有的拦截规则
- 多站点共用一套规则时，评估站点级例外与全局规则的作用先后
验证与定位方法
验证与定位方法
1. 构造命中目标规则的测试请求（含特征参数） # 用测试参数，不要打真实业务
2. 记录响应结果与日志中命中的规则 ID
3. 与配置预期对比：若不符，检查规则阶段与配置顺序
4. 调整顺序或例外范围后，重新发同一请求做回归
5. 留存验证记录，作为该批次变更的证明常见冲突情形
| 情形 | 实际表现 | 处理思路 |
|---|---|---|
| 白名单与通用规则并存 | 以为放行，实际仍被拦截 | 确认引擎优先级，必要时把例外写在更早生效的位置 |
| 同一请求命中拦截与仅记录规则 | 动作取决于先执行的那条 | 用规则 ID 定位实际生效项，再调整顺序 |
| 评分未达阈值 | 命中特征但未拦截 | 属预期行为，需区分「命中」与「拦截」两个概念 |
| 路径例外覆盖过宽 | 该路径下所有检测被跳过 | 收窄例外范围到具体参数，避免整条路径失防 |
| 规则集升级后顺序变化 | 原有放行行为失效 | 升级后回归验证关键业务与关键例外 |
规则顺序问题在配置界面上往往不直观：面板看到的顺序与实际执行顺序可能因阶段划分而不同。以实际动作验证为准，比读配置更可靠。