nodelay不实现平滑转发，而是放弃平滑换取低延迟：突发请求在burst容量内立即放行，超限则立刻503；它把burst当作瞬时并发许可，适合后端弹性强、业务拒斥排队的实时场景。
limit_req 的 nodelay 模式本身**不实现平滑转发**，它恰恰是放弃平滑、换取低延迟的策略。所谓“平滑转发”是 burst 配合无 nodelay 时的行为；而 nodelay 的作用是在突发允许范围内，让请求**立刻通过、不排队、不延迟**——这是对延迟敏感型接口的取舍，不是平滑。
nodelay 的真实行为：立即放行 or 立即拒绝
启用 nodelay 后，limit_req 不再按漏桶节奏逐个释放请求，而是把 burst 容量当作“瞬时并发许可”：
- 前 burst 个请求（含当前）全部立即处理，不等待、不缓冲
- 第 burst + 1 个请求，只要还没进入下一个速率窗口（如 rate=10r/s 对应每100ms一个新配额），就直接返回 503
- 它不拉长间隔，也不削峰填谷，只是把“排队等”换成“要么马上过，要么马上拒”
适合用 nodelay 的典型场景
只有满足以下条件时，nodelay 才是合理选择：
Blender Geometry Nodes Script Generator
下载
生成Blender Python (bpy)脚本，该脚本使用node_groups API和GeometryNodeTree接口程序化地创建几何节点修改器树，用于参数化3D资产生成。
- 后端能扛住 burst 规模的短时并发（例如已压测验证单机可处理 50 QPS，配置 burst=40 是安全的）
- 业务逻辑不允许排队（比如支付回调、短信验证码提交、秒杀下单，用户等待 >200ms 就可能重复触发）
- 前端已内置退避重试（收到 503 后延迟 1s、2s、4s 重发，避免雪崩式重试）
配置要点与避坑提醒
nodelay 不是万能加速键，错误使用等于形同虚设：
- burst 值不能过大（如设为 1000）+ nodelay：相当于只在内存耗尽时才限流，失去防护意义
- 不要全局加 nodelay：/health、/metrics 这类监控接口应禁用 nodelay，确保它们始终可被探测；核心业务接口才酌情启用
- 必须配合日志记录：在 log_format 中加入 $limit_key 和 $limit 变量，否则无法区分是哪个 IP 或用户 ID 触发了拒绝
对比无 nodelay：两种突发应对逻辑完全不同
假设 rate=5r/s、burst=10：
- 无 nodelay：10 个突发请求全部进队列，按每 200ms 放行 1 个，最后 1 个要等约 2 秒才处理
- 有 nodelay：前 10 个请求瞬间全过；第 11 个请求，若距离上一个配额释放不足 200ms，立刻 503
nodelay 的价值不在“平滑”，而在“确定性响应”——用户操作要么快，要么明确失败，不卡在中间状态。
