proxy_next_upstream对大文件上传基本无效，因其仅在请求体完整接收且上游返回502/504等错误时触发，而弱网断连、超时中断等常见场景均不满足条件；真正有效的是前端分片上传+服务端断点续传。
大文件上传中断时，Nginx 的故障转移（proxy_next_upstream）默认不适用于上传场景，强行启用反而会加剧失败——因为重试会把未传完的请求体重复发给另一个上游节点，既浪费带宽，又可能触发二次超时或 413 错误。真正的解法不是让 Nginx “自动重试”，而是前端主动控制分片 + 服务端记录进度，把“重试”从网关层下沉到业务层。
为什么 proxy_next_upstream 对大文件上传基本无效
默认开启的 proxy_next_upstream 仅在以下情况生效：
– 请求体已完整接收并缓存（proxy_request_buffering on）；
– 向上游转发时发生 502/504 或连接拒绝等错误。
但大文件上传中，常见中断是：
– 客户端弱网断连（Nginx 还没收完 body，不触发 upstream 错误）；
– 后端接收慢导致 proxy_send_timeout 触发（此时连接已断，Nginx 不会重试）；
– 分片上传过程中某一片失败，其余仍有效（无需整请求重发）。
这些场景下，proxy_next_upstream 压根不会介入，配置了也等于没配。
真正有效的上传中断应对策略
把可靠性保障前移到业务逻辑，而非依赖反向代理的通用重试机制：
- 前端分片 + 独立重试：将文件切为 5MB 左右分片，每片单独发起 POST 请求；任一分片失败，只重传该片，不影响其他已成功分片
-
服务端持久化上传状态：用 upload_id 标识一次上传，数据库或 Redis 记录每个分片的完成状态（如
chunk_index: 12, status: success） -
断点续传接口必须存在：提供
GET /upload/resume?upload_id=xxx接口，返回已上传分片列表，前端据此跳过、只补传缺失项 - 合并动作异步化：所有分片收齐后，不阻塞响应，而是由后台任务触发合并、校验、转码等耗时操作，再通过回调或消息通知结果
Nginx 配置需配合业务逻辑关闭干扰项
避免 Nginx 自身机制破坏分片语义：
-
关闭请求体缓冲：在上传 location 中设
proxy_request_buffering off，防止 Nginx 强行缓存整个文件再转发，与分片流式上传冲突 -
禁用 proxy_next_upstream 上传路径：明确在
location /api/upload块中写proxy_next_upstream off，杜绝误重试 -
调高关键超时但不滥用：设
proxy_send_timeout 600（防后端接收慢）、client_body_timeout 600（防客户端弱网间隔长），但保持keepalive_timeout合理（如 60s），避免连接积压 -
限制单次请求大小：
client_max_body_size 6m（略大于分片大小），既允许单片上传，又防止用户误传整文件绕过分片逻辑
异常兜底与可观测性补充
即使做了分片，也要预设最坏情况：
- 服务端对 upload_id 设置 TTL（如 24 小时），超时自动清理残留分片，避免磁盘被碎片占满
- 前端上传前先发 HEAD 请求校验 upload_id 是否有效，避免断网重连后继续往一个已失效上下文里传
- Nginx 日志中增加
$upstream_http_x_upload_status等自定义头，记录分片索引和状态，便于排查哪一片卡住 - 监控 502/504 错误率突增——若非零，说明后端接收能力出问题，需查
proxy_send_timeout是否仍不足或后端进程卡死
