负载均衡下大文件上传中断的根本原因是多节点间连接提前终止或状态丢失，需统一各层超时参数、同步会话上下文、避免分片跨节点失联，并通过一致性哈希、外置元数据或直传分片等策略保障连续性。
负载均衡环境下大文件上传中断失败，本质不是上传本身出错，而是请求在多个节点间流转时，某一层提前终止连接或丢失状态。关键不在“加宽管道”，而在“统一各段超时、同步会话上下文、避免分片跨节点失联”。
确保所有中间层超时参数严格对齐
负载均衡器（如Nginx、SLB、ALB）、后端应用服务器、PHP-FPM 或 Java 容器，三者超时值必须完全一致，否则任意一环先断开，就会返回 502/504 或静默截断：
-
Nginx（作为LB或反向代理）：必须同时配置
proxy_connect_timeout、proxy_send_timeout、proxy_read_timeout，建议统一设为600（10分钟），且不能只改其中一项 -
后端服务容器：如 Tomcat 的
connectionTimeout和keepAliveTimeout，Spring Boot 的server.tomcat.connection-timeout，需与 Nginx 值一致 -
PHP-FPM：
request_terminate_timeout必须 ≤ Nginx 的proxy_read_timeout，否则 PHP 进程被强杀，但 Nginx 还在等响应
禁用负载均衡的“会话漂移”干扰分片上传
分片上传依赖前后请求能命中同一台后端节点——因为分片元数据（如已传哪些 chunk、临时目录路径、合并状态）通常存在本地磁盘或内存中。若 LB 默认轮询，第二片可能落到无上下文的节点，导致重复上传或校验失败：
- 启用基于
upload_id或fileId的一致性哈希（如 Nginx 的hash $arg_upload_id consistent;），确保同一文件的所有分片固定路由到同一台机器 - 或改用 IP Hash（简单但不均衡），避免使用纯轮询或最少连接模式
- 更彻底的方案是将分片元数据外置：存入 Redis（含 upload_id → 已传 chunk 列表 + 状态），所有后端节点可共享状态，此时 LB 可自由调度
绕过负载均衡直传分片（针对关键路径）
对初始化上传、上传分片、合并完成这三个核心接口，可考虑跳过 LB，让前端直连具体后端节点（配合服务发现或 DNS 轮询）：
- 上传前先调用
/upload/init接口，服务端返回一个带节点标识的上传地址（如https://node2.example.com/upload/chunk?upload_id=xxx） - 后续所有分片请求都发往该地址，不经过 LB，规避转发链路中断风险
- 适用于集群规模不大、节点数固定、且能接受客户端感知后端拓扑的场景
补充：别忽略健康检查引发的误摘流
某些 LB 会对后端做主动健康检查（如每 5 秒 GET /health）。若上传过程中该节点正处理大文件，健康检查请求可能因超时被判定为异常，LB 立即摘除节点——正在上传的连接就被强制中断：
- 将健康检查路径设为轻量接口（如只返回 200，不查 DB、不读磁盘）
- 延长健康检查超时时间（如
timeout: 10s），并增大失败容忍次数（如连续失败 3 次才摘流） - 或为上传节点单独配置独立健康检查策略，与普通 API 节点区分开
