nginx 的 client_max_body_size 决定静态目录上传能否成功，因其在请求体接收阶段即拦截超限请求并返回413，与是否代理无关；必须在对应 location 块中精确配置，并同步调整 client_body_buffer_size、client_body_temp_path 和 client_body_timeout 等参数。
当大文件上传目标是 Nginx 的静态目录（例如直接 PUT 或 POST 到 /uploads/ 这类由 root 或 alias 指向本地磁盘的 location），client_max_body_size 依然起决定性作用——它限制的是整个请求体大小，与后端是否存在、是否代理完全无关。
为什么静态目录上传也要看这个参数？
Nginx 对“上传到静态目录”的处理，本质仍是接收完整的 HTTP 请求体。即使不经过 proxy_pass，只要客户端发来一个带大 body 的请求（如用 curl -F 或表单提交大文件），Nginx 就必须先完整接收并解析该 body，才能判断是否写入磁盘或返回错误。此时若 body 超过 client_max_body_size，Nginx 在读取阶段就直接拒绝，返回 413，根本不会走到文件写入逻辑。
- 静态服务场景下，没有后端应用参与，但 Nginx 自身仍需缓冲或暂存上传数据
- 若请求体含文件内容（multipart/form-data 或 raw binary），Nginx 必须按规则处理其 body，而不限于只转发
- 默认 1MB 不足以支撑常见图片、视频、压缩包等上传，极易触发 413
配置位置必须匹配静态上传路径
不能只在 http 或 server 块设值，而应精准落在负责静态上传的 location 块中。否则可能无效或过度放宽。
- ✅ 正确示例：
location /uploads/ {<br> root /var/www/static;<br> client_max_body_size 200M;<br>} - ❌ 错误做法：仅在
http块设client_max_body_size 200M，但该静态 location 未显式继承或覆盖——实际仍可能沿用默认 1MB（尤其当有嵌套或 include 干扰时） - ⚠️ 注意：若使用
alias，确保路径末尾斜杠与 location 匹配，否则 location 可能未生效，导致配置被忽略
配套参数同样影响静态上传成败
仅调大 client_max_body_size 不够。大 body 上传过程涉及缓冲、超时、临时存储，缺一不可：
-
client_body_buffer_size：建议设为1m。太小（如默认 8k～16k）会导致频繁刷盘；太大则浪费内存。静态上传更依赖高效缓冲 -
client_body_temp_path：确认该路径（如/var/nginx/client_body_temp）存在、空间充足，且 Nginx 工作用户（如www-data）有读写权限。否则上传中途写临时文件失败，返回 500 -
client_body_timeout：建议设为300s或更高。它控制 Nginx 接收请求体过程中两次数据包之间的最大等待时间，慢速上传或弱网环境易超时
验证是否真正生效
不要只看配置 reload 成功，要实测：
- 用
curl -X POST -F "file=@large.zip" http://yourdomain.com/uploads/测试，观察响应状态码和 body - 检查 Nginx error log（如
/var/log/nginx/error.log），搜索413或client intended to send too large body - 确认请求头中
Content-Length确实超过原限制值，且修改后不再报错
