Nginx 中负载均衡中处理后端连接数限制策略

核心是按连接特征差异化配置：长连接用least_conn+keepalive，短连接用weight分流，混合场景需least_conn配合动态超时与健康检查；必须依据access日志、ss命令及后端连接池数据决策，而非经验猜测。

核心是让 Nginx 的连接调度行为，贴合后端真实的服务模式——不是统一设限，而是按长连接、短连接或混合场景分别应对。

识别后端连接特征

别靠经验猜，要用数据说话：

1. 查 access 日志里的 $connection_requests 和 $request_time，算出平均每个连接处理多少请求（比如 >10 → 偏长连接）
2. 用 ss -s 看 ESTABLISHED 连接总数，再对比当前 QPS：若连接数远高于 QPS（如 5000 连接对应 200 QPS），说明大量空闲长连接存在
3. 确认后端是否启用连接池（如 Tomcat 的 maxConnections、MySQL 的 max_connections）、客户端是否复用连接（如 OkHttp 默认开启 pool）

长连接为主时：least_conn + keepalive 池

轮询会把新请求不断打到已满载的节点，而 least_conn 能实时感知活跃连接数，更公平：

1. upstream 中必须写 least_conn，并配置 keepalive 16–64（建议设为后端平均并发连接数的 1.2 倍）
2. 搭配 max_fails=2 fail_timeout=15s，避免故障节点持续收连接
3. 后端同步调大连接上限：Java 应用提高 maxConnections；Redis/MySQL 确保 maxclients 不被触达

短连接为主时：weight 分流 + 禁用 ip_hash

每次请求都新建断连，连接数基本恒定，least_conn 反而增加开销，此时应看吞吐能力：

1. 用 weight 按真实性能分配流量，例如按 CPU 核心数比值，或压测 TP99 时间倒数设定（TP99 为旧机器一半，weight 可设 2:1）
2. 必须关闭 ip_hash，否则短连接下极易造成负载倾斜
3. 启用被动健康检查（max_fails/fail_timeout）保障可用性，不依赖会话保持

混合型场景：least_conn + 动态超时 + 健康检查

生产环境最常见（长连接占比 15%–30%），需多层协同：

1. 保留 least_conn 做基础连接感知
2. 精细设置三类超时：proxy_connect_timeout（1–3s）、proxy_send_timeout（10–30s）、proxy_read_timeout（略大于后端最长处理时间）
3. 禁用无效重试：proxy_next_upstream error timeout http_500，避免一次失败引发多次建连