防护上线前，凡是不做压力测试就切流量的行为，基本等于把生产环境当试验田；最不能省的是DDoS清洗阈值压测、WAF规则性能压测、API限流压测和主备切换压测。
防护上线前压测有哪些？先把这四件事刻进上线清单
很多团队认为防护设备只要功能测试通过就可以上线，实际完全不是这么回事，功能测试只能证明“配置没写错”，压测才能证明“流量来了扛得住”，防护上线前压测有哪些？从近几年线上故障复盘看，有四类压测反复被忽略,最终导致上线当晚回滚。
- DDoS清洗阈值压测
- WAF规则性能压测
- API限流与防护策略压测
- 主备切换与降级压测
这四类压测的共同点是：不用真实流量模型打一遍，上线后一定会暴露问题，而且暴露的时间点通常在业务高峰期,而不是灰度阶段。
DDoS防护清洗阈值压测：扛不住攻击，上线就是事故
清洗阈值怎么配，直接决定真实攻击下会不会误杀正常用户，阈值设置过高，攻击流量混进来；阈值设置过低，正常突发流量被清洗，上线前必须用模拟攻击流量压测清洗策略,不能只跑功能验证。
为什么空载压测毫无意义
很多团队在测试环境跑几个静态请求，看设备能扛多少QPS，就觉得没问题，但DDoS防护的核心能力不是“转发”，而是“识别和清洗”，空载时CPU和内存都很闲，一旦攻击流量混入，规则匹配、会话跟踪、统计学习全部启动,性能会断崖式下降。
攻击流量模拟操作步骤
- 在测试环境搭建流量发生器，使用
hping3或scapy发送SYN Flood、UDP Flood、HTTP Flood。 - 将清洗设备的阈值临时调整到比生产略宽松的值。
- 逐步加大攻击流量,观察清洗设备是否在预设阈值触发。
- 同时发送正常业务请求,记录误杀率。
- 压测结束后导出清洗日志,核对哪些源IP被误判。
- 针对误判源IP调整白名单或阈值规则,重新压测。
关键观察指标： 清洗触发延迟、正常请求通过率、设备CPU和内存水位、连接表耗尽情况。
北京等地域的机房，由于带宽成本和防护策略差异较大，压测时还要注意跨地域回源链路是否引入额外延迟，部分企业采购北京防护压测服务时，会要求在本机房租用压测机，避免公网链路干扰结果，如果业务部署在多个地域,至少要抽查两个地域的清洗节点。
WAF性能压测方法：规则不是越多越好，压过才知道
WAF是防护体系里最吃CPU的组件之一，规则引擎逐条匹配，一条请求可能经过几十条正则，规则顺序不合理，或者正则写法有回溯风险，压测会直接暴露，WAF性能压测方法不能只测空跑,必须贴近生产流量模型。
用真实业务流量回放，不要只跑简单脚本
常见错误是用ab -n 10000 -c 100打一个首页就完事，这种压测几乎不触发复杂规则，测出来的吞吐量虚高，正确做法是抓取生产环境一段时间内的请求，用tcpreplay或gor回放，至少包含登录、搜索、支付回调等带参数的POST请求。
具体命令示例：
# 录制生产流量 sudo tcpdump -i eth0 -s 0 -w prod.pcap # 回放到WAF测试环境 tcpreplay --intf1=eth1 prod.pcap
回放时观察WAF的CPU、内存、连接数、规则命中耗时，如果WAF控制台有规则耗时统计，按耗时倒序导出，优先优化前几条，压测不充分导致上线故障的案例，多数集中在WAF规则拖慢响应时间,而不是直接打挂设备。
正则灾难性回溯的排查命令
WAF规则里如果出现类似(a+)+$这种嵌套量词，压测时CPU会瞬间打满，上线前可以用pcre2grep对可疑正则做单条测试。
# 用pcre2grep测试正则匹配耗时 time pcre2grep -c '(a+)+$' /tmp/test_payload.txt
如果一条请求匹配耗时超过几十毫秒，这条规则必须重写，行业共识认为，WAF规则上线前应做单条规则性能基线,避免一条坏规则拖垮整个引擎。
地域差异带来的压测重点
上海、北京等一线城市机房的WAF通常承载更高QPS，如果业务部署在多个地域，压测不要只在低峰时段做，要模拟跨地域访问，观察WAF节点是否有地域级缓存或规则同步延迟，部分团队会选择北京防护压测服务，让第三方从不同运营商入口打入流量,验证WAF在跨网环境下的稳定性。
API限流与防护策略压测：最容易在灰度时翻车
防护上线前压测有哪些容易被忽略的API场景？API限流策略首当其冲，很多接口上线时设置了每分钟100次、每IP 50次等限流，但生产环境的正常调用频率可能远超这个值，灰度发布时，部分用户开始报“429 Too Many Requests”,团队才意识到限流阈值拍脑袋定得太低。
限流阈值设置过低，正常用户被误伤
压测时要区分两类流量：正常业务峰值流量、恶意爬虫流量，限流的目标是拦住后者，不能伤及前者,测试方法：
- 从生产日志中统计每个API的P99调用频率。
- 用压测工具模拟正常用户的调用模式，包括重复登录、刷新列表、提交表单。
- 用另一组工具模拟高频调用,验证限流是否在预期阈值触发。
- 观察限流触发后，是否返回统一错误码,是否有降级方案。
- 检查被限流请求是否占用大量连接,导致正常请求排队。
如果压测发现正常调用就被限流，说明阈值需要放宽，反之，如果高频调用没触发,说明限流策略失效。
压测中观察哪些指标
- 网关的QPS、并发连接数、线程池使用率。
- 限流组件自身的CPU和内存。
- 被限流请求的响应时间，应该在几毫秒内返回,不能拖慢正常请求。
- 限流计数是否准确,分布式环境下是否存在计数不同步。
- 不同租户、不同IP的限流是否互相影响。
很多API网关自带压测模式或限流模拟器，没有现成工具时，可以用wrk配合Lua脚本构造签名请求，模拟不同租户、不同IP，重点验证限流算法在分布式场景下的一致性,避免某节点重启后计数清零。
故障切换与主备防护设备压测：切换瞬间别“裸奔”
防护设备上线后不是单点运行，多数部署是主备或集群，但主备切换这个动作，常常被当成“运维操作”而不是“压测场景”,切换瞬间的流量冲击最容易让防护策略出现空窗。
切换瞬间的流量冲击与策略同步
当主设备宕机，备设备接管时，需要加载策略、同步会话表、通告路由，这个过程如果超过几秒，期间所有流量都会直通后端，防护形同虚设,上线前必须做强制切换压测。
操作步骤：
- 在压测流量持续打入的情况下,手动重启主防护设备。
- 观察备设备接管时间,用秒表记录从主设备不可用到备设备开始处理请求的间隔。
- 记录切换期间是否有请求穿透防护,查看后端访问日志是否出现未经防护的源IP。
- 检查切换后会话表是否完整,是否需要重新认证。
- 重复切换3次以上,确认无抖动。
如果切换时间过长，需要调整心跳间隔、优先级或使用Active-Active模式，业内专家指出，多数防护事故不是设备性能不足，而是切换时策略同步机制没有经过压测验证，切换时的短暂空窗,足够让攻击流量打入源站。
上线前压测执行清单：按机房和地域逐项核对
防护上线前的压测不能只在周五下午随便跑一轮，建议在准生产环境，使用与生产同规格的防护设备,按以下清单逐项打勾。
| 压测项 | 必须验证的内容 | 通过标准 |
|---|---|---|
| DDoS清洗阈值 | 模拟攻击触发清洗、误杀率 | 误杀率低于可接受范围 |
| WAF规则性能 | 规则命中耗时、CPU占用 | 无慢规则，CPU低于警戒线 |
| API限流 | 正常流量不被限、恶意流量被拦 | 无误伤，限流生效 |
| 故障切换 | 主备切换时间、策略同步 | 切换期间无穿透 |
清单执行完，把压测报告和上线审批单绑定，没有压测记录，不允许走发布流程，多地域部署时，每个上线地域都要单独核对,不能只测一个机房就全量放行。
防护上线前的压测，省掉任何一类都是在给生产环境埋雷，DDoS清洗阈值、WAF规则性能、API限流、故障切换，这四件事做完，上线才谈得上可控，切流量前,把压测结果翻出来再看一眼。
Q&A：防护上线前压测怎么做才有效？
Q：防护上线前压测有哪些必须做的项目？
A：至少四类：DDoS清洗阈值压测、WAF规则性能压测、API限流压测、主备切换压测，每类都要用真实流量模型，不能只打静态页面，压测通过的标志是正常流量无误伤，攻击流量被拦截,切换期间无穿透。
Q：WAF性能压测方法有哪些推荐？
A：优先用生产流量回放，工具可用tcpreplay或gor，同时用pcre2grep排查单条正则的匹配耗时，避免灾难性回溯，压测时观察CPU、内存、规则命中耗时三个指标，不要用ab打首页这种简单方式替代。
Q：北京防护压测服务价格一般怎么算？
A：价格受机房带宽、压测时长、攻击流量规模影响，差异较大，按需租用压测机比买断设备更灵活，北京地区因机房资源集中，服务商选择多，但跨地域回源延迟要单独评估,最终以实际报价为准。