delay是limit_req触发限流后决定是否延迟响应而非直接拒绝的关键开关，其本质是在令牌桶满额但请求超出瞬时容量时允许等待新令牌生成以平滑突发流量、避免503。
delay 参数不是用来“柔性整形”或“过渡”的独立机制，而是 limit_req 在触发限流后、决定是否延迟响应（而非直接拒绝）的关键开关。它的作用本质是：**在令牌桶满额但当前请求超出瞬时容量时，允许等待，直到有新令牌生成再放行——从而平滑突发流量，避免粗暴 503。**
delay 的真实行为：等待 vs 拒绝
当配置如 limit_req zone=burst burst=5 delay=3; 时：
- 令牌桶容量为 5，每秒补充 1 个令牌（由
rate决定，此处假设为 1r/s）； - 前 5 个并发请求立即通过；
- 第 6 个请求到来时，桶已空 —— 此时 若未设
delay，Nginx 直接返回 503； - 若设了
delay=3，Nginx 允许该请求最多等待 3 秒，等新令牌生成（比如等 1 秒后桶里有了第 1 个新令牌），就放行； - 若等待超时（如 3 秒内仍无足够令牌），仍返回 503。
实现“柔性过渡”的核心配置组合
单靠 delay 不足以整形，必须配合 burst 和合理 rate：
-
burst定义缓冲区大小：容纳突发请求，避免立即拒绝； -
rate设定长期平均速率：决定令牌补充节奏，是整形的“锚点”； -
delay=N提供最大容忍延迟：让超出burst的请求有机会“排队”，而不是一刀切； - 实际效果 = “
burst内零延迟 + 超出部分最多等 N 秒” → 流量被拉长、削峰。
典型场景示例：应对短时脉冲
某接口正常 QPS 为 10，但允许 3 秒内最多 25 次请求（如页面加载带多个资源）：
- 配置：
limit_req zone=api burst=15 delay=3;（假设 rate=10r/s）； - 解释：桶容量 15，每秒补 10 个令牌；
- 第 1 秒涌入 25 请求 → 前 15 立过，后 10 个各等待 0.1～0.3 秒不等（因令牌匀速生成），全部在 3 秒内处理完；
- 若第 1 秒涌入 30 请求 → 后 15 个中，部分需等 >3 秒 → 超时被拒，守住长期速率底线。
注意事项与常见误区
delay 不是“降低限流强度”，而是改变失败策略：
- 它不会提升吞吐量，只是把部分 503 转为轻微延迟，用户体验更平滑；
-
delay值不宜过大（如设成 30），否则请求积压导致响应延迟不可控，可能引发上游超时； - 若希望完全不拒绝、只延迟，需确保
burst + delay × rate ≥ 最大预期突发量，但会牺牲实时性； -
delay=0表示“允许等待，但不主动延迟”——等价于不设delay，即立即拒绝（Nginx 1.13.8+ 行为）。
