413错误本质是Nginx在入口拦截单次请求体超限，须在分段上传的location块中单独配置client_max_body_size（如50m），并同步调大client_body_timeout、proxy_read_timeout等配套参数，且后端限制需与之对齐。
分段上传路径下出现 413 错误，本质仍是 Nginx 在请求体进入第一道关卡时就拦截了——哪怕你前端做了分片、后端支持断点续传，只要**单次 HTTP 请求的 body 大小**超过 Nginx 的 client_max_body_size，就会立刻返回 413，且不转发、不记录后端日志。
必须在分段上传的 location 路径里单独配置
分段上传通常走特定接口，如 /api/v1/chunk/upload、/upload/part 或带 X-Upload-ID 头的通用上传路由。这类路径不能依赖全局或 server 级配置，因为：
- 其他非上传接口（如登录、查询）不该继承大 body 限制，否则增加攻击面
- 分段请求虽单片小（如 5MB），但某些客户端或 SDK 可能合并多片发一次（尤其首片含元数据+文件头），实际 body 可能达 10–20MB+
- 若只在
http块设了100m，但该 location 所属的server块里又写了client_max_body_size 1m，则以 location 内最细粒度为准——而 location 块里没写，就继承 server 的 1m
✅ 正确写法（放在匹配分段上传路径的 location 块中）：
location /api/v1/chunk/upload {
client_max_body_size 50m;
proxy_pass http://backend;
proxy_set_header Host $host;
}
配套超时与缓冲参数要同步加大
分段上传不是“一次传完”，而是多次小请求，但每片上传仍需稳定连接和合理缓存。光调 client_max_body_size 不够：
-
client_body_timeout：默认 60 秒，若网络抖动导致某一片上传慢于该值，Nginx 直接中断并报 413（错误信息可能含 “client closed connection while reading body”）。建议设为300（5 分钟） -
proxy_read_timeout和proxy_send_timeout：后端处理分片校验、存储、回调可能耗时，建议统一设为600（10 分钟）以上 -
client_body_buffer_size：设为1m，让常见分片（≤1MB）走内存，避免频繁刷盘影响吞吐
确认分片请求是否真被 Nginx 拦截
别假设是“分段逻辑出错”。先验证是不是 Nginx 层挡的：
- 用
curl -v上传一个 2MB 的测试分片，看响应头是否有Server: nginx和状态码413 - 检查 Nginx error log（如
/var/log/nginx/error.log），搜索关键词：client intended to send too large body - 执行
nginx -T | grep -A2 -B2 "chunk/upload"，确认你改的 location 块确实加载且生效
后端分片接收逻辑也要对齐限制
Nginx 放行后，分片请求会到达后端服务。此时需确保：
- Spring Boot：即使用了分片，
spring.servlet.multipart.max-file-size仍控制单个请求的 body 上限，必须 ≥ Nginx 设置值（如 Nginx 设 50m，这里也得设50MB） - Node.js + Multer：每个
upload.single()或upload.fields()调用都受limits.fileSize约束，不能只在全局中间件设一次 - PHP：
upload_max_filesize控制单文件，但分片是“多个小文件请求”，所以重点是post_max_size——它限制整个 POST 请求体，必须 ≥ 单片最大可能大小
