nodelay 通过跳过请求排队、即时放行或拒绝来降低延迟，需配合 burst 使用，配置时须同时设置 limit_req_zone 和 limit_req 指令，并建议显式指定 limit_req_status 429。
用 nodelay 优化突发请求，核心是让合法突发流量“秒过”，不排队、不卡顿，同时守住后端承载底线。它不是关掉限流，而是改掉排队逻辑。
为什么 nodelay 能降低延迟
默认限流下，超速请求会被塞进队列，按令牌生成节奏逐个放出——比如 rate=100r/s，第45个突发请求可能被压住440ms才转发。启用 nodelay 后，Nginx 立即查令牌余量：有就放行，没有就立刻拒绝（如返回429），完全跳过等待环节。
- 适合对首字节时间（TTFB）敏感的场景，比如实时风控、消息推送、API网关
- 必须搭配
burst使用，否则没缓冲空间，一超限就全拒 - 实际效果是：平滑流量走匀速通道，突发流量靠 burst + nodelay 瞬时消化
nodelay 的正确配置方式
关键在两处指令协同：
- 先定义限流区域：
limit_req_zone $binary_remote_addr zone=api:10m rate=100r/s; - 再在 location 中启用并加参数：
limit_req zone=api burst=50 nodelay; - 建议显式设置拒绝状态码：
limit_req_status 429;，方便客户端识别重试
注意：burst=50 表示桶里最多能“欠”50次请求；nodelay 让这50次全部在微秒级完成判断并进入 proxy 流程。
常见误区与避坑点
很多人配了 nodelay 却没效果，问题往往出在：
- 只写了
limit_req_zone，漏掉limit_req指令——限流根本不会生效 - 把
limit_req和limit_conn混用，后者管并发连接数，和请求速率无关 -
burst设得太小（如 burst=1），突发稍大就直接 429，起不到缓冲作用 - 没考虑白名单需求，可配合
geo+map实现内网或运维IP不限流
效果对比：加与不加 nodelay
相同配置 rate=100r/s burst=50：
- 不加
nodelay：第48个突发请求可能被延迟约470ms才发出，P99 延迟容易突破300ms - 加
nodelay：前50个请求全部即时转发，后续超限请求立刻返回429，P99 可压到20ms以内（取决于后端）
本质是把“延迟处理”变成“即时决策”，把延迟压力从 Nginx 移交给客户端或上游重试机制。
