直接改client_max_body_size不能单独解决413问题，必须在匹配路径的location块中设置，并同步调优client_body_buffer_size、client_body_temp_path权限及proxy_read_timeout等参数，否则仍会因缓冲、权限或超时导致失败。

直接改 client_max_body_size 就能解决上传被拦在 413 的问题，但只改它大概率还是失败——因为 Nginx 在请求体进入后还会做缓冲、超时、临时文件写入等动作，漏掉任一环节都会卡住或报错。

client_max_body_size 必须写在 location 块里才真正生效

很多人把 client_max_body_size 放在 http 或 server 块里，结果上传接口仍返回 413。根本原因是：你调用的是 /api/upload 这类路径，而 Nginx 的匹配优先级是 location > server > http。如果没在匹配该路径的 location 块中显式设置，就可能继承了更上层的默认值（1M）或错误覆盖值。

• ✅ 正确做法：在 proxy 转发的 location 中设，例如 location /api/upload { client_max_body_size 500m; proxy_pass http://backend; }
• ⚠️ 不推荐：仅在 server 块设——整个域名下所有 POST 请求都放宽，含登录、表单等非上传接口，增加攻击面
• ❌ 错误典型：只在 http 块设了 100m，但 location / 里又没重写，实际走的是默认 1m

配套参数不调，大文件照样中断或 500

client_max_body_size 只管“容不容”，不管“稳不稳”。上传耗时长、数据量大，必须同步调以下三项：

Linux Ai Server

Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。

下载

• client_body_buffer_size：建议设为 512k～1m。太小（如默认 8k）会导致频繁刷盘；太大浪费内存。若设为和 client_max_body_size 相同值，可强制全程走内存（仅适合小流量场景）
• client_body_temp_path：确认路径（默认 /tmp）磁盘空间够、且 Nginx 运行用户（如 www-data 或 nginx）有读写权限，否则会报 open() ... failed (13: Permission denied)
• proxy_read_timeout 和 proxy_send_timeout：建议设为 3600（1 小时）。Nginx 在转发给后端前需完整接收请求体，超时会直接断连，前端看到的是网络失败而非 413

单位、边界值和验证方式要盯紧

单位不区分大小写，但别混用小数和字母，比如 0.5g 合法，500mb 也合法，但 500MB 和 500Mb 容易因拼写疏忽失效。

• client_max_body_size 0 表示禁用检查，生产环境慎用——必须确保后端有校验兜底，否则可能被恶意上传打满磁盘
• 测试不能只靠浏览器点选：用 curl -F "file=@test.zip" http://host/api/upload 发真实 multipart 请求，观察响应码
• 查日志比看页面更准：tail -f /var/log/nginx/error.log 里出现 client intended to send too large body 就说明限制起效了；若出现 Permission denied 或 upstream timed out，说明是配套参数或权限问题

最容易被忽略的是 client_body_temp_path 权限和 proxy_read_timeout 匹配——前者写不了临时文件会静默 500，后者设太短会让大文件传到 99% 时突然断开，前端完全无法捕获原因。