大文件分片上传需用upload_id一致性哈希路由确保同文件分片落同一后端，禁用轮询/ip_hash；Nginx需调大body限制、关闭proxy_buffering并延长超时；后端负责分片暂存与合并，配合健康检查和断点续传。
大文件分片上传不能靠普通轮询或权重转发——同一文件的多个分片（如 /upload?upload_id=abc123&chunk=1、&chunk=2）必须落到同一台后端，否则无法合并。Nginx 不处理切片逻辑，只负责精准路由和传输保障。
用 upload_id 做一致性哈希路由
避免依赖客户端 IP（易受 NAT、移动网络影响），推荐由前端生成全局唯一 upload_id 并带在每个分片请求参数中：
- 在
upstream块中配置：hash $arg_upload_id consistent;（要求 Nginx ≥ 1.7.2） - 禁用
ip_hash、轮询、weight等其他调度方式，防止分片打散 - 确保所有分片 URL 都含
upload_id参数，例如POST /upload?upload_id=xyz789&chunk=5
绕过 Nginx 自身上传瓶颈
Nginx 默认会缓存整个请求体，对大文件极易触发限制或超时：
- 在对应
location块中放开大小限制：client_max_body_size 4G; - 关闭代理缓冲：
proxy_buffering off;（避免 Nginx 先收全再转发） - 延长关键超时：
proxy_connect_timeout 60s;、proxy_send_timeout 3600s;、proxy_read_timeout 3600s;（尤其合并操作耗时长） - 若启用了 SELinux（如 CentOS），执行：
setsebool -P httpd_can_network_connect 1
后端需协同完成分片与合并
Nginx 只管“送对地方”，真正逻辑在后端：
- 各后端节点接收分片后，以
{upload_id}_{chunk_index}命名暂存（建议写入共享存储，如 Redis + 本地磁盘，或直传 MinIO） - 收到最终
POST /merge?upload_id=abc123请求时，按序拉取、校验（如 MD5）、拼接并落盘 - 若用 MinIO，确保其 multipart upload 已启用，且所有节点能访问同一 bucket
加入健康检查防分片丢失
上传过程长，单点故障会导致部分分片不可达：
- 在
upstream中为每台 server 加上：max_fails=2 fail_timeout=30s; - 配合主动健康检查（如 Nginx Plus 或自建探针），及时剔除异常节点
- 前端应支持断点续传：上传前先查
/status?upload_id=xxx获取已传分片列表
