least_conn算法在大文件上传下载场景中失真，因其仅统计连接数而无法反映磁盘%util、网卡吞吐等真实io负载；需配合keepalive、健康检查及io感知动态加权调度。
least_conn 算法本身不区分请求类型，它只看每个后端当前有多少活跃 TCP 连接。大文件上传下载恰恰会建立大量长连接、持续占用连接数但实际 CPU 消耗很低，这就导致 least_conn 容易把新请求继续分给“连接数少但带宽或磁盘已打满”的节点——表面空闲，实则过载。
为什么大文件会让 least_conn “失真”
连接数 ≠ 真实 IO 负载：
- 一个 100MB/s 的下载连接，和十个 10MB/s 的下载连接，连接数差 10 倍，但网卡吞吐压力可能完全一样
- 磁盘 %util > 90% 或 TCP 发送缓冲区积压时，least_conn 完全感知不到，仍可能往该节点分发新上传请求
- 连接长时间存在（几十秒到几分钟），导致活跃连接数堆积，统计滞后于真实资源水位
必须配合的三项基础配置
让 least_conn 至少能“看清”连接状态：
- 在 upstream 中启用 keepalive 32，并确保后端服务支持 HTTP Keep-Alive（如 Tomcat 设置 keepAliveTimeout，Uvicorn 加 --keep-alive）
- 每个 server 行加上 max_fails=2 fail_timeout=15s，避免故障节点持续参与调度
- 上传专用 location 中关闭预读：proxy_request_buffering off，防止 Nginx 把整个大文件缓存在内存里再转发，造成连接假性挂起
针对大文件的增强调度策略
仅靠 least_conn 不够，需叠加 IO 感知能力：
- 用 iostat -x 1 采集后端磁盘 %util、await、r_await；或用 /proc/net/dev 监控网卡 RX/TX bps
- 将这些指标上报给 LB（如通过 OpenResty + Lua 或外部服务），动态调整节点权重：effective_weight = 1 / (1 + α × io_util)
- 当某节点磁盘 %util > 85% 或网卡利用率超阈值时，主动暂停分发新连接，并对已有低速连接（如连续 10 秒
更治本的架构级优化
从源头减少应用层 IO 压力，让 least_conn 更“省心”：
- 前端直传对象存储（OSS/S3），Nginx 只处理回调通知，彻底绕过上传路径
- 下载走 CDN + Range 支持，静态资源由边缘节点响应，回源按需拉取小块
- 后端启用 sendfile 或 io_uring，避免用户态拷贝，降低单连接的内核开销
