大文件上传被Nginx中断，本质是代理链路中某环节超时或限制触发：先查client_max_body_size是否拦在首关（413错误），再分清proxy_send_timeout（发请求体给后端）与proxy_read_timeout（等后端响应）的定位差异，同步检查临时目录空间、权限及前后端超时对齐。
大文件上传被 Nginx 中断，表面看是“上传失败”，实际多数不是后端挂了，而是 Nginx 在代理链路中主动切断了连接。关键要区分清楚：是卡在“发给后端”、还是“等后端回”，抑或根本没走到后端。排查需从请求生命周期逐段验证，而不是盲目调大所有 timeout。
先确认是不是被 Nginx 拦在第一关：client_max_body_size
这是最常被跳过的一步。Nginx 默认只允许 1MB 请求体，超限直接返回 413 错误——但前端往往收不到完整错误页，只显示“网络中断”或空响应。
- 检查 error.log 是否有 "client intended to send too large body" 日志
- 在对应 location 块中显式设置：client_max_body_size 2G;（不要写 0，生产环境需设合理上限）
- 注意该指令生效位置：仅对当前 location 或其子路径有效，避免全局滥用
定位中断发生在哪一环：分清 proxy_send_timeout 和 proxy_read_timeout
两者作用完全不同，混淆会导致调错参数、问题依旧：
- proxy_send_timeout：控制 Nginx 把文件数据“发给后端”的过程。若后端接收慢（如磁盘 I/O 阻塞、未及时 read socket），Nginx 发一段后等不到 ACK，就会断连，日志常见 "upstream prematurely closed connection while reading upstream" 或 "Broken pipe"
- proxy_read_timeout：控制 Nginx “等后端返回响应”的空闲间隔。它不是总耗时，而是两次数据包之间的最大等待时间。后端流式返回但间隔超值（比如每 58 秒 flush 一次，你配了 60 秒），也会触发 504
- 建议初值：两者都设为 3600（1 小时），再根据实际上传耗时和后端吞吐反推优化
检查临时存储与系统级瓶颈
Nginx 接收大文件时默认先写入磁盘临时文件（client_body_temp_path），若路径空间不足、权限不对或 I/O 过载，会静默失败。
- 确认 client_body_temp_path 所在分区有足够空间（建议 ≥ 文件上限的 2 倍）
- 检查该路径属主是否为 nginx 运行用户（如 www-data 或 nginx），且有读写权限
- 用 ss -s 或 netstat -s | grep -i "packet loss" 查看系统是否存在丢包或队列溢出
- 必要时调大内核参数：net.core.somaxconn 和 net.ipv4.tcp_max_syn_backlog 至 65535
别忘了客户端和后端的配合配置
Nginx 调通了，不代表整个链路就稳了。三方超时必须对齐：
- 前端 SDK（如 axios）需同步延长 timeout，例如：timeout: 3600000（60 分钟）
- 后端框架也要放开限制：Spring Boot 需配 spring.servlet.multipart.max-file-size=2GB；Node.js 的 Express 需调 body-parser 或 multer 限制
- 后端应用自身处理逻辑（如鉴权、格式校验）不能阻塞主线程，否则会拖慢接收速度，间接触发 proxy_send_timeout
