least_conn算法通过实时比较后端活跃连接数（含keepalive空闲连接）并归一化为conns/weight值，选取最小值节点转发请求；多节点相同时退至加权轮询，需配合健康检查、max_conns及合理keepalive配置才能生效。
最少连接算法（least_conn）在 Nginx 中不是靠预估或平均分配，而是实时依据后端服务器当前活跃连接数做决策，从而更真实地反映各节点实际负载，实现集群处理能力的动态平衡。
核心逻辑：按“实时连接数”选目标
每次新请求到达时，Nginx 会遍历 upstream 中所有可用 server，读取其当前活跃连接数（conns），并计算 conns / weight 值。该值最小的服务器被选中；若多个 server 的值相同，则退回到加权轮询顺序选取。
- 权重（weight）直接影响比较基准——高权重服务器允许承载更多连接，但不会“跳过”低连接数的低权重节点
- 连接数统计包含所有已建立、尚未关闭的长连接（如 keepalive 连接），不只是瞬时并发请求数
- down、backup 或 max_fails 触发的失效节点会被自动排除，不参与 least_conn 计算
配置要点：必须放在 upstream 块内
least_conn 是一个指令，只能出现在 upstream 上下文中，不能用于 location 或 server 块中。它不接受参数，启用即生效：
- 基础写法：
least_conn;—— 紧跟 upstream 名称后，位置无关（但建议放在 server 列表前） - 支持与 weight、max_fails、fail_timeout 等属性共存，且权重会参与连接数归一化计算
- 不可与其他负载均衡指令（如 ip_hash、hash $arg_id）混用，否则配置校验失败
适用场景：长连接或响应时间差异大的服务
当后端服务存在明显耗时差异（如文件上传、报表生成、WebSocket 长连）时，轮询容易导致部分节点堆积大量慢请求，而 least_conn 能主动避开“忙”的节点：
- API 网关对接异构微服务（Java/Go/Python 混合部署，处理延迟不一致）
- Websocket 或 SSE 接入层，单连接生命周期长达数分钟甚至小时
- 数据库代理或缓存中间件（如 Redis Cluster Proxy），连接复用率高
局限与调优提示
least_conn 不感知 CPU、内存或响应延迟等资源指标，仅依赖连接计数。若需更高精度，可结合其他机制：
- 搭配健康检查（
health_check或第三方模块）及时剔除假活节点 - 为性能更强的机器设置更高 weight，弥补纯连接数无法体现算力差异的问题
- 避免在短平快、秒级响应的静态服务上强行使用——此时轮询更稳定、开销更低
