如何利用limit_req模块的nodelay参数优化反代网关转发，降低延迟？

本文共计855个文字，预计阅读时间需要4分钟。

使用 `limit_req 和 `nodelay 参数，可以在 Nginx 反向代理网关中实现低延迟请求的快速转发。关键在于绕过排队等待，允许突发流量临时通过，同时保持速率控制能力。

理解 nodelay 的作用机制

nodelay 并非关闭限流，而是禁用“令牌桶”的排队延迟行为。默认情况下，当请求超过设定速率（如 10r/s），Nginx 会将超额请求放入队列，按桶填充节奏逐个释放——这带来毫秒级甚至更高延迟。启用 nodelay 后，Nginx 立即检查当前令牌数：有余量则放行，无余量则直接返回 503（或按配置拒绝），不排队、不等待。

• 适合对 P99 延迟敏感的 API 网关，例如实时风控、消息推送、WebSocket 连接建立等场景
• 必须配合 burst 使用，否则无余量时所有超限请求立即被拒，无法缓冲突发
• 实际效果是：平滑流量走限速逻辑，突发流量靠 burst + nodelay 瞬时消化，不堆积不延迟

典型配置示例（低延迟网关）

以下配置适用于每秒稳定 100 请求、允许最多 50 次突发、且绝不引入排队延迟的反代网关：

limit_req_zone $binary_remote_addr zone=api:10m rate=100r/s; <p>server { location /api/ { proxy_pass <a href="https://www.php.cn/link/65b5b8d1f89bf53a5713bc3afdd83e9e">https://www.php.cn/link/65b5b8d1f89bf53a5713bc3afdd83e9e</a>; limit_req zone=api burst=50 nodelay; limit_req_status 429; # 超出 burst 才返回 429，更利于客户端重试判断 } }

• burst=50 表示令牌桶可额外暂存 50 个“信用”，供突发请求即时消耗
• nodelay 确保这 50 次突发请求在抵达瞬间完成校验并转发，无排队延迟
• 若第 51 次突发请求到达，且桶已空，则立即返回 429，不等待

与 delay 行为对比（关键差异）

不加 nodelay 时，相同配置下突发请求会被强制延迟释放，导致首字节时间（TTFB）升高：

• 例如 burst=50，第 45 个突发请求可能被延迟 440ms（按 100r/s 计算）才发出
• 加上 nodelay，前 50 个全部在微秒级内完成限流判断并进入 proxy 流程
• 真实网关中，这能将 P99 延迟从 300ms+ 压至 20ms 内（取决于后端性能）

注意事项与调优建议

nodelay 提升响应速度，但也放大后端瞬时压力，需协同设计：

• burst 值不宜过大，应略高于业务实测最大秒级峰值，避免打垮上游服务
• 建议搭配 proxy_buffering off 和 tcp_nodelay on，进一步减少代理层缓冲延迟
• 监控 limit_req_rejected 和 limit_req_delayed（后者在 nodelay 下恒为 0）指标，验证是否真正零排队
• 若需部分请求“降级延迟”而非直接拒绝，可用两个 limit_req 指令分层控制（如先宽松 nodelay，再严格 delay）