限流恢复后系统吞吐能力验证需测恢复速度、稳态qps、响应延迟和资源利用率；判定标准为nginx日志无限流记录、连接数回落至基线、后端5xx/429归零且p95
测试限流恢复后的系统吞吐能力，核心是验证：当突发流量退去、限流规则退出生效状态后，Nginx 和后端服务能否快速回到稳定高吞吐状态，并真实承载设计容量。这不是单纯“看是否不报错”，而是要测恢复速度、稳态 QPS、响应延迟和资源利用率四项指标。
明确“恢复”的判定标准
限流本身不改变系统能力，只做请求筛选；所谓“恢复”，是指触发限流的条件已消失（如 IP 请求频次回落、burst 队列清空、连接数低于 limit_conn 阈值），且系统资源（CPU、内存、连接池）已释放并稳定。需同时满足：
-
nginx error.log 中不再出现
limiting requests或limiting connections日志 - 用
ss -tn | grep :your_port | wc -l观察 ESTABLISHED 连接数回落至基线水平（比如日常均值的1.2倍内） - 后端应用监控（如 Prometheus 的
http_server_requests_seconds_count）显示 5xx/429 错误归零，且处理延迟 P95
分阶段压测验证吞吐恢复
不能只在“限流刚停”那一刻打一次流量——那测的是瞬时响应，不是可持续吞吐。应按三阶段推进：
-
静默期（0–60秒）：停止所有压测工具，观察 Nginx access.log 是否无新请求，确认限流器内部状态已重置（可通过
limit_req_status指令配合日志变量验证） - 爬坡期（60–180秒）：用 ab / wrk 以每秒 +50 QPS 的速率缓慢加压（例如从 100 → 500 QPS），记录每 10 秒的平均响应时间与成功率。理想曲线是延迟平稳上升、无陡增，成功率始终 ≥99.5%
-
稳态期（180–600秒）：维持目标峰值流量（如预设 800 QPS）持续 6 分钟以上，重点采集：
- Nginx worker 进程 CPU 使用率（应 ≤70%，避免调度瓶颈）
- upstream 后端平均活跃连接数（应 ≤ 连接池上限 × 0.8）
- P99 响应时间波动范围（建议控制在 ±15% 内）
对比基线，识别隐性衰减
限流恢复后吞吐若低于原始基线（即未触发限流时的压测结果），说明存在隐性损耗。常见原因包括：
-
连接未复用：客户端未发 Keep-Alive 头，或 Nginx upstream 未配
keepalive 32，导致每次请求重建 TCP，吞吐虚高但实际开销翻倍 -
缓冲区阻塞：
proxy_buffering on但proxy_buffers过小，大响应体反复落盘，CPU 被 I/O 占满 -
后端连接池卡死：某台后端因限流期间积压请求超时，连接池中残留 half-open 连接，需检查
max_fails和fail_timeout是否合理
此时应关闭限流配置，单独对同一后端集群重跑基线压测，比对差异点定位根因。
用真实业务流量做最终验证
工具压测再准，也替代不了真实用户行为。上线前可做灰度验证：
- 将 5% 用户路由到开启限流的新 Nginx 实例，其余走旧实例
- 通过前端埋点统计关键路径（如登录页→提交→成功）的端到端耗时与失败率
- 对比两组数据：若新实例在同等 UV 下 P95 延迟增加 >100ms 或转化率下降 >0.5%，说明限流策略或恢复机制影响了用户体验，需调优 burst 值或切换为 delay 模式
