rate=1r/s 实际是每100ms允许1个请求；burst=5且无nodelay时，5个请求排队按节奏释放，第6个起返回503；加nodelay则前5个立即处理，超限即刻503；配合limit_req_status和日志可精准监控调优。
rate=1r/s 是 Nginx 限流中最基础也最易误用的配置，它表面看是“每秒1个请求”，实际行为却高度依赖 burst 和 nodelay 的组合。真正实现流量平滑的关键，不在于把 rate 设得多小，而在于让突发请求有缓冲、有节奏、不堆积也不丢弃过猛。
rate=1r/s 的真实时间粒度：不是“每秒一次”，而是“每100ms一次”
Nginx 内部以毫秒级精度调度 limit_req，rate=1r/s 实际等价于“每100毫秒允许处理1个请求”。这意味着：
- 第0ms收到请求 → 立即处理
- 第50ms又来一个 → 进入等待（若未设 nodelay）或直接拒绝（若 burst 已满）
- 第100ms再收一个 → 可立即处理（因上一请求已释放配额）
这个机制天然适合削峰填谷——它不阻断高频访问，而是强制拉长请求间隔，让后端始终以稳定节奏承接。
burst=5 + 无 nodelay：最稳妥的平滑队列模式
这是应对真实业务突发流量的推荐组合：
- limit_req zone=one burst=5; —— 允许最多5个请求排队等待
- 请求到达时，若当前速率未超限，直接处理；否则进入FIFO队列
- 队列中的请求按 rate 节奏依次释放（例如每100ms放出1个）
- 第6个及以后的请求，立刻返回 503（默认状态码）
效果：用户连续点击5次能全响应，但第6次开始提示“操作太频繁”，体验可控且可预期。
burst=5 + nodelay：适合低延迟敏感型接口（慎用）
加了 nodelay 后，行为彻底改变：
- 前5个请求（burst内）全部立即处理，不排队
- 第6个请求开始，只要没到下一个100ms窗口，就直接 503
- 它牺牲了“平滑性”，换来了“瞬时吞吐能力”
适用场景：登录页、短信验证码接口等需快速响应但绝不容许刷量的环节。注意：此时 burst 不是“缓冲区”，而是“特批额度”，用完即止。
配合 limit_req_status 和日志，让限流可观察、可调优
仅限流不够，还要知道谁被限、为什么被限：
- 显式设置状态码：limit_req_status 429;（更符合语义，替代默认503）
- 在 log_format 中加入变量：$limit_req_status 和 $limit_req_key
- 错误日志里会记录类似：excess: 2.998 by zone "one", client: 203.0.113.45，表示该IP超额近3个配额
有了这些数据，就能区分是真实用户连点，还是爬虫试探，进而动态调整 burst 或引入白名单。
