limit_req 的 delay 参数仅控制本地请求排队等待，不参与负载均衡或柔性整形。它允许 burst 队列中最多 n 个请求按令牌桶节奏匀速放行，而非智能调度或跨节点协同；负载均衡由 upstream 配置决定。
limit_req 的 delay 参数并不用于负载均衡，也不能实现“柔性整形保障”。这是一个常见误解。Nginx 的 limit_req 指令本身是单机限流机制，作用于单个 Nginx 实例的请求入口，与上游服务的负载均衡逻辑无关，也不具备跨节点协同、动态调度或流量整形（如平滑延迟注入、优先级排队）能力。
delay 参数的真实作用：控制排队等待行为
当请求超过 limit_req 定义的速率（burst 队列未满时），delay 参数决定是否将超额请求**暂缓执行**而非立即拒绝：
-
delay=1：允许最多 1 个请求进入延迟队列，其余超限请求直接返回 503（若 burst 耗尽） -
delay=N：允许最多 N 个请求排队等待，按令牌桶恢复节奏逐个放行 - 不加 delay（或 delay=0）：所有超出 rate + burst 的请求立即拒绝，无等待
它本质是“本地缓冲+匀速释放”，不是“智能调度”或“负载感知”。延迟时间由当前令牌桶水位和 rate 决定，Nginx 不会主动探测后端健康状态或响应时长。
真正影响负载均衡效果的是 upstream 配置
要让流量在多台后端间合理分摊，需依赖：
— upstream 块中的负载均衡算法（round_robin、least_conn、ip_hash 或 hash $request_uri consistent）
— 健康检查（health_check）自动剔除故障节点
— 连接复用（keepalive）降低握手开销
— 后端权重（weight=）适配异构机器性能
limit_req 只是在请求到达 upstream 之前做前置节流，它可能反而加剧不均衡——比如 burst 排队导致请求集中涌向某台后端（因 Nginx 默认 round_robin 是连接粒度，非请求粒度）。
需要柔性限流？应分层设计
单一 Nginx 很难做到“柔性整形保障”，建议组合使用：
-
接入层限速：用
limit_req zone=api burst=20 delay=5防雪崩，保护自身和下游 - 应用层熔断：后端服务内嵌 Sentinel / resilience4j，基于 RT、异常率动态降级
- 网关层协调：使用 Kong / APISIX 等支持分布式限流（Redis 计数）、自适应限流（如根据系统 Load 调整阈值）的网关
- 客户端配合：对重试请求添加 jitter 和指数退避，避免请求风暴
一个典型误用场景
有人配置：limit_req zone=global burst=100 delay=50;
并认为“这样能让 100 个请求均匀分到 5 台后端”。这是错误的——Nginx 不会因为 delay 就改写 upstream 路由逻辑。这 100 个排队请求仍按原有 upstream 策略（如 round_robin）依次转发，可能前 20 个全打到第一台，后 20 个才轮到第二台，造成瞬时压差。
