waf上线后，拦住恶意请求固然重要，但把正常用户挡在门外同样会造成业务问题。有效配置不是把规则调到最严，而是让每项拦截都有依据、能验证、可回退。以下五个误区，适用于自建或托管的 Web 应用防护方案。
误区一：默认启用全部规则就够了
规则集提供的是通用检测能力，不了解你的应用字段和请求流程。例如，内容管理系统的文章编辑接口可能允许提交 HTML 片段或代码示例；通用规则若把这些内容识别为可疑输入，就可能误拦发布操作。先盘点入口、请求方法和关键参数，再判断规则是否适用。
误区二：只看拦截数量，不核对命中细节
拦截数上升不等于防护效果变好。排查时至少记录时间、请求路径、方法、匹配规则编号、命中的参数或请求体位置，以及最终动作。检查 waf 日志时，要区分真实攻击、自动化扫描和正常业务输入；不要仅凭单条告警就关闭整组规则。
误区三：遇到误报，就放宽整个站点
整站关闭检测或放宽规则，会让原本有效的防护一并失效。更稳妥的做法是缩小例外范围：限定具体路径、参数、规则编号或请求方法，并说明业务原因。确需设置白名单时，应避免对整个来源地址或全部请求无条件放行，同时为例外设定负责人和复查时间。
误区四：把限速当作通用拦截工具
限速针对的是一定时间内过于频繁的请求，适合保护登录、验证码发送等容易被重复调用的入口；它不能代替对恶意载荷的规则检测。阈值应结合正常流量、共享出口网络和客户端重试行为设定。阈值过低可能影响多人共用网络的用户，过高则难以抑制突发请求。
误区五：直接全量切换到阻断模式
新规则先在监测模式运行，能让团队看到潜在拦截而不立即影响请求。随后选取有代表性的业务流程验证，再按小范围、分阶段的方式开启阻断。灰度发布期间持续核对用户反馈、应用错误日志和 waf 命中记录；出现异常时，按预先保存的策略版本回退，而不是临时删除大量规则。
上线前的校准步骤
- 建立基线：列出公开入口、常见请求方法、重要业务操作和已知的正常流量变化。
- 先观察再调整：启用候选规则的记录或监测能力，收集覆盖日常与高峰业务时段的样本。
- 逐项验证：对照规则编号和命中字段，使用正常流程复测；只为确认的误报添加最小范围例外。
- 分批阻断并留档：记录策略版本、变更原因、验证结果和回退方式，之后定期复查例外是否仍然必要。
不同 waf 产品的界面与规则语法各不相同，但校准思路一致：先理解命中原因，再做局部调整；先验证业务，再扩大阻断范围。这样既能减少误报，也能让每次配置变更都可追溯。
常见问题
监测模式要运行多久？
没有适用于所有应用的固定时长。至少覆盖日常流程和重要业务高峰；流量有明显周期时，应尽量观察到相应周期再切换。
发现一次误报，要立即加白名单吗？
先确认请求确为正常业务，并定位具体规则和字段。确认后再设置最窄范围的例外，同时记录原因并安排复查。
开启阻断后出现业务异常怎么办？
先对照时间、路径和规则日志判断是否相关；若影响持续且无法及时确认，可回退到已验证的策略版本，再复测后调整。
规则上线后还需要维护吗？
需要。应用接口、流量模式和规则版本都可能变化，应在应用发布或规则更新后复核关键流程与例外配置。
