least_conn真正起效必须配合keepalive连接复用，否则活跃连接数仅反映瞬时请求数，算法退化为近似轮询；需在upstream中配置keepalive、location中启用HTTP/1.1并透传Connection头，且后端须支持长连接，同时必须搭配健康检查避免导流至故障节点。
最少连接算法（least_conn）在 Nginx 中真正起效，不靠“选连接数少的”这一句逻辑，而靠它和连接池复用（keepalive）的紧密配合。没有复用，连接数就只是瞬时请求数，算法退化为近似轮询；有了复用，连接数才真实反映后端“手头正在干的活”，调度才具备负载感知能力。
为什么必须配 keepalive 才算完整启用 least_conn
least_conn 统计的是 Nginx 与后端之间“已建立、尚未关闭”的活跃 TCP 连接数。如果每次请求都新建连接、用完即关（短连接），那这个数字就始终≈当前并发请求数，节点间差异极小，算法失去区分度。
- upstream 中加 keepalive 32：每个 worker 进程最多缓存 32 个空闲长连接，避免反复建连开销
- location 中设 proxy_http_version 1.1 和 proxy_set_header Connection ''：告诉后端不要关闭连接，支持复用
- 后端服务也要开启 keep-alive：如 Tomcat 配
keepAliveTimeout > 0，Node.js 默认支持，Spring Boot 可调server.tomcat.connection-timeout
连接池大小怎么定才合理
keepalive 值不是越大越好，它代表每个 worker 缓存的空闲连接上限，需匹配后端单实例的平均并发压力。
- 估算公式：后端单实例平均活跃连接数 × 1.2～1.5
- 常见起步值：32 或 64（中小流量）、128（高并发 API 网关）
- 过小 → 频繁建连，连接数抖动大，least_conn 判定失真
- 过大 → 内存占用上升，且空闲连接堆积可能掩盖真实负载变化
least_conn 调度行为依赖连接池状态
算法本身只看“当前活跃连接数”，但这个数由连接池实际使用情况决定：
- 新请求到来时，Nginx 优先从本 worker 的 keepalive 池中复用空闲连接；若无可用，则新建连接并计入该后端的活跃数
- 请求结束时，连接若未超时且后端允许复用，就回收进池子，不再计入活跃数
- 因此，连接池是否被有效填充、复用率是否足够高，直接决定 least_conn 是否能持续识别出“真正轻载”的节点
别忘了健康检查这个前提
least_conn 不剔除故障节点。一台后端宕机但连接尚未超时断开，它的活跃连接数可能仍为 0，Nginx 就会持续转发请求过去，造成失败堆积。
- 必须搭配被动检查：proxy_next_upstream error timeout http_500 + max_fails=2 fail_timeout=15s 在 server 行中
- 或主动健康检查（需商业版或开源 patch）：health_check interval=5 fails=2 passes=2
- 否则，连接池再好，least_conn 再准，也会把流量导给不可用节点
