压测进行到第 3 分钟，响应码里 429 占到 45%，网关日志显示 rate limit exceeded for 10.20.3.0/24。同一时间段手工打开页面是正常的。日志里能对上时间点，这种反而好排。
网关按来源 IP 做 QPS 限流，压测机集中在一段地址，所有流量算到同一个桶里。脚本把限流返回当成了业务失败，QPS 曲线随之下折。限流阈值本来就是给真实用户配的，压测没申请白名单。这一点先确认清楚，后面就不用反复试。
curl -s -o /dev/null -w '%{http_code}\n' http://gw/api/order
nginx -T | grep -A 5 limit_req_zone
「限流拦截压测」确认了原因之后，改动尽量只碰那一处，顺手改的东西后面最容易出问题。线上出问题先对时间点，跟发布、备份、任务执行的时刻排一排，能省掉一半功夫。
日志级别临时调高可以，记得改回去，长期开着既占磁盘又掩盖真问题。
处理上按这个顺序：压测前把压测机网段加进限流白名单；脚本里把 429 单独统计 别混进业务错误率；确认限流维度是 IP 还是用户 ID 再决定白名单粒度；用小流量验证白名单生效后再加压。
结果对不对很好判断，压测期间 429 占比降到 0，QPS 曲线不再中途下折。