limit_req 的 delay 参数实现静态请求速率柔性过渡，即允许 n 个请求立即通过、其余按间隔平滑释放，兼顾首屏速度与后端安全。

用 limit_req 的 delay 参数实现静态请求速率的柔性过渡，核心是让突发流量“软着陆”——不直接拒绝，也不全量压向后端，而是让一部分请求立刻通过、其余平滑释放。这特别适合静态资源（如 JS、CSS、图片）在缓存未命中或 CDN 回源时的保护场景。

理解 delay 在静态请求中的实际作用

静态资源通常响应快、计算开销低，但并发高时仍可能击穿上游缓存或压垮源站。delay 不改变限流基线（rate），只调控 burst 队列里的调度优先级：

• rate=10r/s 表示每秒最多匀速放行 10 个请求
• burst=20 表示最多缓存 20 个超限请求
• delay=5 表示这 20 个缓存请求里，最先到的 5 个跳过排队、立即处理；剩下 15 个按 100ms 间隔逐个释放（因为 1/10r/s = 100ms）

针对静态资源的典型配置策略

静态请求路径明确、无状态，适合按 IP 或 URL 哈希做细粒度限流。关键在于 delay 值要匹配资源特性：

• 对高频小文件（如 favicon.ico、监控探针）：rate=5r/s; burst=10; delay=2 —— 允许极短突增，避免探测请求被误杀
• 对中等体积资源（如 CSS/JS 文件）：rate=20r/s; burst=30; delay=8 —— 支持页面首次加载的并发请求，后续请求匀速消化
• 对大图或字体文件（带宽敏感）：rate=3r/s; burst=5; delay=1 —— 控制回源压力，避免多个大请求挤占带宽

与 nodelay 和无 delay 的对比选择

静态资源不是强事务接口，完全拒绝（nodelay）会引发页面白屏或加载失败；而零 delay（即默认严格排队）又会让用户感知明显卡顿。delay 提供中间解法：

• nodelay true：所有超限请求立刻 503，适合健康检查探针，不适合真实用户请求
• 不写 delay（等效 delay=0）：所有 burst 请求严格排队，适合后台日志上报类静态接口
• 显式设置 delay=N：N 个请求免等待，其余延时释放，兼顾首屏速度与后端安全，是静态资源推荐模式

配合 key 和共享内存提升效果

静态资源限流效果依赖 key 粒度和状态共享：

• 用 $binary_remote_addr 按客户端 IP 限流，防止单个用户刷资源
• 对 CDN 回源场景，改用 $http_x_forwarded_for 或组合 key（如 $binary_remote_addr$uri），避免不同资源共用同一桶
• zone 大小建议 ≥ 10m，确保高并发下状态不溢出；若跨节点需搭配 redis-cluster 策略