least_conn算法通过将新请求分发给活跃连接数最少的后端，间接提升响应速度与资源利用率，需配合健康检查、keepalive复用、合理超时及weight适配才能生效。
最少连接算法本身不直接“优化连接处理效率”，而是通过更合理地分发请求，间接提升整体响应速度和资源利用率。真正起效的关键，在于让 Nginx 能准确感知后端真实负载，并把请求导向真正空闲的节点——这需要健康检查、连接复用、超时协同和权重适配四方面配合。
确保活跃连接数统计真实可靠
最小连接数依赖“当前活跃连接数”做决策，但若连接频繁新建又快速关闭（如短连接未复用），计数就失去意义。必须让连接真正复用起来：
- 在 upstream 块中配置 keepalive 32;（建议值 16–100，视后端并发能力而定）
- 后端服务开启连接池：例如 Tomcat 设置 maxKeepAliveRequests > 0，Node.js 使用 http.Agent keepAlive: true
- Nginx 主配置中启用 keepalive_timeout 65; 和 keepalive_requests 100;，避免客户端过早断连干扰上游统计
强制剔除异常节点，避免调度失真
宕机、卡顿或响应缓慢的节点若仍参与 least_conn 计算，新请求会持续打过去，连接数虚低但实际失败率高：
- 每个 server 必须显式配置 max_fails=2 fail_timeout=15s，让 Nginx 主动标记并隔离故障节点
- 搭配 proxy_next_upstream error timeout http_500 http_502，确保超时或错误码触发重试与踢出逻辑
- 有条件时启用主动健康检查（如商业版 health_check 或开源 patch），比被动检查更早发现“假存活”节点
按硬件能力差异化分发，防止小规格机器过载
单纯比连接数，容易让 CPU/内存较弱的节点因响应慢而堆积连接。需引入权重调节承载倾向：
- 若某台后端 CPU 是其他节点的 2 倍，设 weight=2；若仅为一半，设 weight=1
- 权重不影响“选连接最少”的前提，只在多个节点连接数相同时起作用——此时高权重要求更高连接容量，才更公平
- 避免对所有 server 使用相同 weight=1，尤其当后端存在异构机型时
监控验证是否真正生效
不能只看配置写了 least_conn，要确认它在真实流量下是否按预期工作：
- 通过 stub_status 或 Prometheus exporter 观察各后端的 active connections 是否长期均衡（如波动范围控制在 ±3 内）
- 对比 $upstream_header_time 和 $upstream_response_time：前者稳定而后者飙升，说明问题在后端业务层；两者同步升高，可能是 Nginx worker_connections 不足或网络瓶颈
- 记录 $upstream_addr 和 $upstream_cache_status，排除缓存失效导致重复压测后端引发的连接堆积
