Nginx least_conn算法基于实时、精确的每worker进程内活跃连接数动态调度，跳过故障节点，不依赖权重或历史数据，适用于连接生命周期差异大的场景。
是的，Nginx 最少连接（least_conn）算法确实依靠实时统计后端服务器的活跃连接数来实现动态调度，不依赖历史数据或预设权重，每次请求到来时都做一次即时判断。
它统计的是“当前活跃连接数”
这个数值包括所有尚未关闭的 TCP 连接，尤其是 keepalive 长连接、WebSocket 连接、数据库代理连接等。Nginx 会在每个 worker 进程中维护每台 upstream server 的连接计数器，当请求建立或断开时同步增减。
- 不是平均值，也不是采样估算，而是精确到连接粒度的实时计数
- 健康检查失败的 server 不参与比较，自动被跳过
- 多个 worker 进程之间不共享连接数，但因单次请求只由一个 worker 处理，该决策在本 worker 内有效且合理
调度发生在请求进入的瞬间
不同于轮询靠内部指针推进，least_conn 在每次请求抵达 upstream 模块时，遍历所有可用 server，读取各自当前连接数，选出最小值对应的目标节点——整个过程无状态、无缓存、无延迟。
- 无需配置额外参数，只需在 upstream 块中声明 least_conn;
- 不依赖外部监控系统或指标上报，完全由 Nginx 自身在内存中维护
- 适用于连接生命周期差异大、响应时间不均的场景，比如后台任务网关或实时通信服务
和加权最少连接的区别
开源版 Nginx 只支持基础 least_conn；加权最少连接（WLC）属于 Nginx Plus 或部分第三方模块的功能。它在连接数相同时，优先选择权重更高的 server，兼顾硬件能力与实时负载。
- 如果你有性能明显分层的后端（如 16 核 + 8 核混部），纯 least_conn 可能导致高配机器连接数长期偏低
- 此时需评估是否引入商业版或兼容模块，而非仅靠调高 weight 参数（weight 在 least_conn 模式下不生效）
实际效果受连接管理方式影响
least_conn 的优势能否发挥，取决于后端是否真正释放连接。若应用端未及时 close，或大量 keepalive 超时设置过长，会导致连接数虚高、调度失准。
- 建议配合后端连接超时策略（如 proxy_read_timeout、keepalive_timeout）协同优化
- 可通过 stub_status 或第三方 exporter 观察各 server 的 active conn 数，验证调度是否符合预期
