验证 limit_req 的平滑缓冲能力需通过压测观察响应分布、失败率和延迟曲线是否符合漏桶节奏，重点考察排队匀速性、拒绝可控性及延迟可预期性。
直接用压测工具发短时高并发请求，观察响应分布、失败率和延迟曲线是否符合漏桶节奏，就能验证 limit_req 的平滑缓冲能力。重点不是看“能不能限住”，而是看“怎么限”——排队是否匀速、拒绝是否可控、延迟是否可预期。
用 ab 或 wrk 模拟真实突发场景
选一个被限流保护的接口（如 /api/order），用工具制造明确的流量脉冲：
-
基础突刺测试：用
ab -n 100 -c 50 http://localhost/api/order，模拟 50 并发打 100 个请求。若配置为rate=10r/s burst=20，理想结果是：前 10 个快速返回，接下来约 2 秒内匀速放出 20 个（间隔 ~100ms），其余 70 个直接 503 -
带时间窗口的压测：用
wrk -t4 -c100 -d5s --latency http://localhost/api/order，持续 5 秒高并发，观察 P50/P95 延迟是否稳定在1000ms / rate附近（如 rate=10r/s → P95 延迟应接近 100–200ms，而非跳变到秒级） -
对比有无 burst：先关 burst（
limit_req zone=api;），再开 burst（limit_req zone=api burst=30;），两次跑相同 ab 命令，失败率应从接近 90% 降到 30% 左右，且成功请求的响应时间呈阶梯状分布
看日志确认排队与拒绝行为
默认 access log 不记录被限流的请求，必须主动加变量才能看清内部动作：
- 在
http块里定义日志格式：log_format reqlog '$remote_addr - [$time_local] "$request" $status $limit_key $limit_rate $limit_req_status'; - 在 location 中启用：
access_log /var/log/nginx/api_access.log reqlog; - 压测后查日志：
grep "503" /var/log/nginx/api_access.log | head -20，能看到哪些 IP 被拒、当前速率、key 值；grep -v "503" | tail -10可查最后几个成功请求是否带排队痕迹（$limit_req_status为delayed表示被匀速放行）
监控关键指标判断缓冲是否有效
平滑不是“没拒绝”，而是让拒绝和延迟落在可预期的位置：
-
看
$limit变量值：它表示当前请求在队列中的等待序号。如果压测中出现limit=15、limit=28这类递增数字，说明 burst 队列正在起作用；如果全是limit=0或空，说明 burst 没生效或被 nodelay 关闭 -
检查
X-RateLimit-Delay响应头：启用delay=N后，被延迟放行的请求会在响应头中带这个字段（单位毫秒）。用 curl 测试：curl -I http://localhost/api/order 2>&1 | grep RateLimit，能直观看到排队等待时间 -
关注错误日志级别：加
limit_req_log_level warn;，然后tail -f /var/log/nginx/error.log，会看到类似limiting requests, excess: 12.345 by zone "api"的提示——excess 值越平稳、不剧烈跳变，说明漏桶节奏越准
结合后端表现交叉验证
限流最终是为保护后端，所以要看它是否真把压力“摊平”了：
- 在 upstream 中开启
proxy_next_upstream error timeout http_503;，并配合keepalive 32;，压测时观察后端 access log 的请求到达时间戳是否变得均匀（比如原来 1 秒内扎堆 80 条，现在拉长到 3 秒内每 200ms 一条） - 用
nginx -t确保配置无误，再用kill -USR2 $(cat /var/run/nginx.pid)平滑重载，避免 reload 导致队列状态丢失影响测试准确性 - 若发现大量请求卡在 delay 队列尾部（如延迟超 2 秒），说明
burst / rate比值过大，需调小 burst 或提高 rate，而非单纯加内存
