least_conn能降低响应延迟，关键在于将请求导向真正空闲节点，避开正处理长耗时任务的后端；需配置least_conn指令、max_fails/fail_timeout、proxy_next_upstream健康检查及keepalive连接复用，缺一不可。
最少连接策略（Least Conn）能降低响应延迟，关键不在“选连接少的后端”，而在于它把请求导向真正空闲的节点——尤其当后端处理耗时差异大、存在长任务时，效果明显。
为什么能压低延迟？
轮询不看后端实际负载，容易把新请求打到正卡在复杂计算里的节点上；最小连接数实时比较活跃连接数，天然避开堆积中的服务器。
- 比如两个节点，A正在处理3个8秒AI推理请求（连接数=3），B刚释放连接（连接数=0），轮询可能继续派单给A，而least_conn立刻导向B
- 实测在200 QPS、含10%长连接场景下，P95延迟从490ms降至320ms左右
- 对CPU/内存消耗波动大的服务（如模型服务、报表生成）特别有效
必须配齐的4项基础配置
只写least_conn没用，缺一不可：
-
显式声明算法：upstream块里加
least_conn; -
每个server配max_fails和fail_timeout：例如
server 10.0.1.10:8080 max_fails=2 fail_timeout=15s;，让Nginx主动踢掉异常节点 -
启用健康检查逻辑：至少通过
proxy_next_upstream error timeout http_500 http_502配合max_fails生效；更推荐加主动健康检查（如commercial版或patch） -
开启并复用keepalive连接：upstream内加
keepalive 32;，后端也要配连接池（如Tomcat设maxKeepAliveRequests > 0），否则短连接频繁建断会让连接数失真
权重与冷启动保护
硬件能力不同或新实例上线时，需进一步调优：
- 用
weight体现机器规格差异：CPU是其他节点2倍，就设weight=2，让Nginx在连接数相近时多分请求过去 - 新server加
slow_start=30s：连接权重从0线性升至满值，避免冷启动瞬间被打满 - 别忽略
proxy_next_upstream策略：至少包含error timeout http_500 http_502，确保超时或5xx时自动切走，不卡死
怎么验证是否真起效？
不能只看日志里的$upstream_addr，要结合指标交叉判断：
- 查各后端
active connections（通过stub_status或Prometheus exporter）：是否持续接近上限？若是，说明已到瓶颈，得扩容或优化后端逻辑 - 对比
$upstream_header_time和$upstream_response_time：前者稳、后者飙升 → 后端业务慢；两者同步升 → 可能是Nginx自身瓶颈（如worker_connections不够）或网络问题 - 记录
$upstream_bytes_received和$upstream_cache_status：排除缓存失效导致重复计算压力
