关键在于匹配后端连接生命周期特征：先实测长/短连接比例，再分场景配置——长连接为主时用least_conn+keepalive池，短连接为主时用round-robin+合理超时。
优化 Nginx 负载均衡器的连接数策略，关键不是选“最先进”的算法，而是让调度逻辑匹配后端真实的连接生命周期特征。同一套配置在直播服务和支付接口上效果可能截然相反——因为前者长连接占比常超 50%，后者短连接可能占 90% 以上。核心动作是：先看清连接分布，再分场景定策略，最后用参数兜住边界。
看懂你的连接模式：别猜，要测
凭经验判断长/短连接比例容易出错。真实业务中，HTTP/1.1 keepalive、gRPC 流复用、WebSocket 持久化都会显著拉高长连接占比，而 RESTful API 配合客户端短连行为则倾向短连接主导。
- 在 Nginx access 日志中加入 $connection_requests 和 $request_time，统计每个 upstream server 的平均请求数与平均连接耗时，估算单连接承载请求数（比如平均 12 个请求/连接 → 偏长连接）
- 用 ss -s 查看各后端 ESTABLISHED 连接总数，再对比当前 QPS：若连接数远高于 QPS（例如连接数 8000，QPS 200），说明大量连接长期空闲 → 长连接主导
- 检查后端是否启用连接池（如 Tomcat 的 maxConnections、MySQL 的连接复用）、客户端是否复用连接（如 OkHttp 默认开启 connection pool）
长连接为主（>30%）：least_conn + keepalive 池
轮询会把新请求持续打到已持有数百个长连接的节点，空闲节点却无事可做。least_conn 实时感知活跃连接数，天然适配。
- 配置必须带 least_conn，并显式设置 keepalive N（N 一般设为后端平均并发连接数的 1.2 倍，常见 16–64）
- 搭配 max_fails=2 fail_timeout=15s，避免故障节点持续接收连接
- 后端需同步调大连接上限：Java 应用调高 maxConnections；Redis/MySQL 确保 maxclients 足够，否则连接被拒会被误判为失败
短连接为主（
每次请求即建连+断连，连接数几乎恒定，least_conn 不仅没优势，还增加状态同步开销。此时应关注吞吐能力而非连接数。
- 用 weight 按真实性能分配流量：建议按 CPU 核心数比值或压测 TP99 时间倒数设定（例如新机器 TP99 是旧机器一半，weight 可设为 2:1）
- 禁用 ip_hash：短连接下它会导致严重负载倾斜，且无会话保持必要
- 可配合 health_check（Nginx Plus）或被动探测（max_fails/fail_timeout）保障可用性
混合型（15%–30%）：least_conn + 动态超时 + 健康检查
这是生产环境最常见的情况。不能只靠一种算法，要叠加连接状态感知与生命周期控制。
- 仍以 least_conn 为基础，但每台 server 显式配置 max_fails=3 fail_timeout=20s，提升故障识别精度
- 调低 proxy_read_timeout（如 10–15s），快速释放卡死的短连接；同时调高 keepalive_timeout（如 75s），保障长连接复用效率
- 若后端支持（如 gRPC、WebSocket），启用 proxy_http_version 1.1 和 proxy_set_header connection ""，避免连接头冲突
