最可靠方式是直接压测并分层对比：用ab或wrk精准控制并发与请求数，验证rate/burst是否按预期生效，同步监控Nginx拒绝数、后端CPU/连接池/P95延迟及错误码分布，且必须单机直连测试以避免集群干扰。
直接压测是最可靠的方式——不靠猜，用真实请求看 Nginx 限流是否按预期起作用，同时观察后端服务资源水位（CPU、内存、连接数、响应延迟）是否稳定。
用 ab 或 wrk 做定向压测
选一个能精确控制并发数和总请求数的工具，比如 ab（Apache Bench）或更现代的 wrk。重点不是“跑多快”，而是“按你设的 rate 和 burst 精准打满”。
-
模拟基础速率：比如你配了
rate=5r/s，就用ab -n 100 -c 5 http://example.com/api/—— 每秒发 5 个请求，持续 20 秒，看成功率是否接近 100%，后端 QPS 是否稳定在 5 左右 -
触发 burst 缓冲区：配了
burst=10 nodelay，就用ab -n 15 -c 15 http://example.com/api/—— 15 个请求瞬间发出，前 10 个应被缓冲并立即处理，第 11–15 个大概率被 503 拒绝 -
验证排队行为：去掉
nodelay后，同样用高并发短请求测试，会发现响应时间明显拉长（排队等待），但失败数减少，适合对延迟不敏感、重可用的场景
观察关键指标是否守住底线
限流不是为了“拦住多少”，而是确保后端不垮。压测时同步盯住这些点：
-
Nginx 自身状态：用
nginx -s status（需启用 stub_status）或监控limit_req_rejected日志计数，确认拒绝量符合预期 - 后端服务负载：CPU 使用率是否不再飙升；数据库连接池是否没被打满；下游接口响应 P95 是否仍在 200ms 内
- 错误码分布：Nginx 日志里 503 出现比例应与 burst 超出量基本一致；若大量 502/504，说明限流没拦住，后端已开始超时或崩溃
分层对比不同配置下的压力曲线
别只试一组参数。同一业务路径下，横向对比几组典型配置：
-
rate=2r/s burst=0→ 极其保守，适合登录等高风险接口 -
rate=10r/s burst=5 nodelay→ 允许小突发，适合普通 API -
rate=30r/s burst=20（无 nodelay）→ 排队平滑放行，适合文件上传类长耗时操作
每组都记录：压测期间后端平均响应时间、错误率、Nginx 拒绝数、系统 load 值。最终选那个让后端 CPU 稳在 60% 以下、且用户感知不到卡顿的组合。
注意单机局限，避免误判全局效果
所有压测必须在单台 Nginx 实例上进行。如果你线上是 4 台 Nginx 做负载均衡，那么实际全局限流能力 ≈ 单机阈值 × 4。压测时如果直接对 VIP 发请求，看到的“整体通过率”会虚高，掩盖单机过载风险。务必直连某台 Nginx 的 IP 测试，再推算集群容量。
