limit_rate 不降低并发连接数上限，但延长单连接占用时长，加剧资源竞争；与limit_conn联用易致503；建议配合limit_rate_after和特定location限速。
限制带宽（limit_rate）本身不会直接减少服务器的并发连接数上限，但它会显著影响连接的实际占用时长和资源消耗，从而间接加剧并发瓶颈。
带宽限制延长单连接生命周期
当启用 limit_rate（例如 limit_rate 50k）时，Nginx 向客户端发送响应数据的速度被压低。即使后端已快速生成完响应，Nginx 仍需花更长时间把数据“一节一节”吐出去。这意味着：
- 一个下载大文件的连接可能从几百毫秒拉长到几十秒甚至几分钟
- 该连接在 Nginx 的连接池中持续占用 fd、内存和 worker 进程资源
- worker_connections 配额被缓慢释放，新请求更容易排队或被拒绝
与 limit_conn 协同时易触发 503
如果同时配置了 limit_conn（如每个 IP 限 10 并发），带宽限制会让“已建立的连接”迟迟不关闭：
- 用户开 10 个标签页下载视频 → 迅速占满 10 个连接配额
- 第 11 次访问（哪怕只是刷个页面）因无空闲连接被直接返回 503
- 现象是“静态资源也打不开”，但日志里看不到限速记录，只看到连接拒绝
对后端 upstream 无直接影响，但放大延迟风险
limit_rate 只作用于 Nginx → 客户端这一段的响应体传输，不影响 Nginx → upstream 的通信速度。但要注意：
- 若 upstream 响应快、Nginx 限速慢，大量连接卡在“等待发完数据”状态
- 若后端本身响应慢（如数据库卡顿），再叠加限速，连接堆积更严重
- 此时
keepalive_timeout和client_body_timeout等超时设置会变得更关键
更合理的带宽控制策略
单纯全局限速体验差且副作用大。推荐组合使用：
- 用
limit_rate_after 1m：前 1MB 不限速，让用户快速看到开头，再开始限速 - 仅对特定 location（如
/download/或/*.mp4）启用限速，避免影响 API 或 HTML - 配合
limit_conn时，给下载类 location 单独设更高连接数（如limit_conn addr 20），并监控连接平均时长
