least connections算法在大文件下载场景下效果显著，但需精准配置：必须启用主动健康检查（如health_check）、合理设置keepalive连接池与weight权重，并通过stub_status等监控active connections验证真实负载均衡效果。
Least Connections（最小连接数）算法在大文件下载这类长耗时、高连接占用场景下效果显著，但前提是配置必须精准匹配其运行逻辑——它不是“挑个空闲机器”，而是“在健康、可复用、权重合理的节点中，选此刻活跃连接最少的那个”。配置不当反而会放大延迟或导致连接堆积。
必须启用主动健康检查，避免故障节点持续吸流
大文件下载过程中，后端可能因磁盘I/O瓶颈、网络卡顿或进程假死而响应缓慢甚至无响应。Nginx默认仅靠被动失败重试（proxy_next_upstream）无法及时感知这类“软故障”。若不剔除，新请求仍会被分发过去，连接数虚高却无实际处理能力。
- 推荐使用商业版或带patch的开源Nginx，配置主动健康检查：
health_check interval=5 fails=3 passes=2 match=download_ok; - 搭配自定义match块，校验HTTP状态码为200且响应头含
Content-Length或Accept-Ranges，确保服务真正就绪 - 若无法启用主动检查，至少强化被动机制：
proxy_next_upstream error timeout http_500 http_502 http_503;
并为每个server设置max_fails=3 fail_timeout=20s
合理配置keepalive与连接复用，防止连接数统计失真
大文件下载多走HTTP/1.1长连接，若Nginx与后端之间未开启连接池，每分块传输都新建连接，会导致$upstream_addr中连接数频繁归零，“最小连接”退化为伪随机调度。
- upstream内启用连接池：
upstream download_backend {<br> least_conn;<br> keepalive 64;<br> server 10.0.2.10:8080 max_fails=3 fail_timeout=20s;<br> server 10.0.2.11:8080 max_fails=3 fail_timeout=20s;<br>} - 后端服务同步开启连接复用：如Tomcat需设
maxKeepAliveRequests="1000"，Go服务启用http.Server.IdleTimeout - Nginx全局调优：
keepalive_timeout 60s;和keepalive_requests 10000;，保障客户端长连接稳定
按后端吞吐能力配weight，避免小规格机器过早打满
两台机器同时跑大文件服务，若一台是16核64GB，另一台是4核16GB，但都设weight=1，最小连接算法会在它们连接数接近时平均分发——结果小机器很快连接数见顶，大机器却仍有余量。
- weight应反映实际吞吐能力，建议按CPU核心数线性折算：
4核机器设weight=1，16核则设weight=4 - 若某节点磁盘IO是瓶颈（如SATA vs NVMe），可额外加权：NVMe节点
weight=5，SATA节点weight=2 - 上线新节点时务必加
slow_start=60s，避免冷启动瞬间涌入大量下载请求
监控关键指标，验证算法是否真正生效
不能只看日志里有没有least_conn字样，要通过数据确认它是否在“看清真实负载”：
- 通过
stub_status或Prometheus exporter，实时观测各后端active connections：理想状态下差异应控制在±10%以内；若某台持续高于均值30%，说明健康检查未生效或weight失衡 - 记录
$upstream_header_time与$upstream_response_time：前者稳定但后者飙升，问题在后端IO或网络；两者同步升高，可能是Nginx自身瓶颈（如worker_connections不足或系统文件描述符不够） - 开启详细日志：
log_format download_log '$remote_addr - $upstream_addr [$time_local] $status $body_bytes_sent $upstream_response_time';，排查是否出现反复重试或错误分发
