大文件分片上传需用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 默认会缓存整个请求体，对大文件极易触发限制或超时：

Nginx Hosting

通过服务器本地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 获取已传分片列表