least_conn算法通过调度至连接数最少节点间接降低延迟，但需keep-alive、健康检查、max_conns及延迟监控协同验证有效性。
最少连接（least_conn）算法本身不测量延迟，但它通过把新请求导向当前活跃连接数最少的后端节点，在计算密集型、长耗时任务场景下，间接避开正在处理慢请求的服务器，从而降低整体平均响应延迟。
让连接数真实反映实时负载压力
连接数只有在能代表真实工作负荷时，least_conn 才有效。否则会误判“空闲节点”实为卡死或过载节点：
- 后端必须启用 HTTP/1.1 keep-alive，并设置合理 keepalive_timeout（推荐 15–30 秒），避免短连接频繁新建/关闭导致连接数统计失真
- Nginx upstream 中需配置 keepalive 32（每 worker 缓存最多 32 个空闲长连接），确保复用稳定
- 图片处理、AI 推理等短时高负载场景，建议将 keepalive_timeout 缩短至 5 秒，防止慢请求长期占位
必须叠加健康检查排除假活节点
least_conn 只看连接数，不感知节点是否内存泄漏、磁盘 I/O 阻塞或进程僵死。若不剔除异常节点，低连接数反而成为“陷阱”：
- 每个 server 行必须带 max_fails=2 fail_timeout=15s，触发被动摘除
- 配合 proxy_next_upstream error timeout http_500 http_502，使失败可被识别并计入 max_fails
- 生产环境推荐主动探测：使用 nginx_upstream_check_module 或 OpenResty 的 check 指令
用 max_conns 替代 weight 实现容量感知调度
least_conn 忽略 weight 参数，无法靠权重表达机器性能差异。更可靠的方式是用 max_conns 设置硬性连接上限：
- 高性能节点（如 GPU 服务器）设 server 10.0.1.10:8080 max_conns=2000
- 普通节点设 server 10.0.1.11:8080 max_conns=800
- 当某节点活跃连接达上限，least_conn 自动跳过——相当于按实际吞吐能力动态分流
验证是否真正降低延迟
不能只看日志请求数分布，要交叉分析连接状态与响应时间：
- 开启 stub_status，访问 /nginx_status 观察各 backend 的 active 连接数是否趋于均衡（如压测中维持在 15–19，而非一台长期高于 40）
- 采集 $upstream_connect_time 和 $upstream_header_time，识别“连接快但业务慢”的异常节点
- 绘制 active connections vs response time 散点图，定位离群点（例如连接数为 3 但 P95 延迟超 2s，大概率是本地缓存失效或磁盘打满）
