least_conn算法不直接缩短HTTPS响应时间，但通过将请求分发给活跃连接数最少的后端，减少排队等待，间接降低整体延迟；需配合proxy_http_version 1.1、keepalive、健康检查及max_conns等配置，确保连接状态真实可复用。
最小连接算法（least_conn）本身不直接缩短 HTTPS 响应时间，但它能显著减少因后端负载不均导致的排队等待，尤其在长连接、响应时间波动大或计算密集型场景下，间接压低整体延迟。真正起效的关键，是让 least_conn 看到真实、及时、可复用的连接状态——而这需要 HTTPS 层面的协同配置。
确保 upstream 与 HTTPS 流量匹配
HTTPS 请求经 Nginx 解密后，实际转发的是 HTTP 流量（除非用 stream 模块做 TLS 透传）。所以 upstream 配置本身不涉及证书或加密，但必须和 proxy_pass 的协议、端口、健康检查方式对齐：
- upstream 中 server 地址应指向后端 HTTP 服务端口（如
10.0.1.20:8080），不是 HTTPS 端口；若后端也走 HTTPS，则需配proxy_ssl_*系列指令，但会增加加解密开销，一般不推荐 - 启用
proxy_http_version 1.1和proxy_set_header Connection ''，这是复用 keepalive 连接的前提，否则每次 HTTPS 请求解密后都新建 HTTP 连接，least_conn 统计的“连接数”就失去意义 - 后端服务（如 Spring Boot、Node.js）必须开启 HTTP/1.1 keep-alive，并设置合理超时（如
keepAliveTimeout: 60s），否则空闲连接被提前关闭，Nginx 的连接池无法稳定复用
让 least_conn 算法真正反映实时负载
只写 least_conn; 是远远不够的。以下四项必须同时存在，否则算法容易失效甚至加剧不均：
-
显式声明算法：upstream 块首行必须为
least_conn;，不能省略 -
每个 server 配 max_fails 和 fail_timeout：例如
server 10.0.1.20:8080 max_fails=2 fail_timeout=15s;，否则宕机节点仍持续收请求 -
启用 passive 健康检查：在 location 中加
proxy_next_upstream error timeout http_500 http_502;，配合上面的 max_fails 触发自动剔除 -
upstream 内启用 keepalive：如
keepalive 32;，控制每个 worker 进程最多缓存 32 个空闲连接；数值太小（如 4）会导致多 worker 下实际复用率极低
适配 HTTPS 业务特征的调优点
HTTPS 常伴随 TLS 握手开销、客户端重连行为、以及后端处理证书校验等额外耗时。这些会让响应时间更易波动，此时 least_conn 更有价值，但也更需针对性调整：
- 对新上线的后端实例，加
slow_start=30s，避免冷启动时因无历史连接数而瞬间涌入大量 HTTPS 请求 - 若部分后端性能明显更强（如高配 TLS 加速卡），不要用 weight（least_conn 忽略它），改用
max_conns设硬上限：强节点设max_conns=2000，普通节点设max_conns=800，least_conn 在未达上限时才参与调度 - 监控重点不是响应时间本身，而是各后端的
active connections是否均衡，以及$upstream_header_time（连接建立+首字节时间）是否突增——若该值升高，说明 TLS 握手或后端连接池已成瓶颈
验证是否生效的简单方法
不用压测工具也能快速判断：
- 开启
stub_status，访问/nginx_status，观察各 upstream server 的Active connections是否随请求动态变化、且差异不大（比如始终在 15–22 之间浮动） - 在 access_log 中加入
$upstream_addr和$upstream_connect_time，抽样看连续多个请求是否分散到不同后端，且 connect_time 没有长期高于其他节点 - 手动停掉一台后端，观察日志中是否在 15 秒内（fail_timeout）停止向其发新请求，且其余节点 active connections 缓慢上升而非陡增
