nodelay 不用于平滑限流，而是禁用 burst 缓冲、使超限请求立即返回 503；平滑限流需依赖 burst 配合默认延迟排队机制，以匀速释放积压请求实现削峰填谷。
在 Nginx 中，limit_req 的 nodelay 参数本身**不用于实现“平滑限流”**，而是用于**禁用延迟（burst 缓冲）行为**，让超过速率限制的请求立即被拒绝（返回 503），而不是排队等待。真正实现平滑限流（即允许短时突发、但长期平均达标）靠的是 burst + 默认的延迟排队机制，nodelay 反而会让限流更“陡峭”。
理解 nodelay 的真实作用
nodelay 是对 burst 的修饰：它不取消限流，而是取消“等待”。当配置了 burst=5 时，默认行为是——前 5 个超限请求会被暂存（按令牌桶剩余容量排队），等后续有空闲配额时再处理；加上 nodelay 后，这 5 个请求会立刻被拒绝，不排队、不延迟。
换句话说：
- ✅ 有 burst 无 nodelay → 允许突发 + 平滑释放（推荐用于平滑限流）
- ✅ 有 burst + nodelay → 允许极小突发（仅瞬时透支），但超了就秒拒（适合防扫描/强一致性场景）
- ❌ 无 burst → 严格按 rate 执行，任何超限都立即 503（最硬性限流）
配置平滑限流（推荐方式）
要达到“用户感觉不到卡顿、后端压力平稳”的效果，应依赖默认的延迟排队机制，而非 nodelay：
- 定义共享内存区，设置基础速率（如每秒 10 个请求）：
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s; - 在 location 中启用限流，并设置合理 burst 值（如 20）：
limit_req zone=api burst=20;
此时：10r/s 是长期均值，最多可瞬时接受 20 个“积压请求”，Nginx 会以 10r/s 的节奏逐步放出它们，实现削峰填谷。 - 可选：用
nodelay仅对某些关键路径关闭排队（如登录接口防爆破），但不是平滑限流所需：
limit_req zone=login burst=3 nodelay;
为什么 nodelay 不适合平滑限流？
开启 nodelay 后，所有超出 rate + burst 瞬间容量的请求都会立即失败，用户可能遭遇密集 503；而平滑限流的目标是“把突发请求摊开处理”，靠的是排队+匀速释放。Nginx 的令牌桶实现中，nodelay 实质是跳过“等待时间计算”，直接检查当前令牌数是否 ≥ 1 —— 它加速了拒绝，而非加速了处理。
验证与调优建议
- 用
ab或wrk模拟突发流量（如-n 100 -c 50），观察响应状态码分布和延迟曲线 - 配合
limit_req_status 429和自定义错误页，让客户端友好重试 - 监控
$limit变量（需开启log_format）或 Nginx stub_status，确认 burst 是否被有效利用 - burst 值建议设为 rate × 2～5（如 rate=10r/s → burst=20～50），具体根据业务容忍延迟的时长调整（burst=30 相当于最多排队 3 秒）
