least_conn算法需配合主动健康检查、真实keepalive复用、max_conns容量限制及多维监控才能有效降低排队延迟：主动探测≤3s间隔、后端开启连接池、max_conns设为软限、交叉验证连接数与响应时间等指标。
最少连接（least_conn）算法本身不直接减少排队延迟，但它能显著降低因后端负载不均导致的隐性排队——尤其当部分节点正处理长耗时请求、连接堆积却未被隔离时。真正起效的前提，是让 Nginx 看清“谁真闲、谁假空”。否则，连接数低的节点可能正卡在 GC、磁盘 I/O 或锁竞争中，调度过去反而加剧延迟。
健康检查必须主动且灵敏
默认 passive 检查（靠失败响应触发）太慢：一个超时或 502 要等 proxy_next_upstream 触发重试，期间新请求仍持续打向故障节点。必须叠加主动探测：
- 使用 nginx_upstream_check_module 配置 HTTP 探针，间隔 ≤3s，连续 2 次失败即标记为 down
- 或用 OpenResty 的 check 指令，配合 match 校验响应头或 body 内容，避免“HTTP 200 但业务已卡死”
- fail_timeout 设为 10–15s，确保异常节点快速摘除又不过度震荡
keepalive 连接要真实复用，不能只配数字
upstream 中的 keepalive 32 只是每 worker 缓存上限；若后端不维持长连接，或客户端频繁断连，Nginx 统计的“活跃连接数”就失真——刚建就关的短连接会让 least_conn 变成伪随机分发。
- 后端需开启连接池：Tomcat 设置 maxKeepAliveRequests > 0、keepAliveTimeout > 5s
- Nginx location 块中启用 HTTP/1.1 长连接：proxy_http_version 1.1 + proxy_set_header Connection ''
- 避免 upstream keepalive 值过大（如 200），否则空闲连接人为拉高某台机器的“账面连接数”，干扰判断
用 max_conns 实现容量感知调度
least_conn 不支持 weight，但 max_conns 是更贴合真实负载的软限控制。它让算法在“连接最少”之外，还尊重物理能力边界：
- 高性能节点设 max_conns=2000，普通节点设 max_conns=800
- 当某节点活跃连接数 ≥ max_conns 时，Nginx 自动跳过它，即使它是当前最小值
- 这比单纯依赖连接数更可靠——尤其在 CPU 已饱和但连接尚未超限时，max_conns 能提前规避
监控必须交叉验证，不能只盯连接数
连接数低 ≠ 延迟低。需同步观测三类指标才能定位真瓶颈：
- 通过 stub_status 或 Prometheus exporter 查看各 server 的 active connections 是否均衡，且未长期逼近 max_conns
- 记录 $upstream_connect_time 和 $upstream_header_time：前者突增说明网络或 Nginx 侧瓶颈，后者稳定但 $upstream_response_time 飙升，说明问题在后端业务逻辑
- 绘制 active connections vs response time 散点图，识别“连接数 5 但 P95 延迟 2s”的离群点——大概率是内存泄漏、本地缓存失效或慢 SQL
