Nginx 的 limit_conn 不能直接限制单个 upstream 后端的并发请求数，需结合 max_conns、负载均衡策略及后端自身限流实现精准控制。
Nginx 的 limit_conn 指令本身不能直接限制发往单个 upstream 后端节点的并发请求数，它只控制客户端到 Nginx 的并发 TCP 连接数。要真正约束某个后端服务（如 10.0.1.10:8080）同时处理的请求数，需组合使用 upstream 层能力与间接控制策略。
用 max_conns 限制每个后端节点的最大并发连接数
这是最直接、原生支持的方式，适用于 HTTP/1.x 场景：
- 在
upstream块中为每个server显式设置max_conns - 配合
keepalive复用连接，避免新建连接冲击后端
upstream backend {
server 10.0.1.10:8080 max_conns=30;
server 10.0.1.11:8080 max_conns=30;
keepalive 32;
}
server {
location / {
proxy_pass http://backend;
proxy_http_version 1.1;
proxy_set_header Connection '';
}
}✅ max_conns=30 表示 Nginx 最多向该后端维持 30 个空闲长连接；超出的请求会排队或被拒绝（取决于 queue 指令是否启用）。
⚠️ 注意：该限制作用于连接池层面，不是严格意义上的“正在处理的请求数”，但对大多数后端已足够有效。
用 least_conn 或一致性哈希调度平衡负载
避免默认轮询导致某节点堆积大量活跃连接：
-
least_conn：优先把新请求分给当前活跃连接数最少的节点 -
hash $remote_addr consistent：固定用户到节点，便于后端自身做连接管理
upstream backend {
least_conn;
server 10.0.1.10:8080;
server 10.0.1.11:8080;
}在后端服务自身做限流（最可靠）
Nginx 是反向代理，不是流量控制器。语义最清晰、效果最稳的做法是让后端自己控制：
- Spring Boot：设
server.tomcat.max-connections=200 - Go HTTP Server：用
http.Server{MaxConns: 100} - Node.js：通过
server.maxConnections或中间件（如express-rate-limit）
这样无论 Nginx 如何调度，后端都不会超载。
补充：用 limit_conn 做源头协同控制
虽然不直控后端，但可配合使用防止整体过载放大失衡：
http {
limit_conn_zone $binary_remote_addr zone=perip:10m;
limit_conn_zone $server_name zone=perserver:10m;
upstream backend { /* ... */ }
server {
limit_conn perip 15; # 每个 IP 最多 15 个连接
limit_conn perserver 500; # 整个虚拟主机最多 500 并发（全局兜底）
}
}不复杂但容易忽略。
