最小连接数算法在高并发短连接场景下易失效，因短连接导致active连接数频繁归零、数值趋同，使least_conn退化为轮询；需关闭keepalive、启用passive健康检查、调优系统fd限制及监控响应分布。
最小连接数算法在高并发短连接场景下容易失效，不是算法本身有问题，而是默认配置与短连接特性严重不匹配。短连接频繁建连断连，导致“活跃连接数”无法真实反映后端负载，反而让调度变成伪随机——关键要让 Nginx 看清“谁真闲、谁真忙”。
为什么短连接会让 least_conn 失效
短连接生命周期极短（毫秒级），请求一完成就断开。Nginx 统计的 active connections 刚升上来就归零，各节点数值频繁抖动、趋于一致，least_conn 实际退化为轮询。更糟的是，若后端响应延迟略有差异（比如某台磁盘慢 20ms），该节点会在瞬间堆积更多并发连接，而 Nginx 因缺乏健康反馈机制，仍持续派发新请求过去。
必须关闭 keepalive 并禁用连接复用
在纯短连接场景中，upstream 中配置 keepalive 反而有害：它会维持空闲连接，虚高 active 连接数，干扰 least_conn 判断。正确做法是彻底关闭连接池复用：
- upstream 块内不写
keepalive N - proxy 层显式关闭 HTTP/1.1 长连接：
proxy_http_version 1.1;+proxy_set_header Connection "close"; - 确保后端服务也返回
Connection: close，避免静默复用
用 passive 健康检查替代主动探测
短连接高频发压，主动健康检查（如 interval=3s）会额外增加后端负担，且难以覆盖瞬时卡顿。应依赖 passive 检查快速剔除异常节点：
- 配置
proxy_next_upstream error timeout http_500 http_502 http_503 http_504; - 每个 server 必须设
max_fails=2 fail_timeout=10s，保证两次失败即摘除 - 配合
proxy_connect_timeout 1s和proxy_read_timeout 2s，让超时更快触发 failover
调整 worker_connections 与系统限制对齐
短连接爆发时，并发 socket 数量直线上升，worker_connections 不只是数字，更是文件描述符（fd）消耗主因：
- 设
worker_connections 65535，同时配worker_rlimit_nofile 65535 - 系统层执行：
sysctl -w fs.file-max=2097152，并为 nginx 用户设置soft/hard nofile 65535 - 监听端口加
backlog=65535，防止 SYN 队列溢出丢包：listen 80 backlog=65535;
监控重点不是连接数，而是失败率与响应分布
短连接场景下，$upstream_connect_time 和 $upstream_header_time 的 P95 差值能暴露问题：
- 若 connect_time P95 正常（
- 若两者同步升高，检查是否因
net.ipv4.tcp_tw_reuse=1未启用，导致 TIME_WAIT 耗尽端口 - 记录
$upstream_addr和$status，观察失败是否集中于某台服务器——若是，说明 max_fails 未生效或后端未及时返回错误码
