delay参数控制请求排队行为，为burst队列提供“免等待名额”：前N个超限请求立即处理，其余按令牌桶节奏延时调度；其值不超过burst，未设置时默认delay=0。
delay 参数是 limit_req 模块中控制“请求排队行为”的关键开关，它不改变限流阈值本身，而是决定超出基础速率（rate）的请求是否立刻被处理、延迟处理，还是直接拒绝。用好 delay，能避免突增流量被粗暴拦截，同时防止后端被压垮。
delay 的真实作用：给 burst 队列加个“免等待名额”
burst 定义的是可暂存的请求数量，但这些请求默认不是立刻执行的——Nginx 会按令牌桶节奏逐个释放。delay 就是告诉 Nginx：“在 burst 队列里，前 N 个请求可以跳过等待，直接进入处理流程”。
- 例如：
rate=5r/s; burst=10; delay=3表示：每秒最多放行 5 个请求；超出的请求最多缓存 10 个；其中最先到达的 3 个超限请求无需等待，立即处理；其余 7 个则按每 200ms 一个的节奏延时调度 - 若未显式写 delay，默认等效于
delay=0，即所有超限请求都严格排队，哪怕只超 1 个也要等 - delay 值不能超过 burst，否则会被自动截断为 burst 值
与 nodelay 的本质区别：不是“开或关”，而是“分层响应”
nodelay 是一种极端策略：只要超过 rate，全部超限请求立刻返回 503，不排队也不延迟。而 delay 提供的是中间态——既不全放、也不全拒，而是让一部分有“优先通行权”。
-
nodelay：适合强一致性接口（如支付回调），不允许任何积压，宁可失败也不延迟 -
delay=N：适合用户可见的页面或 API（如搜索、列表加载），允许少量突发访问“秒开”，其余平滑消化 - 不写 delay 也不写 nodelay：最保守模式，所有请求严格匀速，适合后台任务类接口
配置建议：结合业务特征设置合理 delay 值
delay 不是越大越好。过大的 delay 会让 burst 队列实际变成“伪限流”，失去保护后端的意义；太小又起不到缓冲效果。推荐按以下逻辑判断：
- 前端有防抖/节流（如按钮点击限制），delay 可设为 1～2，覆盖用户误操作重试
- 移动端弱网场景多，用户可能反复刷新，delay 设为 3～5，容纳短时重连波动
- 后端单请求平均耗时约 100ms，且最大并发承受力为 50，那么 burst=10 + delay=3 是较安全的组合
- 若使用了 CDN 或前端缓存，真实穿透到 Nginx 的请求已大幅减少，delay 可适当调低，甚至省略
配合日志与状态码，让 delay 行为可观察
仅靠 delay 参数无法直观判断其是否生效。建议同步配置以下指令，便于定位问题：
-
limit_req_log_level warn;：当请求因 delay 队列满而被拒绝时，记录 warning 级别日志 -
limit_req_status 429;：把默认的 503 改为标准限流状态码 429 Too Many Requests，方便前端识别并提示用户 - 在 access_log 中加入
$limit变量（需编译支持或使用 openresty），可记录当前请求是否命中限流逻辑
