核心是按连接特征差异化配置：长连接用least_conn+keepalive，短连接用weight分流，混合场景需least_conn配合动态超时与健康检查；必须依据access日志、ss命令及后端连接池数据决策，而非经验猜测。
核心是让 Nginx 的连接调度行为，贴合后端真实的服务模式——不是统一设限，而是按长连接、短连接或混合场景分别应对。
识别后端连接特征
别靠经验猜，要用数据说话：
- 查 access 日志里的 $connection_requests 和 $request_time，算出平均每个连接处理多少请求（比如 >10 → 偏长连接）
- 用 ss -s 看 ESTABLISHED 连接总数，再对比当前 QPS：若连接数远高于 QPS（如 5000 连接对应 200 QPS），说明大量空闲长连接存在
- 确认后端是否启用连接池（如 Tomcat 的 maxConnections、MySQL 的 max_connections）、客户端是否复用连接（如 OkHttp 默认开启 pool）
长连接为主时：least_conn + keepalive 池
轮询会把新请求不断打到已满载的节点，而 least_conn 能实时感知活跃连接数，更公平：
- upstream 中必须写 least_conn，并配置 keepalive 16–64（建议设为后端平均并发连接数的 1.2 倍）
- 搭配 max_fails=2 fail_timeout=15s，避免故障节点持续收连接
- 后端同步调大连接上限：Java 应用提高 maxConnections；Redis/MySQL 确保 maxclients 不被触达
短连接为主时：weight 分流 + 禁用 ip_hash
每次请求都新建断连，连接数基本恒定，least_conn 反而增加开销，此时应看吞吐能力：
- 用 weight 按真实性能分配流量，例如按 CPU 核心数比值，或压测 TP99 时间倒数设定（TP99 为旧机器一半，weight 可设 2:1）
- 必须关闭 ip_hash，否则短连接下极易造成负载倾斜
- 启用被动健康检查（max_fails/fail_timeout）保障可用性，不依赖会话保持
混合型场景：least_conn + 动态超时 + 健康检查
生产环境最常见（长连接占比 15%–30%），需多层协同：
- 保留 least_conn 做基础连接感知
- 精细设置三类超时：proxy_connect_timeout（1–3s）、proxy_send_timeout（10–30s）、proxy_read_timeout（略大于后端最长处理时间）
- 禁用无效重试：proxy_next_upstream error timeout http_500，避免一次失败引发多次建连
