least_conn算法真正起效依赖连接数真实反映后端负载，需通过主动健康检查、合理keepalive配置、max_conns容量控制及实时监控协同实现，而非仅靠选择连接最少节点。
最少连接算法（least_conn）在高并发场景下真正起效，不靠“选连接少的机器”这个动作本身，而靠它能否真实反映后端实际负载。连接池利用率高低，取决于 Nginx 是否能持续把请求导向真正空闲的后端，而不是账面上“连接数低”但实际卡死的节点。
健康检查必须主动且灵敏
默认 passive 检查（靠失败重试触发）无法识别“连接挂着但不响应”的情况，比如后端线程阻塞、GC 暂停或数据库锁表。这类节点连接数可能不高，但新请求一打过去就超时，反而拖慢整体。
- 启用 active health check（商业版或带 patch 的开源版），配置
health_check interval=3 fails=2 passes=2，并用match校验 HTTP 状态码和关键响应头（如X-App-Status: ok） - 若只能用 passive 模式，至少配
proxy_next_upstream error timeout http_500 http_502，配合max_fails=2 fail_timeout=15s，让异常节点快速隔离 - 避免健康检查路径与业务路径共用——检查接口应轻量、绕过缓存和鉴权，否则检查本身会加重后端压力
keepalive 连接池要大小合理、复用到位
upstream 的 keepalive 不是越大越好。设得过大，空闲连接长期占着连接数，会让 least_conn 误判；设得太小，又频繁建连，抵消算法收益。
- 按后端单实例平均并发连接数反推：若后端稳定承载 20–30 并发，worker_processes 为 4，建议
keepalive 32（单 worker 最多复用 8 条） - 配套设置
keepalive_timeout 60s和keepalive_requests 1000，避免连接长期空闲或单连接处理过多请求导致状态污染 - 务必开启
proxy_http_version 1.1和proxy_set_header Connection ""，显式关闭客户端 Connection 头，防止后端误关连接 - 检查后端响应头是否含
Connection: close——常见于错误返回、调试开关打开或 WAF 干预，这种响应会强制释放连接，导致池失效
用 max_conns 代替 weight 实现容量感知
least_conn 原生不支持 weight，但 max_conns 可以软性约束节点接入上限，让算法在“连接数最少”前提下，自然倾向能力更强的机器。
- 高性能节点（如 32C64G）可设
max_conns=3000，普通节点（16C32G）设max_conns=1200 - 注意：max_conns 是硬限制，一旦达到，Nginx 就跳过该节点参与 least_conn 比较，不会排队等待
- 上线新节点时加
slow_start=30s，避免冷启动瞬间涌入大量连接，冲击后端连接池
监控要盯住“活跃连接趋势”，而非瞬时数值
单看某次 $upstream_addr 日志里的连接数没意义。关键是观察各后端 active connections 随时间的变化是否平滑、有无持续爬升或突刺。
- 通过 stub_status 或 Prometheus exporter 抓取
Active connections，画出每台后端的曲线图，理想状态是波动范围窄、无单点持续高位 - 对比
$upstream_connect_time和$upstream_response_time：前者稳定但后者飙升，说明问题在后端逻辑；两者同步升高，可能是 upstream 连接池不足或 Nginx 自身瓶颈（如 worker_connections 不够） - 开启自定义日志格式，记录
$upstream_bytes_received和$upstream_cache_status，排除因缓存失效导致的重复计算压垮连接池
