nodelay 不取消限流，而是让合规请求毫秒级转发、不排队；它关闭漏桶等待环节，仅瞬时判断令牌有无，配合 burst 实现弹性突发，P99 延迟可压至 1–5ms。
启用 nodelay 不是为了取消限流，而是让合规请求跳过排队、毫秒级转发，把延迟控制权交还给业务本身。
理解 nodelay 的真实作用
默认的 limit_req 使用漏桶机制：超限请求会进队列等待，直到“水位”下降才被处理——这带来不可控的排队延迟（比如 burst=50、rate=100r/s 时，第45个请求可能被卡住440ms）。nodelay 关闭的就是这个等待环节：系统只做一次瞬时判断——有令牌立刻放行，没令牌立即拒绝（返回 503 或自定义状态码），不排队、不缓冲、不等待。
- 它不改变限流阈值，rate 和 burst 仍决定“谁有资格被放行”
- 所有未被拒绝的请求，从匹配规则到进入
proxy_pass全程无排队，P99 延迟可压至 1–5ms 级别 - 真正优化的是“合法请求的确定性低延迟”，不是“让更多请求通过”
burst 与 nodelay 必须协同配置
nodelay 单独使用（尤其是 burst=0）等于硬限流，流量稍有抖动就大量 503，客户端重试反而引发雪崩。burst 是它的安全垫，代表允许瞬时透支的请求数量。
-
burst=20表示最多容许 20 个请求“提前消费”未来几秒的配额 - 这些请求在抵达瞬间完成校验并转发，不排队——这就是“弹性突发”的实现方式
- 典型低延迟场景推荐组合：
rate=100r/s+burst=50+nodelay，效果≈“稳态 100 QPS + 瞬时 50 请求无损通过”
避免常见误用陷阱
加了 nodelay 却没调优，可能让延迟问题从 Nginx 转移到后端或网络层。
- 不要设
burst=0：失去缓冲能力，毛刺流量直接打穿可用性 - 慎用
limit_conn混合限流：连接数瓶颈可能掩盖limit_req的优化效果 - 后端慢时，Nginx 转发快了反而加剧上游积压——必须监控
$upstream_response_time做端到端观测 - 未透传
request_id或trace_id：503 发生时无法区分是限流拦截还是业务异常，拖慢问题定位
验证与可观测性要点
上线前必须实测行为是否符合预期，不能只看配置写对了没有。
- 用
wrk -t4 -c100 -d5s模拟突发，观察 503 比例是否贴近理论值（如 100r/s + burst=50，在 5 秒内突增 600 请求，应约 550 成功、50 失败） - 在 access_log 中加入
$limit_req_status（需 Nginx ≥1.13.8），区分 “-”（未限流）、“h”（命中 burst）、“l”（被限流拒绝） - 配合
limit_req_status 429显式返回 429，比默认 503 更利于客户端识别和退避
