根本原因是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 签名过期等）