刚接触 Web 应用防火墙，容易把“拦得越多越安全”当成配置目标。实际上，Web应用防火墙规则配置入门的重点是先看清请求，再逐步收紧策略：明确保护对象、观察误报、验证业务是否正常，最后才扩大拦截范围。下面按六个常见问题说明。
1. 配规则前，先确认哪些信息？
先列出要保护的域名、公开页面和关键操作，再确认流量是否经过防护服务、源站是否仍可被绕过访问。对每个业务入口记录正常请求方法、常用参数和访问来源。例如，预约系统的提交页面可能使用 POST，查询可开放 GET；两者不必套用完全相同的规则。
同时准备可观测的日志，至少关注请求路径、时间、响应状态、命中规则和处置动作。记录中应避免保留密码、访问令牌等敏感内容。
2. 应先启用托管规则，还是自己编写？
多数新手可先从供应商提供的托管规则开始。这类规则通常覆盖常见攻击特征，维护成本较低，但规则集更新或检测范围较广时，可能影响合法请求。自定义规则更适合处理明确的业务约束，例如对管理页面限制访问来源；灵活性更高，也更依赖维护者判断。
建议先启用基础托管规则并选择“记录”或检测模式，观察一段覆盖正常业务周期的时间。再根据日志逐项调整，不要一开始就复制一大批规则并全部设为拦截。
3. 规则动作选拦截、记录还是挑战？
记录模式只留下命中信息，适合新规则上线前观察；拦截会直接拒绝请求，适合证据明确且误伤风险较低的情况；挑战则要求请求完成额外验证，能用于需要区分自动化流量的场景，但也可能增加用户操作成本。
判断时查看命中请求的路径、参数和业务结果。若合法表单内容反复触发规则，先检查规则条件是否过宽，不要只靠放行整个域名解决。对尚未确认的命中，保留记录通常比直接拦截稳妥。
4. 误报出现后，怎样缩小例外范围？
误报是合法请求被规则识别为风险。处理时先确认命中的具体规则和请求字段，再按“规则编号、路径、参数或请求方法”等条件做最小例外。比如某个报表筛选字段允许特定格式，不代表同一站点的所有参数都应该跳过检测。
每次调整后，用原先触发问题的请求验证页面、提交和后续结果；同时检查相邻入口是否仍受保护。白名单应有负责人、原因和复查时间，业务改版后及时删除不再需要的例外。
5. 限速规则的阈值应该怎么定？
限速规则用于控制短时间内重复请求，常见于登录、验证码发送、搜索等容易被自动化反复调用的入口。阈值不要照搬通用数字：先观察正常流量在不同时间段的请求分布，再结合单个用户、来源地址或会话的访问特征设置。网络出口共享、移动网络切换等情况，也会影响按 IP 统计的准确性。
初期可先记录超限事件，确认规则不会集中命中正常用户后再启用挑战或拦截。阈值需要随流量变化复查；限速能减轻重复请求压力，但不能替代应用自身的身份验证和资源保护。
6. 上线前后如何验证规则有效？
把 Web应用防火墙规则配置入门落实为可复查的变更流程，比一次性追求复杂规则更重要。
- 导出或记录当前策略，标注本次新增、修改和例外规则。
- 在测试环境或低风险范围验证正常页面、表单提交和异常请求的处理结果。
- 分批切换到拦截模式，观察命中日志、错误率和用户反馈；如出现异常，按预设方案回退相关规则。
- 定期复核例外、过期策略和长期未命中的规则，避免配置不断累积。
虚拟补丁可用于应用暂时无法及时修复时拦截特定风险请求，但它不能代替代码修复。配置完成后仍要持续检查日志和业务表现。
补充常见问题
- 规则越多越安全吗？不一定。重复或范围过宽的规则会增加误报和排查难度。
- 检测模式要运行多久？应覆盖业务高峰、低峰和主要操作流程；周期依流量规律而定，没有适用于所有站点的固定天数。
- 规则更新后要重新检查吗？要。更新可能改变匹配范围，建议查看变更说明并观察命中情况。
新手配置的核心不是堆规则，而是让每条策略都有明确目标、验证方法和回退方式。按观察、调整、分批拦截的顺序推进，才能把 Web应用防火墙规则配置入门做得稳妥且便于维护。
