burst 参数决定超额请求的缓冲池大小，如 burst=5 表示最多暂存 5 个请求；rate=1r/s 结合漏桶算法，令牌按固定速率生成且不累积，空闲时也不会补满，仅适用于匀速限流场景。
limit_req 的 burst 参数到底缓存多少请求
rate=1r/s 不代表每秒只放行 1 个请求，burst 才决定缓冲池大小。Nginx 默认 burst=0，此时超出速率的请求直接返回 503 Service Temporarily Unavailable，根本没缓冲这回事。
要启用缓冲，必须显式设置 burst，比如 burst=5 表示最多暂存 5 个超额请求，按排队顺序逐个释放（前提是未超时）：
limit_req zone=mylimit burst=5 nodelay;
注意：nodelay 会跳过排队、直接拒绝超额请求（等价于 burst=0），别误以为它“加速”——它其实是关掉缓冲的开关。
漏桶算法下 rate=1r/s 的真实放行节奏
Nginx 的 limit_req 基于漏桶（leaky bucket），不是滑动窗口。rate=1r/s 意味着：桶每秒“漏出”1个令牌，请求需持令牌才能通过。令牌不累积，最多存满 burst 个。
这意味着：
- 连续 2 个请求在 10ms 内到达 → 第 2 个被放入
burst缓冲区，等待约 1 秒后才被放行 - 第 3 个请求在 20ms 后到达 → 若
burst=2已满，则直接 503 - 空闲 2 秒后，令牌桶仍只有 1 个可用（漏桶不补满，只按固定速率补充）
所以它无法应对短时脉冲，更适合匀速压测或防爬虫慢速探测。
如何让 1r/s 看起来更“平滑”而不卡顿
单纯调大 burst 只是把拒绝延后，用户感知仍是延迟飙升。真正改善体验得靠组合策略：
- 用
burst=3 nodelay+ 自定义错误页，把部分超额请求快速返回带 retry-after 的 503，引导客户端退避重试 - 对非关键接口（如头像加载）改用
limit_req zone=mylimit burst=10（无nodelay），接受轻微排队但避免失败 - 配合
limit_req_status 429统一返回状态码，方便前端做节流降级 - 绝对不要给登录、支付等路径配
burst过大——突发流量可能压垮后端，漏桶只是第一道过滤，不是兜底
日志里看不到 limit_req 拒绝记录？检查 log\_format 和变量
默认 access log 不记录被限流的请求，它们甚至不进入日志阶段。要审计限流行为，必须主动注入变量：
log_format main '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent" '
'rt=$request_time uct="$upstream_connect_time" '
'uht="$upstream_header_time" urt="$upstream_response_time" '
'limit_status=$limit_status';
$limit_status 是关键变量，值为 -（未限流）、0（已限流且排队中）、1（已限流且立即拒绝）。没有它，你永远不知道哪次 503 来自限流、哪次来自上游崩了。
另外注意：limit_req 规则若写在 server 块里，对所有 location 生效；若只希望作用于 /api/，务必写进对应 location /api/ 块内，否则静态资源也会被误限。
