least_conn不适合短生命周期接口，因其活跃连接数始终趋近于0，算法退化为随机分发；短连接场景下建连即断，无法反映真实负载，失去动态调度意义。
least_conn 对微服务短生命周期接口基本不适用，强行启用反而会削弱调度效果。短连接场景下，每个请求建连又断连，Nginx 统计的“活跃连接数”始终趋近于 0，算法退化为随机分发，失去意义。
为什么 least_conn 不适合短生命周期接口
微服务短生命周期接口（如 RESTful 查询、鉴权校验、轻量状态同步）通常具备以下特征：
- 单次请求耗时极短（
- 后端处理完立即返回，TCP 连接很快进入 TIME_WAIT 或被主动关闭
- Nginx 每次看到的活跃连接数几乎恒定为 0 或 1，无法形成有效区分
- least_conn 的核心优势——避开高连接负载节点——在该场景中完全无法触发
更适合短接口的替代方案
应放弃 least_conn，改用更匹配短连接特性的策略：
- round-robin + weight：按真实性能分配流量，例如按 CPU 核心数比值设 weight（4核:8核 → weight=1:2）
- ip_hash（慎用）：仅在需会话粘性且客户端 IP 稳定时考虑；短连接下易导致严重倾斜，一般不推荐
- hash $request_uri consistent：对相同路径做一致性哈希，提升缓存命中率，适合读多写少的微服务网关
- 若使用 Nginx Plus，可启用 least_time last_byte，但需确认后端支持准确响应时间上报
必须同步优化的配套参数
无论选哪种算法，短连接场景下这些配置直接影响吞吐与稳定性：
- 禁用 upstream 中的 keepalive（设为 0 或直接不写），避免空闲连接干扰连接数统计
- 缩短超时：proxy_connect_timeout 3s、proxy_send_timeout 5s、proxy_read_timeout 8s（略高于 P99）
- 开启失败重试：proxy_next_upstream error timeout http_500 http_502，配合 max_fails=2 fail_timeout=15s 快速摘除异常节点
- 后端服务需调低 TCP linger 时间，避免 TIME_WAIT 占满端口；Java 应用建议设置
server.tomcat.connection-timeout=2000
如何验证是否真为短连接主导
别凭经验判断，用数据确认：
- 查 access log：加
$connection_requests字段，统计单连接平均请求数；若普遍 ≤ 2，即属短连接 - 用
ss -s | grep "tcp:"观察 ESTABLISHED 连接总数，对比当前 QPS；若连接数 ≈ QPS × 1.5 以内，说明无明显长连接堆积 - 检查后端响应头：是否存在
Connection: close或缺失Keep-Alive头
