防护规则变更前的压力测试与回滚验证，重点不是单纯把请求量加上去，而是确认新规则能否承受预期流量、是否误伤正常请求，以及出问题时能否恢复到已知可用状态。以下以 AWS WAF 调整速率限制规则为例；其他防火墙或访问控制系统也可沿用这套检查思路。
先定义边界，再准备对照组
测试前记录当前规则版本、优先级、动作和匹配条件，并保存可执行的旧配置。若通过基础设施即代码管理，可保留变更前的 Git 提交及部署参数；手工配置则应导出配置并确认恢复步骤。只备份配置文件、不验证它能否重新部署，不算完成回滚准备。
选定代表性请求：正常登录、常见 API 调用、合法的突发请求，以及应被拦截的测试请求。对照组使用未变更规则的环境或基线记录。AWS WAF 对规则提供 Count 等动作，可在适用配置中先观察匹配情况，再决定是否启用阻断；Count 结果反映规则命中，不等同于真实阻断后的全部影响。
按阶段施压，观察规则和服务两端
- 做低流量功能检查：先以少量受控请求验证规则匹配、日志字段和预期动作。确认测试来源已获授权，避免压测触发真实用户保护或第三方限制。
- 逐级增加负载：使用 k6、Apache JMeter 等工具，先测基线，再按约 1 倍、1.5 倍、2 倍目标负载逐档增加。每档可观察约 5 至 15 分钟；具体时长取决于业务峰值、系统恢复时间和测试环境，不应把这些数值当作通用门槛。
- 覆盖边界行为：检查速率阈值附近、多个客户端来源、请求突发及长时间稳定请求。若只用单个压测机，来源分布可能与实际访问不同，结论应注明这一限制。
- 对照指标：同时观察允许、计数和阻断数量，抽查日志中的规则名称及匹配原因，并比较响应延迟、成功率、错误率和后端资源使用。负载上升时服务自身变慢，不一定是规则误拦截；应结合请求样本判断。
判断标准应在测试前写明，例如正常样本不应被新规则阻断、预期拦截样本应命中目标规则，且服务指标未超过团队既定告警线。阈值要按基线和业务容忍度设定，不宜临时为了通过测试而放宽。
把回滚当作一次正式变更来演练
演练流程
- 在与生产配置尽量一致的测试环境部署新规则，记录配置差异和部署时间。
- 执行与上线相同的恢复操作：重新应用已保存的旧配置或回退到上一版基础设施即代码提交。
- 核对关键规则、优先级、动作和关联资源，确认配置与预期旧状态一致；再重放正常及拦截样本。
- 确认监控和日志恢复到基线范围，并记录恢复耗时、失败点、执行人及所需权限。
若规则由控制台、自动化流水线或不同团队分别管理，需特别检查恢复后是否会被其他配置源再次覆盖。还要确认回滚权限、审批和凭据在变更窗口内可用。回滚验证的结果应是“旧状态恢复且行为正确”，而非仅仅看到部署命令执行成功。
上线判断与常见问题
只有在负载覆盖目标场景、误拦截样本经过核查、回滚演练成功且责任人明确时，才进入上线评估。防护规则变更前的压力测试与回滚验证应留下可复查记录；若测试环境无法代表真实流量，应缩小上线范围，并安排分阶段发布与持续观察。
压力测试一定要达到生产峰值吗？
不一定。应按授权范围和系统承载能力设定目标；无法安全达到峰值时，可结合基线外推，并明确不确定性。
只看阻断数量够不够？
不够。需抽查命中日志和请求样本，同时关注正常请求成功率、延迟及后端指标。
回滚演练可以只检查配置文件吗？
不可以。应实际执行恢复，并验证规则状态、请求行为和相关监控。
规则没有误拦截就能直接上线吗？
不能。还要确认目标负载下的服务表现、日志可观测性、回滚权限和变更责任人。