根本原因是Nginx在请求体进入时即拦截超限数据，即使分片上传，单个HTTP请求body超过client_max_body_size也会直接返回413；必须在具体分片路径（如/api/upload/）的location块中单独配置client_max_body_size、超时及临时目录权限等参数。
静态资源分段上传路径报 413 错误，根本原因是 Nginx 在请求体进入时就拦截了超限数据——哪怕你用的是分片（如 tus、cos-js-sdk-v5、minio-js 的 multipart upload），只要单个 HTTP 请求的 body 超过 client_max_body_size，Nginx 就会直接返回 413，根本不会把请求转发给后端或触发分片逻辑。
必须配在分片上传的实际 endpoint 路径下
分段上传通常有明确的 API 路径，例如：
-
/api/upload/init（初始化） -
/api/upload/chunk（上传分片） -
/api/upload/complete（合并完成）
这些请求虽然单片体积可控，但某些初始化请求可能携带较大元数据（如 base64 编码的缩略图、JSON 描述），或某次 chunk 请求意外偏大。不能只依赖“分片小”就忽略限制。
✅ 正确做法：在匹配这些路径的 location 块中单独配置，例如：
location /api/upload/ {
client_max_body_size 200m;
proxy_pass http://backend;
}
⚠️ 不要只写在 http 或根 server 块里——容易被其他 location 覆盖，也缺乏针对性。
注意分片上传特有的临时文件权限问题
分段上传过程中，Nginx 可能将每个 chunk 写入临时磁盘（尤其当 chunk 大于 client_body_buffer_size 时）。若 client_body_temp_path 目录空间不足，或 Nginx 运行用户（如 www-data 或 nginx）无写权限，会转为 500 错误，而非 413。
检查并确保：
- 临时路径磁盘剩余空间 ≥ 单次最大 chunk × 并发数（建议预留 5–10 GB）
- 执行
ls -ld /var/nginx/client_body_temp（或自定义路径），确认属主和权限可写 - 必要时显式声明：
client_body_temp_path /data/nginx/tmp 1 2;
配套参数要同步调高，避免超时中断分片流
分段上传是长连接、多请求过程，Nginx 默认的短超时会切断 chunk 流，导致上传卡住或报 499/502。
在对应 location 块中一并设置：
-
client_header_timeout 300;（防止初始化请求头读取超时） -
client_body_timeout 300;（防止单个 chunk 体传输慢被中断） -
proxy_read_timeout 3600;（后端处理合并等耗时操作） -
proxy_send_timeout 3600;（避免 Nginx 向客户端回传响应时超时）
验证是否真由 Nginx 拦截，而不是分片逻辑失败
别急着改配置，先定位错误源头：
- 看响应状态码是 413 且响应头含
Server: nginx→ 确认是 Nginx 层拦截 - 查 Nginx error log（
/var/log/nginx/error.log），搜索client intended to send too large或413 - 对比前端发起的每个分片请求的 Content-Length，找出哪次实际超限（可用 curl -v 或浏览器 Network 面板查看）
- 如果后端日志完全没记录该请求 → 基本锁定为 Nginx 拦截；若有记录但失败 → 问题在后端分片逻辑或存储服务（如 MinIO 权限、S3 签名过期等）
