nginx中burst与nodelay协同逻辑为：不加nodelay时超rate请求进burst队列并延迟释放，超队列则503；加nodelay时≤rate+burst的请求立即通过，超限即拒。
排查 Nginx 限流配置中 burst 与 nodelay 的协同逻辑错误，关键在于理解两者组合后的实际行为是否符合预期——尤其是请求排队、延迟响应、突发处理和拒绝策略是否按设想工作。
确认限流桶模型的实际行为
Nginx 的 limit_req 基于“令牌桶”（更准确说是“漏桶+缓冲队列”混合模型）：每秒按 rate 补充令牌，请求需消耗令牌；burst 定义缓冲区大小（即最多允许积压多少个请求），而 nodelay 决定是否跳过排队等待。
- 没加
nodelay：超出rate的请求会进入burst队列，按漏桶节奏逐个释放（有延迟）；超队列则直接 503 - 加了
nodelay：只要总请求数 ≤rate + burst，就全部立即通过（不排队、无延迟）；超过该总数才开始拒绝 - 常见误用：以为
nodelay是“关闭限流”，其实它只是关闭排队延迟，反而更容易触发拒绝（因不缓冲）
用日志精准定位被限请求的类型
启用 limit_req_log_level 和详细日志格式，区分是“排队中被丢弃”还是“瞬时超限被拒”：
- 在
http或server块中添加：
limit_req_log_level error; - 确保
error_log级别 ≥warn，这样限流拒绝会记为error级日志 - 观察日志中是否频繁出现：
*12345 limiting requests, excess: 5.123 by zone "mylimit"
其中excess值 > 0 且持续接近或超过burst，说明突发远超设计容量
用 curl + 时间戳验证实际响应延迟模式
手动模拟突发请求，观察响应时间与状态码变化，验证 nodelay 是否生效：
- 例如配置：
limit_req zone=mylimit burst=3 nodelay;
对应 rate=1r/s → 理论上最多 4 请求/秒（1+3）立即通过 - 发送 5 个并发请求：
for i in {1..5}; do curl -o /dev/null -s -w "%{http_code}:%{time_total}s\n" http://localhost/ -H "Host: test.com" & done; wait - 预期结果：
若带nodelay：前 4 个返回 200（时间 ≈ 0.01s），第 5 个返回 503
若不带nodelay：前 1 个 200（立刻），后 3 个 200（但延迟约 1s/个），第 5 个 503
检查 zone 共享范围与多 location 冲突
burst 和 nodelay 的效果依赖于 limit_req_zone 的 key 和作用域，常见协同错误源于 scope 不一致：
- 同一 zone 被多个
limit_req指令引用（如不同 location），但有的带nodelay、有的不带 → 实际行为以**最先匹配的指令为准**，后续指令无效 - key 设计不合理（如只用
$binary_remote_addr），导致不同用户共用一个桶，burst 被挤占 - zone 存储在 shared memory，但 worker 进程数多、burst 值小 → 高并发下因锁竞争导致实际队列行为偏离预期（可临时调大
zone大小测试）
