nodelay 是在令牌桶算法中跳过等待，使超限请求立即按策略处理而非排队延迟；它不提升吞吐量，仅避免突发延迟，适用于延迟敏感且可容忍丢弃的场景。
使用 limit_req 的 nodelay 参数，本质是在令牌桶算法基础上“跳过等待”，让超出速率限制的请求不排队、不延迟，而是立即按配置策略处理（如拒绝或放行）。它不提升吞吐量，但能避免突发时的累积延迟，适合对响应延迟敏感、可容忍少量超限请求丢弃的场景。
理解 nodelay 的作用机制
nodelay 并非取消限流，而是关闭“请求排队等待令牌”的行为：
- 默认情况下（无
nodelay），当令牌桶为空，新请求会进入队列等待，直到有令牌可用——这会导致突发流量下响应延迟陡增； - 加上
nodelay后，请求到达时若无可用令牌，Nginx 不排队、不等待，直接根据burst和当前桶状态决定是否立即拒绝（返回 503）或允许通过； - 关键点：它只影响“等待行为”，不改变令牌生成速率（
rate）和桶容量（burst）。
典型配置与突发应对逻辑
例如以下配置：
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;server {
location /api/ {
limit_req zone=api burst=20 nodelay;
}
}
含义是：
- 基础速率：每秒最多 10 个请求（令牌生成速度）；
- 桶容量：最多缓存 20 个“预支”请求（burst=20）；
-
nodelay：所有请求都尝试立即处理——前 20 个突发请求（含桶中初始空位）可秒级通过，第 21 个及之后的请求将立刻被拒绝（503）； - 注意：burst 容量不是额外配额，而是允许“瞬时透支”的上限，且透支部分不会延后补还，只在桶有空余时才生效。
配合 error_page 实现友好降级
由于 nodelay 下超限请求会快速失败，建议用 error_page 捕获 503 并返回更友好的响应：
server {
error_page 503 @rate_limit_exceeded;
location /api/ {
limit_req zone=api burst=15 nodelay;
}
location @rate_limit_exceeded {
return 429 '{"error":"Too many requests, please try again later"}';
add_header Content-Type "application/json";
}
}
这样既保持低延迟，又提升客户端体验。
慎用场景与常见误区
nodelay 不适合所有情况：
- 若后端处理能力本身有限（如数据库连接池小），放行 burst 请求可能引发雪崩——此时应优先限流+排队（即不用 nodelay），让压力平滑传导；
- 误以为
nodelay+ 大burst能“扛住高并发”：实际只是把拒绝动作提前，未提升系统真实承载力； - 未配合日志记录：建议开启
limit_req_log_level warn，便于监控被限流的频率和来源。
