要减少大文件上传中断，需精准匹配client_max_body_size与业务流量、网络及系统能力，在处理上传的location块中单独配置，如/upload设50m、/api/v1/chunk设20m；结合文件类型设定合理上限（如商品图10m、tiff/pdf报告50m），避免全局设0或过大；同步调大client_body_buffer_size（512k～1m）、client_body_timeout（300s）、proxy_read/send_timeout（600～3600s），并确保temp_path磁盘空间充足、权限正确；还需对齐api网关、后端框架（spring boot/php/node.js）及前端组件的限制参数。
要减少大文件上传过程中的异常中断，核心是让 client_max_body_size 与实际业务流量、网络条件和系统能力相匹配，而不是简单设大或设零。中断往往不是因为“不够大”，而是配置错位、配套参数失衡或链路未对齐。
按上传路径精准设置，避免全局放宽
把参数写在真正处理上传请求的 location 块里，是最稳妥的做法。比如前端调用的是 /upload 或 /api/v1/chunk，那就只在这个 location 中设置：
location /upload { client_max_body_size 50m; }location /api/v1/chunk { client_max_body_size 20m; }- 不建议在
http或server块统一设为 0 或 1G——这会把登录、查询等非上传接口也暴露在大请求风险下
结合典型文件类型设定合理上限
数值不是越大越好，应略高于业务中 95% 的单次请求体大小，并预留缓冲空间：
- 普通商品图（JPEG/PNG）：设 10m 足够支持 4K 清晰度
- 带元数据的 TIFF、PDF 报告或三维扫描包：可设 50m
- 后台批量上传高清样品图集：可在对应 location 设 100m，但需叠加 IP 鉴权或速率限制
- 不推荐设为
0，除非是可信内网调试环境
同步调整超时与缓冲参数
只改 client_max_body_size 不足以稳定上传，还需协同优化 Nginx 内部处理机制：
-
client_body_buffer_size设为 512k～1m：太小（如默认 8k）会导致频繁刷盘；太大则浪费内存 -
client_body_timeout设为 300（5 分钟）：防止弱网环境下单片上传中途断连 -
proxy_read_timeout和proxy_send_timeout建议设为 600～3600：给后端校验、存储、回调留出足够时间 - 确认
client_body_temp_path所在磁盘空间充足，且 Nginx 进程用户有读写权限
确保全链路限制对齐
Nginx 放行后，请求还会流经 API 网关、微服务、语言运行时等环节，任一环卡住都会表现为中断或静默失败：
- Spring Boot：检查
spring.servlet.multipart.max-file-size和max-request-size - PHP：同步调大
upload_max_filesize、post_max_size和memory_limit - Node.js（Express + Multer）：初始化时明确指定
limits: { fileSize: 50 * 1024 * 1024 } - 前端上传组件（如 Ant Design Upload）也要核对
maxSize是否与后端一致，避免前端拦截掩盖真实问题
