Nginx实现大文件分段上传负载均衡需保障会话一致性：必须用hash $arg_upload_id consistent;确保同文件分片路由至同一后端，禁用轮询；同时调大client_max_body_size、关闭proxy_buffering、延长超时，并配合后端分片合并逻辑与健康检查。
直接用 Nginx 做“大文件分段上传”的负载均衡，不能靠 upstream 简单轮询或加权转发来实现——因为分段上传本质是同一个文件的多个 HTTP 请求（如 `/upload?chunk=1`、`/upload?chunk=2`）需路由到同一台后端节点，否则合并失败。Nginx 本身不处理文件切片逻辑，但可通过合理配置保障分段请求的**会话一致性**和**后端协同能力**，这才是实战关键。
确保同一文件的所有分片落到同一台后端
必须启用 ip_hash 或更可靠的 hash $arg_upload_id consistent（需 Nginx ≥1.7.2），避免因客户端 IP 变化（如 NAT、移动网络）导致路由漂移：
- 推荐用业务层传递唯一标识，例如前端上传时生成
upload_id=abc123，所有分片带该参数 - 在 upstream 中配置哈希键：
hash $arg_upload_id consistent;，这样相同 upload_id 永远打到同一台后端 - 禁用轮询或 weight 分发，否则分片散落，后端无法识别属于哪个完整文件
后端服务需支持分片接收与合并逻辑
Nginx 只负责路由，真正处理分段的是后端（如 Spring Boot、Node.js 或 MinIO）。常见做法：
- 每个分片以
{upload_id}_{chunk_index}命名临时存入共享存储（如 Redis + 本地磁盘 / 或直接写入对象存储） - 收到最终合并请求（如
POST /merge?upload_id=abc123）后，按序读取、校验并拼接成完整文件 - 若用 MinIO 集群，Nginx 可对
/minio/upload路径做 upstream 转发，但需确保 MinIO 的 multipart upload 已启用且各节点能访问同一 bucket
规避 Nginx 自身的上传瓶颈与超时问题
默认配置下，Nginx 会缓存整个上传体到内存或临时文件，大文件易触发 client_max_body_size 和 proxy_buffering 限制：
- 在 server 或 location 块中显式放开：
client_max_body_size 4G; - 关闭代理缓冲（防止 Nginx 先收全再转）：
proxy_buffering off; - 调长超时：
proxy_connect_timeout 60s; proxy_send_timeout 3600s; proxy_read_timeout 3600s;（尤其合并操作可能耗时） - 若启用了 SELinux（如 CentOS），需确认
setsebool -P httpd_can_network_connect 1允许 Nginx 连接后端服务
配合健康检查与故障隔离提升可靠性
分段上传过程长，某台后端宕机可能导致部分分片丢失。建议：
- 使用开源模块
nginx-upstream-check-module主动探测后端 /health 端点 - 为 upstream 添加
max_fails=3 fail_timeout=30s，自动剔除异常节点 - 前端上传 SDK 应具备重试机制，对单个分片失败可重新提交，而非整文件重传
- 后端记录分片状态（Redis Hash 或数据库），支持断点续传和幂等写入
