proxy_upload_rate 是 Nginx（需 OpenResty 或特定编译）中用于限制每个 proxy_pass 连接发往后端的上传速率的指令，其总出口带宽 = 单连接速率 × 活跃连接数，需结合 upstream keepalive、worker_connections 和 limit_conn 等协同控制。
proxy_limit_rate 并不是 Nginx 官方指令，你实际想用的是 proxy_upload_rate（控制发往后端的出向带宽）或 limit_rate（控制发往客户端的响应带宽）。结合 worker 并发数来控制整体出口带宽，关键在于理解：Nginx 的带宽限制是 per-connection 的，不是 per-worker 或全局的。
下面以最贴近你需求的场景——四层/七层代理中限制发往后端的总出口带宽（比如爬虫出口、上游服务调用）——来说明如何用 proxy_upload_rate + worker 配置达成可控、可预期的总带宽。
? proxy_upload_rate 的作用粒度很关键
它不作用于整个 worker 进程，也不作用于整个 upstream 组，而是作用于每一个从 Nginx 主动发起的 proxy_pass TCP 连接。
这意味着：
- 每个连接独立限速，比如设为
proxy_upload_rate 100k;→ 单连接最大上传速率 ≈ 100 KB/s - 若当前有 20 个并发连接打到同一后端，理论总出口带宽 ≈ 20 × 100 KB/s = 2 MB/s
- 实际值受
worker_connections、keepalive复用、后端响应速度、TCP 拥塞控制等影响，但趋势稳定
✅ 所以“控制整体出口带宽”的本质，就是：控单连接速率 × 控活跃连接数
? 如何协同配置：proxy_upload_rate + worker 层级参数
你需要在 location 或 upstream 块中设置限速，并通过以下方式约束并发连接规模：
-
worker_connections：单个 worker 进程最多能维持多少连接（含客户端+后端）。默认通常 512 或 1024。 -
upstream keepalive N：复用后端连接池大小。设为keepalive 32表示最多缓存 32 个空闲长连接，避免频繁建连放大瞬时并发。 -
proxy_requests/proxy_buffering：间接影响连接生命周期；开启 buffering 可减少连接等待时间，利于复用。 -
limit_conn（配合使用）：虽然它限的是客户端连接数，但能间接压制源头并发，防止下游疯狂建连导致 upstream 连接数失控。
示例配置（用于爬虫出口网关）：
upstream backend_api {
server 192.168.1.100:8000;
keepalive 20; # 后端连接池上限 20，复用为主
}
server {
listen 8080;
location /api/ {
proxy_pass http://backend_api;
proxy_upload_rate 80k; # 每个发往后端的连接 ≤ 80 KB/s
proxy_buffering on;
proxy_buffers 8 128k;
proxy_busy_buffers_size 256k;
# 可选：限制单个客户端最多建立 5 个并发连接，防滥用
limit_conn addr 5;
limit_conn_zone $binary_remote_addr zone=addr:10m;
}
}
此时理论最大出口带宽 ≈ 20（keepalive池）× 80 KB/s ≈ 1.6 MB/s（约 12.8 Mbps），且较平稳。
⚙️ 更精细的总带宽调控技巧
如果需要更接近目标带宽（如严格卡死在 10 Mbps），可组合以下策略：
- 用
limit_rate_after+limit_rate对客户端响应做二次限速，避免本地带宽被下游拉满 - 在
upstream中用least_conn或hash $remote_addr consistent分流，避免某后端连接堆积 - 用
proxy_next_upstream error timeout http_503提升失败容忍，减少重试带来的连接毛刺 - 监控指标：
nginx_stub_status中的Active connections和Writing状态数，结合ss -s | grep "tcp:"观察真实 ESTABLISHED 连接数，反推当前并发水平
❗ 注意避坑点
-
proxy_upload_rate是实验性指令（OpenResty 默认启用，原生 Nginx 需编译--with-stream或使用 OpenResty） - 不要误用
limit_rate替代proxy_upload_rate：前者限的是回给客户端的响应，和出向流量无关 -
worker_processes auto;+worker_connections 1024;≠ 总并发 1024：实际受限于系统ulimit -n、TIME_WAIT 回收、后端处理能力 - 高频短连接场景下，
keepalive效果弱，应优先压测并调低keepalive_timeout（如设为 5s），加快连接释放
合理配比单连接速率与连接池规模，比盲目调大 worker_connections 更有效。带宽控制不是堆资源，而是控节奏。
