least_conn与limit_conn分工明确：前者在upstream内按后端活跃连接数调度请求，后者在server或location级限制客户端并发连接总数；二者需配合keepalive才能协同实现“外层控总量、内层调分配”的双重并发控制。
Least Connections（least_conn）算法本身不控制并发总量，它只在多个后端节点间做“相对轻载优先”的分发决策；而 limit_conn 是 Nginx 的全局或入口级并发连接数硬限流机制。二者定位不同、作用层级不同，但可以协同配合，形成“外层控总量 + 内层调分配”的双重并发控制策略。
least_conn 与 limit_conn 的分工逻辑
least_conn 负责在 upstream 集群内“怎么分”——把新请求导向当前活跃连接最少的后端，前提是这些连接可复用、状态真实；
limit_conn 负责在 server 或 location 级别“能接多少”——直接限制 Nginx 接收的客户端并发 TCP 连接数，防止打爆自身或下游。
- limit_conn 控制的是 Nginx worker 进程接受的客户端连接总数（基于 $binary_remote_addr 或自定义 key）
- least_conn 统计的是 Nginx 与后端之间已建立、尚未关闭的长连接数（依赖 keepalive 复用）
- 二者不冲突：limit_conn 在 accept 阶段拦截，least_conn 在 proxy_pass 前调度，属于前后衔接的两道防线
典型双控配置结构
常见做法是：用 limit_conn 控制入口总连接压力，再用 least_conn + keepalive 把这股压力尽量均衡地落到后端节点上。
- 在 http 块中定义连接限制区域：
limit_conn_zone $binary_remote_addr zone=perip:10m; - 在 server 或 location 中启用限流：
limit_conn perip 200;（单 IP 最多 200 并发连接） - upstream 中启用 least_conn 并配 keepalive：
upstream backend {<br> least_conn;<br> keepalive 32;<br> server 192.168.1.10:8080 max_fails=2 fail_timeout=15s;<br> server 192.168.1.11:8080 max_fails=2 fail_timeout=15s;<br>} - 对应 location 启用 HTTP/1.1 和 Connection 头透传：
proxy_http_version 1.1;<br>proxy_set_header Connection '';
为什么必须搭配 keepalive 才能让 least_conn 发挥价值
若没开 keepalive，每次请求都新建短连接，Nginx 与后端之间的“活跃连接数”几乎等于瞬时请求数，各节点差异极小，least_conn 实际退化为轮询；而 limit_conn 限制的是客户端到 Nginx 的连接，两者之间就脱节了。
- keepalive 让连接可复用，least_conn 统计的才是后端“手头正在处理的连接”真实负载
- 只有这时，limit_conn 控制的总并发量，才能被 least_conn 有效摊平到各个后端，避免某节点堆积大量慢连接
- 建议 keepalive 数值不低于 16，worker 进程多时可设 32 或更高，确保复用率
进阶：用 max_conns 做节点级软上限
limit_conn 是全局入口限流，least_conn 是集群内调度，而 max_conns 可作为第三层控制——给每个后端节点设置最大允许的活跃连接数。
- 例如：
server 192.168.1.10:8080 max_conns=150;表示该节点最多承接 150 个活跃连接 - least_conn 会在不超过各自 max_conns 的前提下，选择当前连接数最少者
- 这样既保留调度灵活性，又防止单节点过载，和 limit_conn 形成“总—组—单”的三级控制链
