nodelay模式需与burst配合实现低延迟静态流量平滑转发，它用令牌桶余量即时放行请求而非排队，适用于JS/CSS加载等场景；单独使用nodelay无效，burst过大（如>200）易导致过载。
要让 limit_req 的 nodelay 模式真正支撑低延迟静态流量的平滑转发，核心不是简单加个参数，而是让“瞬时放行”和“后端承载力”“前端行为”形成闭环。它适合那些不能排队、但又必须扛住小规模突发的静态资源场景，比如 JS/CSS 文件加载、CDN 回源请求、健康检查探针等。
明确 nodelay 的真实作用：不排队 ≠ 不限流
nodelay 不是关闭限流，而是把“排队等待”换成“即决判断”。只要令牌桶里还有余量（由 burst 定义），请求就立刻通过；没余量就直接 503。这对静态资源很关键——用户浏览器加载多个 CSS/JS 文件时，并发请求集中到达，排队会拖慢整页渲染，而 nodelay 能在不增加延迟的前提下，用 burst 提供的弹性空间消化这批突增。
-
burst是你的“瞬时缓冲容量”，不是并发上限。例如rate=50r/s + burst=30 + nodelay表示：每秒稳定处理 50 个请求，同时允许最多额外 30 个请求在同一毫秒级窗口内被立即检查并放行（只要桶未空） - 单独写
nodelay无效，必须和burst同时出现，否则 Nginx 忽略该参数 - 不要设过大的
burst值（如 >200）。静态资源通常响应极快（
针对静态资源的典型配置组合
静态内容本身无状态、处理开销低，但容易被爬虫、监控或前端脚本批量触发。配置需兼顾防护与效率：
用于自动切换项目中适合的node 版本
下载
根据 package.json 中的 engines 字段自动检测 Node.js 版本需求，未安装 nvm 时自动安装并切换至对应版本。支持 Windows、macOS、Linux。适用于 Node.js 项目开发、版本切换和环境配置。
- 通用静态资源（/static/、/assets/）：
limit_req zone=static burst=15 nodelay;
搭配limit_req_zone $binary_remote_addr zone=static:10m rate=40r/s;
——平衡单 IP 突发访问与缓存友好性 - 高频小文件（favicon.ico、healthz）：
limit_req zone=health burst=5 nodelay;
搭配limit_req_zone $binary_remote_addr zone=health:1m rate=5r/s;
——避免探测类请求挤占主资源配额 - CDN 回源路径（如 /cdn/）：
建议用更细粒度 key，例如$host$request_uri或$host$uri，防止热门 URL 被单个 IP 打爆limit_req_zone $host$uri zone=cdn:20m rate=100r/s;limit_req zone=cdn burst=25 nodelay;
必须配套的日志与验证手段
启用 nodelay 后，拒绝行为从“延后失败”变成“即时失败”，若无日志，你无法区分是攻击、误配还是正常突增。
- 在
log_format中加入关键变量：log_format main '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" $limit_key $limit'; - 观察
$limit_key是否合理（如是否把 CDN 回源 IP 错判为终端用户）、$limit是否为 “-”（未匹配限流区域）或具体 zone 名 - 用
ab或wrk模拟突发：例如wrk -t4 -c100 -d5s http://your.site/static/app.js，对比开启/关闭nodelay时的 503 比例与 P95 延迟变化
避开常见失效陷阱
很多配置看似生效，实则形同虚设：
- 把
nodelay加在全局location /下，却对所有接口一视同仁。静态资源可以宽松些，而 API 接口应独立限流 zone，避免相互干扰 - 用了
$binary_remote_addr作为 key，但在公司出口、移动运营商 NAT 环境下，大量用户共享一个 IP，导致误伤。此时可考虑加 header（如$http_x_real_ip）或结合 cookie 做二级识别 - 未调整
limit_req_status，默认 503 对前端不友好。静态资源建议设为 429：limit_req_status 429;，便于前端做退避重试
