先取证再动手
业务报障说「某个功能用不了」时，第一步不是关 WAF，而是按日志、规则、参数的顺序确认它到底是不是被拦了。确认后按最小粒度加例外并记录原因，这样才能既恢复业务，又不至于把防护面主动让出去。
基本信息
| 适用平台 | 厂商 WAF 控制台、开源自建 WAF（如 CRS 规则集） |
|---|---|
| 排查顺序 | 日志时间与 URL、命中的规则 ID、被匹配的参数与值 |
| 处置粒度 | 参数级例外优于 URL 级例外，URL 级优于整站放行 |
| 记录要求 | 例外原因、申请人、生效范围与有效期写入台账 |
典型使用场景
- 富文本与评论提交：正文里带 HTML 标签或 SQL 关键字，被规则误判
- 搜索与筛选参数：合法的引号、括号组合命中了注入特征
- 文件上传与批量导入：内容本身带有可执行代码片段，触发内容检测
- 长文本或多语言内容：编码差异导致匹配行为与预期不同
- 接口改版：参数结构变化后，原本正常的调用开始被拦
排查路径
排查路径
1. 让业务提供时间点与完整 URL，在 WAF 日志中定位记录
2. 找到命中的规则 ID 与被匹配的具体参数值
3. 判断该参数值是否属于正常业务特征，必要时与开发确认
4. 按最小粒度加例外并立即复测
5. 记录到例外台账，注明原因、范围与复核时间例外粒度选择
| 粒度 | 影响面 | 适用情况 |
|---|---|---|
| 参数级 | 最小 | 确认该参数确实会出现此类内容 |
| URL 级 | 中等 | 整个接口都属同类业务特征 |
| 规则级 | 较大 | 该规则与业务框架天然冲突 |
| 整站放行 | 最大 | 仅在极端情况下临时使用 |
同类误报反复出现时，处理方向应是调整规则阈值或更换检测方式，而不是不断加例外，否则防护面会被一点点蚕食。