least_conn调度通过实时将新请求分配给活跃连接最少的健康节点，有效缓解高频访问下因请求时长差异导致的负载不均；需配合主动健康检查、合理权重设置及失败重试，并依赖keepalive连接复用与准确连接状态反馈。
最少连接调度（least_conn）能有效缓解后端在高频访问下的负载不均问题，尤其适合请求处理时长差异大、资源消耗波动强的场景。它不靠轮询“平均分发”，而是实时把新请求导向当前活跃连接最少的健康节点，让空闲资源优先被利用。
为什么 least_conn 更适合高频访问
高频访问常伴随大量短请求混杂少量长耗时任务（如实时计算、小模型推理）。轮询容易把新请求持续打到正忙于长任务的节点上，造成响应堆积和延迟跳变；least_conn 则天然绕开高连接数节点，显著降低尾部延迟。
- 两个后端节点 A 和 B，A 正处理 5 个需 6 秒完成的请求，B 当前连接数为 0 —— 轮询可能继续分给 A，least_conn 会立即选 B
- 对 API 网关、微服务注册中心等小包高频接口，least_conn 配合连接复用，可提升吞吐稳定性
必须配齐的三项基础配置
单独启用 least_conn 不足以发挥效果，需与健康检查、权重调节、失败重试协同工作：
- 主动健康检查不可省略：仅靠 proxy_next_upstream 的被动重试无法及时发现“假活”节点（如卡住但未断连）。建议配置 interval=3s、fails=2、passes=2，并用 match 块校验 HTTP 状态码与关键响应头
- weight 要反映真实承载力：若某台机器 CPU 是其他节点的 1.5 倍，设 weight=3（其余为 2），Nginx 在连接数相近时会按比例倾斜分发，避免小规格机器率先打满
- proxy_next_upstream 至少包含 error timeout http_500 http_502：确保后端因过载返回 502 或超时时，请求能立刻切走，不滞留在故障节点
连接池与 keepalive 是高频场景的前提
least_conn 的效果依赖于连接状态的真实反馈。若后端维持大量空闲长连接，active connections 值虚高，调度就会失真。
- upstream 中配置 keepalive 32（建议值 16–64），每个 worker 复用固定数量空闲连接
- 搭配 proxy_http_version 1.1 和 proxy_set_header Connection ''，显式关闭 Connection 头，防止连接被误关或堆积
- 可设 keepalived_requests 1000，限制单连接最大请求数，避免老化连接影响统计准确性
验证是否真正生效的关键指标
不能只看 upstream_addr 日志或简单连接数，要结合多维度观测：
- 通过 stub_status 或 Prometheus exporter 查看各后端 active connections 是否持续接近上限 —— 若普遍偏高且不均衡，说明 least_conn 已触达瓶颈，需扩容或优化后端逻辑
- 对比 $upstream_header_time（到响应头到达时间）与 $upstream_response_time（完整响应时间）：前者稳、后者升，问题在业务层；两者同步升，可能是 Nginx worker_connections 不足或网络延迟
- 开启 log_format 记录 $upstream_bytes_received 和 $upstream_cache_status，排除缓存失效导致的重复计算压力
