测试Nginx限流系统高并发稳定性，核心是验证突发洪峰下是否精准限流、资源可控、主链路无损：需实测拒绝率是否符合阈值、CPU/连接数是否稳定、503返回是否统一、正常请求P95延迟是否基本不受影响。
测试 Nginx 限流系统在高并发下的稳定性与抗压能力，核心不是“能不能限住”，而是验证它在真实洪峰中是否不误伤、不崩溃、不放大延迟、不引发级联抖动。重点看限流是否精准生效、资源是否可控、主链路是否始终可用。
一、明确要验证的四个关键行为
限流配置上线后，必须回答以下问题：
- 当突发流量（如 5 倍于设定速率）瞬间打进来，被拒绝的请求是否严格落在限流阈值内（例如 rate=10r/s，burst=20，实测每秒只放行约 10 个，拒绝约 40 个）
- 限流触发时，Nginx 自身 CPU/内存/连接数是否稳定，有无 worker 进程卡死、响应延迟跳变、stub_status 中 Waiting 数飙升
- 被限流的请求是否统一返回预期状态码（如 503），日志中 error_log 是否出现大量“limiting requests”但无其他 warn/error
- 未被限流的正常请求，其 P95 延迟是否基本不受影响（例如从 8ms 升至 12ms，而非暴涨到 300ms）
二、搭建可信的压测环境
避免因环境干扰导致误判：
- 压测机与 Nginx 物理分离：禁用本地 loopback 压测，走真实网络路径；万兆直连更佳
- 关闭无关干扰：停 access_log、禁用 gzip、sendfile、proxy_buffering；后端用固定响应的 mock 服务（如 nginx -s reload 期间也能稳定返回）
- 启用可观测性基础：确保 stub_status 开启（/nginx_status）、error_log 设为 info 级别、实时采集 nginx_upstream_requests_total（若配了 upstream）
- 确认系统资源充足：ulimit -n ≥ 65535，worker_rlimit_nofile 和 worker_connections 匹配，临时端口范围调宽（1024–65000）
三、分阶段压测并抓关键指标
推荐使用 wrk（支持长连接、可控并发、带 latency 统计）：
- 基线测试：wrk -t4 -c100 -d60s http://ip/，记录 RPS、P95/P99、错误率，作为无限流基准
- 限流阈值测试：按配置的 rate 设置压测强度，例如 rate=50r/s → wrk -t2 -c100 -d60s --latency -R50 http://ip/，观察实际通过率是否≈50，拒绝率是否集中出现在 burst 耗尽后
- 突增压力测试：模拟秒杀场景，wrk -t8 -c2000 -d30s --latency -R200 http://ip/（远超 rate+burst），重点盯：Active connections 是否突增后快速回落、Waiting 数是否持续高位堆积、error_log 中 “limiting requests” 日志条数是否与拒绝请求数基本一致
四、交叉验证与失效排查
单看 wrk 输出容易漏掉深层问题：
- 对比不同限流粒度：同样总流量下，分别测试 limit_req_zone $binary_remote_addr（单 IP）和 $server_name（全局），看是否出现某 IP 被误封或整体限流失效
- 检查连接复用影响：开启 keepalive 后，同一连接内高频发请求（如 10r/s），观察是否仍被准确限流（需确认 limit_req_zone 的 key 是否含 connection 相关变量）
-
定位常见瓶颈：
- 若 CPU 持续 >90%，检查是否因频繁日志写入或正则匹配（如 $request_uri）拖慢
- 若出现大量 500 错误而非 503，可能是 limit_req_zone 内存区（zone）不足（10m 不够支撑高基数 IP）
- 若 burst 后延迟陡增，检查是否 nodelay 缺失，导致请求排队阻塞后续连接
