nodelay 通过跳过排队、立即放行或拒绝请求，消除限流环节的等待延迟，使合规请求毫秒级转发；必须配合 burst 使用，burst 定义瞬时弹性容量，单独使用无效。
启用 nodelay 并不能“提升”单个请求的处理速度，而是**消除限流环节引入的排队延迟**，让合规请求在毫秒级内完成限流判断并进入转发流程。它不加快后端响应，但能确保 Nginx 层不成为低延迟链路的瓶颈。
核心机制：跳过等待，不是加速处理
nodelay 关闭的是令牌桶算法中的“等待新令牌生成”行为。默认情况下，超限请求会排队等待（哪怕只等几毫秒），而开启后：
- 有令牌 → 立即放行，走 proxy 或静态服务，无额外延迟
- 无令牌 → 立即返回 503 或 429，不排队、不缓冲、不占用连接
- burst 值在此模式下变为“瞬时弹性容量”，而非排队长度
必须配合 burst 使用才有效
单独写 nodelay 不生效，它依赖 burst 定义可瞬时透支的请求数：
-
rate=100r/s burst=30 nodelay：每秒稳定放行 100 个，最多允许 30 个突发请求立刻通过 - 第 31 个及后续超限请求，直接拒绝，不延迟
- 若
burst=0，等价于硬限流，稍有抖动就大量失败，反而损害可用性
降低端到端 P99 延迟的关键操作
要让 nodelay 真正体现低延迟效果，需同步优化代理链路：
- 关闭缓冲：
proxy_buffering off;，避免 Nginx 缓存响应体拖慢首字节时间 - 禁用 Nagle：
tcp_nodelay on;，减少小包合并带来的微秒级延迟 - 区分路径限流：对缓存命中率高的静态资源或 API，单独配置宽松的
burst + nodelay；对穿透类请求走更严策略 - 记录限流状态：
log_format中加入$limit_req_status，便于识别是 “passed”、“rejected” 还是 “delayed”
典型低延迟场景配置示意
适用于实时风控、商品详情页、JS/CSS 回源等对 RT 敏感的路径：
limit_req_zone $binary_remote_addr zone=api:10m rate=200r/s;
server {
location /api/v1/check/ {
limit_req zone=api burst=100 nodelay;
limit_req_status 429;
proxy_pass http://backend;
proxy_buffering off;
tcp_nodelay on;
}
}
该配置意味着：日常 200 QPS 稳定处理，短时 100 请求可零等待穿透，超出即刻反馈 429，不堆积、不拖慢正常请求。
