least_conn是nginx内置的动态负载均衡策略，自1.3.1版本起支持，需在upstream块首行配置，基于实时活跃tcp连接数调度，优先分发请求至连接数最少的健康后端，适用于长连接、响应时间差异大或后端性能不均场景。
Linux 本身不直接提供 least_conn 负载均衡策略，这个策略是 Nginx（运行在 Linux 系统上）的 upstream 模块功能。你要实现“把请求分发给当前连接数最少的后端”，本质是在 Nginx 配置中启用并正确使用 least_conn 指令。
least_conn 必须写在 upstream 块第一行
语法位置错误会导致配置失效或降级为轮询：
- 必须紧接在
upstream 名称 {后面，且是该块第一条有效指令 - 不能放在 server 行之后，也不能嵌套在 location 或 server 块里
- 不能和 ip_hash、hash、least_time 等其他负载策略共存，否则 reload 会失败
连接数统计要真实可信
least_conn 只统计 Nginx 与后端之间“已建立、尚未关闭”的 TCP 连接。如果连接频繁新建又断开，数字就失真：
- 在 upstream 块中启用长连接池：
keepalive 32;（建议 ≥16） - 在 proxy 所在 location 中开启 HTTP/1.1 长连接：
proxy_http_version 1.1;和proxy_set_header Connection ''; - 确认后端支持 keepalive（如 Tomcat 的
keepAliveTimeout> 0，Node.js 默认开启） - 避免后端因超时设置不合理（如 MySQL 的
wait_timeout过长）导致空闲连接滞留
用 max_conns 实现容量感知调度
单纯比最小值，可能让高性能节点长期满载而弱节点被卡在临界值外。max_conns 让 least_conn 主动跳过已达上限的节点：
- 给高配节点设更高上限：
server 192.168.1.10:8080 max_conns=2000; - 给普通节点设合理上限：
server 192.168.1.11:8080 max_conns=800; - 一旦某节点活跃连接数 ≥ max_conns，Nginx 自动跳过它，继续找下一个最小值节点
必须搭配健康检查防止“假空闲”
least_conn 不剔除故障节点。若后端宕机但 TCP 连接未超时断开，它的连接数可能仍显示为 0：
- 启用主动健康检查（七层）：
health_check interval=3 fails=2 passes=2; - 或用被动探测：
server 192.168.1.12:8080 max_fails=3 fail_timeout=30s; - 确保连接数反映的是“可服务的空闲”，而不是“未响应的假空闲”
