Nginx负载均衡策略需匹配后端连接特征：长连接占比＞30%用least_conn，短连接＜15%用轮询或weight，混合型（15%–30%）需结合健康检查与超时调优。
先识别你的连接模式
不要凭经验猜测，用真实数据说话：
- 在 Nginx 日志中开启
$connection_requests和$request_time字段，统计单位时间内每个 upstream server 的平均请求数与平均连接持续时间 - 用
ss -s或netstat -ant | grep :8080 | wc -l查看各后端服务器 ESTABLISHED 连接数占比（长连接主导时该值显著高于请求 QPS） - 检查应用层是否启用 HTTP/1.1 keepalive、gRPC 的长连接复用、WebSocket 等——这些都会大幅拉高长连接比例
长连接占比高（＞30%）→ 优先用 least_conn
轮询不感知连接状态，可能把新请求持续打到已持有上百个长连接的节点上，而空闲节点却闲置。least_conn 实时跟踪活跃连接数，天然适配长连接场景。
- 配置示例：
upstream backend {<br> least_conn;<br> server 192.168.1.10:8080;<br> server 192.168.1.11:8080;<br>} - 注意：需配合
max_fails=2 fail_timeout=15s防止单点故障拖累整体连接分发 - 若后端是 Java 应用，建议同步调大 Tomcat 的
maxConnections和acceptCount，避免连接拒绝被误判为失败
短连接为主（＜15%）→ 轮询或加权轮询更稳
每次请求即建连+断连，连接数波动小，least_conn 优势不明显，反而增加状态同步开销。此时应关注吞吐能力而非连接数。
- 统一硬件时用默认轮询即可；存在性能差异（如旧服务器 CPU 较弱）就用 weight，例如：
server 192.168.1.10:8080 weight=3;（新机器）server 192.168.1.11:8080 weight=1;（旧机器） - weight 值建议按 CPU 核心数或压测 TP99 比值设定，避免主观估测
- 禁用
ip_hash——短连接下它会造成严重负载倾斜，且无会话保持必要
混合型（15%–30%）→ 结合健康检查做动态调节
实际生产中多数属于此情况。不能只靠一种算法，要叠加被动探测 + 合理超时控制：
- 在 upstream 中为每台 server 显式配置：
server 192.168.1.10:8080 max_fails=3 fail_timeout=20s; - 调低 proxy_read_timeout（如设为 10s），快速释放卡住的短连接；同时调高 keepalive_timeout（如 75s），保障长连接复用效率
- 观察 Nginx 的
ngx_http_upstream_module状态页（需开启 stub_status），重点关注Active connections与Current requests的比值，比值＞5 说明长连接占主导，可倾向 least_conn
