delay 参数实现分层限流：前N个超限请求秒级放行，其余平滑调度；值≤burst，配合日志与429状态码监控可调优，需据业务场景合理设置。

用好 delay 参数，核心是让突发流量“有层次地消化”，而不是一刀切拒绝或全盘放行。它不改变限流底线，但改变了超限请求的调度优先级，从而在保护后端和维持用户体验之间找到可落地的平衡点。

delay 的真实作用：给 burst 队列设“快速通道”

burst 定义的是最多能暂存多少个超限请求，但默认情况下，这些请求都要排队等令牌——哪怕只超 1 个，也要按节奏一个一个放行。
delay 就是告诉 Nginx：“burst 队列里，前 N 个请求可以跳过等待，直接交给后端处理”。
这相当于在严格漏桶模型中，为短时突增开了几条“免排队通道”。

• 例如：rate=5r/s; burst=10; delay=3 表示：每秒基础放行 5 个；最多缓存 10 个超限请求；其中最先到达的 3 个超限请求立刻执行，其余 7 个按每 200ms 一个的节奏延后调度
• 未设置 delay 时，默认 delay=0，所有超限请求都严格排队
• delay 值不能超过 burst，否则会被自动截断为 burst 值

与 nodelay 的本质区别：不是“开/关”，而是“分层响应”

nodelay 是极端策略：只要超 rate，全部超限请求立刻返回 503，不排队、不缓冲、不等待。
delay=N 则是一种分级响应机制：允许 N 个请求“秒开”，其余平滑释放，既避免用户感知卡顿，又防止后端瞬时压垮。

• 适合强一致性接口（如支付回调、订单确认），用 nodelay：宁可失败，也不接受延迟或积压
• 适合用户可见的页面或 API（如搜索页、商品列表、登录页），用 delay=3～5：覆盖弱网重试、前端防抖失效、用户误点等常见波动
• 若后端单请求平均耗时约 100ms，最大并发承受力为 50，推荐组合 burst=10; delay=3：既留出缓冲空间，又不致队列虚高失守

配置时的关键配合项：让 delay 行为可观察、可调优

仅靠 delay 无法判断是否生效。必须搭配日志与状态码监控，才能真正闭环优化。

• 加 limit_req_log_level warn;：当 delay 队列满、请求被拒绝时，记录 warning 级日志，便于定位瓶颈点
• 配合 limit_req_status 429;（可选）：将限流拒绝统一返回 429，方便前端识别并做友好提示
• 若已使用 CDN 或前端强缓存，穿透到 Nginx 的真实请求数大幅下降，delay 可适当调低甚至省略，避免过度缓冲

实际部署建议：按业务特征定 delay，不追求理论最优

delay 不是越大越好。过大等于变相放宽限流，失去保护意义；过小则起不到缓冲效果，仍易触发用户侧重试雪崩。

• 前端已有按钮防抖或请求节流：delay 设为 1～2，覆盖单次误操作重发
• 移动端为主、弱网场景多：delay 设为 3～5，容纳短时网络抖动引发的集中刷新
• 后台任务类接口（如定时同步、数据导出）：可不设 delay，走最保守匀速模式
• 上线前用 ab 或 wrk 模拟突发流量，观察 429 返回比例、平均延迟、后端 CPU/连接数变化，再微调 delay 和 burst