least connections算法不降低接口耗时，而是将新请求导向活跃连接最少的后端；需确保连接数准确（启用keepalive、http/1.1复用）、叠加健康检查与max_conns限流、按业务特征分离路径并验证实时指标。
Least Connections 算法本身不降低接口耗时，它的作用是让新请求尽量落到当前活跃连接最少的后端上。在微服务多实例部署中，它特别适合处理长耗时接口（如报表导出、AI推理、大文件解析），但若配置不当，反而会放大不均衡——关键不是启用算法，而是让“连接数”真实反映后端压力。
确保连接数统计准确
连接数不准，least_conn 就失去意义。重点做两件事：
- 开启并合理设置 keepalive：upstream 中加 keepalive 32;，避免空闲连接堆积虚高计数；后端服务也要支持长连接（例如 Spring Boot 配置
server.tomcat.connection-timeout=-1，Tomcat 设置maxKeepAliveRequests > 0） - 显式声明 HTTP/1.1 复用：在 proxy location 块中加上 proxy_http_version 1.1; 和 proxy_set_header Connection '';，防止 Nginx 自动关闭复用通道
防止慢节点持续吸流
least_conn 不判断节点是否健康或响应是否变慢，必须叠加保护机制：
- 配主动健康检查（推荐）：使用
check interval=3 rise=2 fall=3 timeout=1 type=http，路径设为轻量 /health，不走业务逻辑 - 至少配被动检查：proxy_next_upstream error timeout http_500 http_502;，配合每个 server 的 max_fails=2 fail_timeout=15s，让异常节点及时隔离
- 设硬性容量上限：每个 server 显式加 max_conns=150;，一旦达到即跳过，哪怕它当前连接数仍是“最少”
适配微服务实际运行特征
微服务常存在异构、冷启动、长/短任务混杂等问题，需针对性调整：
- 分离流量路径：将长耗时接口（如 /report/export）单独路由到专用 upstream，启用 least_conn + max_conns=50；普通 API 走另一组，避免慢请求污染快路径
- 新实例加 slow_start：扩容时给新 server 加 slow_start=30s;，权重从 0 线性升至满额，防冷启动雪崩
- 硬件差异靠 max_conns 区分：高性能节点设 max_conns=2000，普通节点设 800，比 weight 更贴近 CPU/内存瓶颈
上线后验证是否真均衡
不能只看 access log 的 $upstream_addr，要盯实时指标：
- 监控各后端的 活跃连接数分布（Nginx stub_status 或 OpenResty prometheus 模块）
- 对比 P95 延迟变化：轮询下某节点连接数飙升但 CPU 平稳，least_conn 下连接数收敛且延迟稳定，才是生效信号
- 观察健康检查状态：是否有节点反复进出 up/down 状态，说明 fail_timeout 或检查间隔需调整
