不能直接用 limit_req_zone 实现带宽预留，但可通过识别核心请求、独立限流策略及 upstream 分流间接保障核心业务资源：用 X-Business-Category 头区分流量，map 构造隔离键，分别配置 core_limit 和 normal_limit 区域，在 location 中差异化应用，并配合 limit_conn、upstream 权重与可观测性验证。
不能直接用 limit_req_zone 实现“带宽预留”，它只管请求数（QPS），不控制字节流量或带宽。但你可以通过“识别核心业务请求 + 独立限流策略 + 配合 upstream 分流”来间接达成类似效果：让核心业务请求优先获得服务资源，非核心请求主动让出连接、延迟或被拒绝。
识别核心业务请求：用自定义 Header 做标记
前端或网关在调用核心接口时，统一加上业务标识头，比如：
X-Business-Category: coreX-Service-Priority: high
在 Nginx 中提取该头，构造限流键值：
map $http_x_business_category $req_key {
default $binary_remote_addr;
"core" "$binary_remote_addr-core";
}这样，核心用户和普通用户的限流状态就完全隔离，互不影响。
为不同业务设置独立限流区域
分别定义两个 limit_req_zone，一个宽松保核心，一个严格控非核心：
limit_req_zone $req_key zone=core_limit:10m rate=50r/s; limit_req_zone $binary_remote_addr zone=normal_limit:10m rate=5r/s;
关键点：
-
core_limit共享内存中存的是"IP-core"键，只对带X-Business-Category: core的请求生效 -
normal_limit对所有未标记或标记为 non-core 的请求统一限速 - 内存大小（如
10m）按预估并发 IP 数配置，64 位系统下约支持 8 万个独立键
在 location 中差异化应用限流策略
以 API 路径为例，对核心路径启用高配限流，并确保不挤占后端连接：
location /api/v1/order/ {
# 核心下单路径，仅允许 core 标记请求
if ($http_x_business_category != "core") {
return 403 "Only core business allowed";
}
limit_req zone=core_limit burst=100 nodelay;
proxy_pass http://core_backend;
}
<p>location /api/ {</p><h1>其他路径走普通限流</h1><pre class='brush:php;toolbar:false;'>limit_req zone=normal_limit burst=10 nodelay;
proxy_pass http://general_backend;}
补充建议：
- 配合
limit_conn控制每个 IP 的最大并发连接数（如limit_conn conn_per_ip 20），防止单个客户端建太多长连接耗尽 upstream 连接池 - 后端 upstream 可配置不同组：core_backend 使用更高权重、更少超时、keepalive 更多的服务器；general_backend 则可设 backup 或降级节点
- 用
limit_req_status 429统一返回标准限流响应，便于前端识别重试逻辑
验证与可观测性要点
上线前务必检查三项：
- Header 是否真实透传（确认 client → Nginx 链路没被中间代理清洗掉
X-Business-Category） - 日志中添加变量：
$req_key和$limit，观察限流命中情况 - 用 ab 或 wrk 模拟两类请求，对比响应时间、429 比例、后端连接数分布
这种方案不依赖带宽计量，却能从请求调度层面保障核心链路容量水位，是生产环境常用且稳定的做法。
