least_conn策略只统计Nginx与后端间已建立未关闭的活跃TCP连接数，不感知HTTPS握手负载；需配合keepalive、健康检查及max_conns配置，才能真实反映并均衡建连压力。
least_conn 策略本身不感知 HTTPS 握手负载，它只统计 Nginx 与后端之间已建立、尚未关闭的活跃 TCP 连接数。所谓“握手负载最轻”，实际是指当前正在处理 TLS 握手或刚完成握手、尚未进入业务请求阶段的连接较少的节点——而 least_conn 正是通过优先选择 active 连接数最少的后端，间接避开那些正被大量 HTTPS 建连请求堆积的节点。
必须把 least_conn 放在 upstream 块第一行
它不能嵌套在 server 或 location 中，也不能和 ip_hash、hash、least_time 等策略共存：
- 正确写法：
upstream backend { least_conn; server 10.0.1.10:443; server 10.0.1.11:443; } - weight 参数会被静默忽略，不要依赖它做调度；max_conns 才是体现容量差异的有效方式
- 若某 server 行后写了
backup或down，least_conn 会自动跳过它们，不参与连接数比较
让连接数真实反映 HTTPS 建连压力
短连接下，每次 HTTPS 请求都新建 TCP+TLS 连接再断开，所有后端 active 数几乎恒为 0，least_conn 就失效了。关键是要复用连接：
- 在 upstream 块中加
keepalive 32;（建议 ≥16，太小会导致连接池不够用） - 在 proxy_pass 的 location 中启用 HTTP/1.1 并清空 Connection 头：
proxy_http_version 1.1;和proxy_set_header Connection ''; - 后端必须支持 keep-alive：例如 Nginx 自身作后端时需配
keepalive_timeout 60s;；Tomcat 需开启keepAliveTimeout；OpenResty 默认支持
防止“连接数低但握手卡死”的假象
一个后端进程可能 TLS 握手线程阻塞、证书校验慢、OCSP 响应超时，但 TCP 已建连、连接未关闭，least_conn 仍会把它当“空闲”节点分发新请求：
- 配置被动健康检查：
max_fails=3 fail_timeout=30s，配合proxy_next_upstream error timeout http_503; - 更可靠的是主动探测：用 OpenResty 的
check interval=3 rise=2 fall=3 type=https（需编译含 stream_ssl_module） - 对高并发 HTTPS 场景，可设
server 10.0.1.10:443 max_conns=1500;，避免弱节点因握手队列积压拖垮整体
验证是否真按握手压力分流
不能只看日志请求数，要观察连接层行为：
- 开启
stub_status模块，访问/nginx_status查各后端的Active connections实时值 - 压测时用
curl -kvs https://api.example.com/ --connect-timeout 5模拟建连压力，比对各后端 access log 中$time_connect分布 - 若发现某节点 active 数低但
$upstream_connect_time明显偏高，说明它 TLS 握手慢，需排查证书链、OCSP Stapling 或 SSL 缓存配置
