nginx 不支持直接限制 upstream 集群整体带宽，其 limit_rate 仅面向单连接限速；需通过 limit_rate（单连）、limit_conn/limit_req（并发与请求节奏）、后端限速及系统级 tc 四层协同实现软性总量约束。
Nginx 本身不支持直接限制整个 upstream 集群的“整体最大并发带宽”（例如：所有后端加起来总出口带宽不超过 100 Mbps）。它的带宽控制机制 limit_rate 是面向单个客户端连接的响应流控，作用在 http → server → location 链路的出向响应阶段，与 upstream 分发逻辑无关，也无法聚合统计或限制所有后端节点的总流量。
但你可以通过组合策略，间接实现对 upstream 集群出口带宽的软性约束和合理分流。关键思路是：从客户端入口限速 + 后端承载能力对齐 + 连接复用优化，避免带宽被少数大流量请求耗尽。
使用 limit_rate 控制单连接响应带宽（最常用）
这是 Nginx 唯一原生支持的带宽限制方式，适用于防止个别大文件下载/上传拖垮整体网络：
location /download/ {
proxy_pass http://backend;
proxy_http_version 1.1;
proxy_set_header Connection '';
# 限制每个客户端连接的响应速率（单位：字节/秒）
limit_rate 2m; # 即 2 MB/s ≈ 16 Mbps 每连接
}
- ✅ 生效于每个活跃连接，无需共享内存区
- ✅ 可放在
location级，按路径精细化控制 - ❌ 不是“集群总带宽上限”，若 100 个用户同时下载，理论峰值达 100 × 16 Mbps
提示：
limit_rate_after 10m;可设为“前 10MB 不限速，之后限速”，改善小文件体验。
用 limit_conn + limit_req 协同压住并发连接数与请求数
虽然不直接控带宽，但能有效抑制高并发下的总流量基线：
# 定义每 IP 最大连接数（防慢攻击、连接堆积）
limit_conn_zone $binary_remote_addr zone=perip:10m;
# 定义每 IP 请求速率（防刷、控节奏）
limit_req_zone $binary_remote_addr zone=qps:10m rate=50r/s;
server {
location /api/ {
limit_conn perip 10; # 每 IP 最多 10 个并发连接
limit_req zone=qps burst=30 nodelay;
proxy_pass http://backend;
}
}
- 减少空闲长连接数量 → 降低 TCP 连接开销与内存占用
- 控制请求到达节奏 → 避免后端瞬时吞吐超载，间接稳定带宽使用曲线
后端侧统一限带宽（推荐，更精准）
Nginx 是代理层，真正决定“发多少数据出去”的是后端服务本身。让后端控制更可靠：
-
Spring Boot：通过
server.tomcat.connection-timeout+ 自定义 Filter 限速响应体 -
Go HTTP Server：用
http.Server{WriteTimeout: 30s}+ 中间件控制ResponseWriter写速 -
Node.js（Express）：用
express-rate-limit或stream.pipeline+throttle包 -
Nginx Plus（商业版）：支持
proxy_buffering off+limit_rate透传至 upstream，但开源版不支持
✅ 优势：带宽统计真实（含压缩、分块等）、可结合业务逻辑（如 VIP 用户不限速）、不受 Nginx worker 分布影响。
补充：系统级兜底（Linux TC）
若必须硬限整个 Nginx 进程出口总带宽（比如物理网卡出口），需脱离 Nginx，在操作系统层用 tc（Traffic Control）做 QoS：
# 示例：限制 nginx 出口总带宽为 100Mbps（eth0 网卡） tc qdisc add dev eth0 root tbf rate 100mbit burst 32kbit latency 400ms
- ⚠️ 注意：这是主机级全局限速，影响所有进程，非 Nginx 特有
- ⚠️ 需 root 权限，运维复杂度高，一般用于 IDC 边界网关而非应用服务器
不复杂但容易忽略：Nginx 的带宽管理本质是「连接粒度」的，不是「集群粒度」的。真要控总量，得靠上游限速+下游节流+系统兜底三层配合。
