大文件下载需用least_conn+weight动态调度、proxy_buffering off流式传输、URI一致性哈希实现sticky session，并配健康检查与超时调优。
大文件下载场景下，Nginx负载均衡不能只靠默认的轮询或IP哈希——连接时长高、带宽占用大、单连接持续时间久，容易导致后端节点负载不均甚至阻塞。关键在于：避免长连接堆积、减少传输中断、让空闲能力强的节点承接更多流量。
优先使用 least_conn + 连接数权重动态调度
默认轮询不考虑后端当前连接压力，而大文件下载会维持长时间 TCP 连接（可能数分钟甚至小时），least_conn 能真实反映各上游服务器的实时负载。更进一步，可结合 weight 参数为硬件配置更强（如更高带宽、SSD 存储、更大 socket buffer）的节点分配更高权重：
- 在 upstream 块中启用
least_conn，并为不同后端设置合理 weight（例如：16核64G+10Gbps 网卡的机器设为weight=3，普通节点设为weight=1） - 配合
max_conns限制单台后端最大并发连接数（如max_conns=200），防止某节点被长连接占满 - 注意：该策略依赖 Nginx 主进程统计连接数，需确保所有 worker 进程共享状态（默认开启，无需额外配置）
关闭 proxy_buffering 并调优超时参数
大文件下载若开启缓冲（proxy_buffering on），Nginx 会先收完整个文件再吐给客户端，极大消耗内存和磁盘临时空间，还可能触发 proxy_max_temp_file_size 限制导致失败。应改为流式透传：
- 显式设置
proxy_buffering off，让响应体直接从后端流式转发到客户端 - 增大超时值：将
proxy_read_timeout和proxy_send_timeout设为远高于平均下载耗时（如 3600 秒），避免因慢速客户端或网络抖动断连 - 禁用请求体缓冲：
client_body_buffer_size 0（对下载服务通常无需接收请求体）
用 sticky session 避免跨节点续传失败
若业务支持断点续传（Range 请求），且后端未做全局存储共享（如未共用 NFS 或对象存储），则同一文件的多次 Range 请求必须落到同一台后端，否则 416 错误不可避免。此时需基于请求特征“粘性”调度：
- 推荐使用
sticky cookie（需 nginx-plus）或开源版兼容方案：用hash $request_uri consistent实现 URI 一致性哈希——相同文件路径总路由到固定后端 - 若 URL 含版本号或哈希（如
/dl/app-v2.3.1.zip），此方式天然稳定；若含随机参数（如?t=171xxxx），需先用map提取纯净路径再哈希 - 慎用 IP 哈希：NAT 环境下多个用户共享一个出口 IP，易造成单点过载
监控与熔断：防止雪崩传导
单个后端故障或拥塞若不及时隔离，会通过重试/超时传导至其他节点。需主动感知并规避问题实例：
- 启用健康检查：
health_check interval=3 fails=2 passes=2，检查路径建议用轻量端点（如/health?disk=download），验证磁盘 IO 和可用空间 - 配合
slow_start=30s，让刚恢复的节点逐步承接流量，避免瞬间压垮 - 设置
proxy_next_upstream error timeout http_500 http_502 http_503 http_504，并在出现连续错误时快速切走流量
不复杂但容易忽略：大文件下载的本质是 I/O 密集型任务，均衡策略要围绕连接生命周期、吞吐承载力和数据局部性来设计，而不是套用 Web API 的短连接模型。
