要让nginx真正优先分发请求给并发连接数最少的节点，需构建感知、维持、规避闭环机制：least_conn须置于upstream块首行；启用keepalive长连接确保统计真实；结合max_conns实现容量感知调度；叠加健康检查排除假空闲节点。
要让 Nginx 真正把请求“永远优先”分发给当前并发连接数最少的节点，关键不是靠 magic 参数，而是构建一套能准确感知、稳定维持、及时规避的闭环机制。least_conn 本身逻辑简单——只比数字，但数字是否真实、是否及时、是否受干扰，决定了它能否可靠工作。
least_conn 必须放在 upstream 块第一行
这是硬性语法要求，写错位置 Nginx 直接报错或降级为轮询：
- 必须紧接在
upstream 名称 {之后，且是该块第一条有效指令 - 不能嵌套在 server 或 location 块里，只能出现在 http 块下的 upstream 定义中
- 不能和 ip_hash、hash、least_time 等策略共存，否则配置加载失败
确保连接数统计真实可信
least_conn 只统计 Nginx 与后端之间“已建立未关闭”的 TCP 连接。如果连接频繁新建又快速断开，这个数字就失去意义：
- 启用 keepalive 连接池：在 upstream 块中加
keepalive 32;（建议 ≥16，太小会导致复用率低） - 在 location 中显式启用 HTTP/1.1 长连接：
proxy_http_version 1.1;和proxy_set_header Connection ''; - 确认后端服务支持并保持长连接（如 Tomcat 的
keepAliveTimeout> 0，Node.js 默认开启） - 避免后端异常断连或空闲连接不释放（例如 MySQL 的 wait_timeout 设置过长，会让连接虚高）
用 max_conns 实现容量感知的“真优先”
单纯比最小值，可能让强节点长期处于 799 连接，弱节点卡在 800 边缘却不再接收新请求。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 自动跳过它，继续找下一个最小值节点
- 这相当于把硬件差异“编码”进调度逻辑，比 weight 更贴近实际承载力
叠加健康检查防止假空闲
least_conn 不管节点是否卡死——连接数为 0 的节点，可能是刚启动，也可能是进程僵死但 TCP 连接未断。必须主动排除：
- 配置被动检查：
proxy_next_upstream error timeout http_500 http_502;+ 对应的max_fails=2 fail_timeout=30s - 或使用主动健康检查模块（如 nginx_upstream_check_module），定期探测接口可用性
- 故障节点即使连接数为 0，也会被标记为不可用，不会参与 least_conn 选举
