核心是用client_max_body_size在请求体解析前拦截超限请求，必须设在匹配上传路径的location块中（如location /api/upload { client_max_body_size 200m; }），并同步调整client_body_buffer_size、client_body_temp_path权限、proxy_read_timeout等配套参数，避免降级为500错误或安全风险。
限制客户端单次上传的最大报文体积，核心是用 client_max_body_size 在请求体解析前就拦截超限请求，避免内存或磁盘资源被恶意耗尽——它不是“优化上传体验”的配置，而是第一道安全防线。
必须设在匹配路径的 location 块中
很多人把 client_max_body_size 放在 http 或 server 块里，结果上传接口仍返回 413。根本原因是 Nginx 的配置继承优先级为：location > server > http。如果你的上传接口是 /api/upload，就必须在对应 location 中显式设置：
location /api/upload { client_max_body_size 200M; proxy_pass http://backend; }- 避免在
server块全局放宽——会把登录、表单等非上传接口也暴露给大载荷攻击 - 不推荐设为 0（禁用检查），等于主动关闭防护入口
配合 client_body_buffer_size 控制内存缓冲策略
这个参数不决定“能不能传”，而决定“怎么存”。默认 8KB～16KB，对防溢出很关键：
- 设得太小（如 1KB）：大文件上传会频繁写临时文件，增加磁盘 IO 和权限风险
- 设得太大（如等于
client_max_body_size）：可能让单个请求吃光 worker 进程内存 - 建议值：512KB～1MB，平衡内存占用与 IO 频次；若业务并发低且文件稳定 ≤100MB，可设为 1M
补全配套项，防止拦得住但传不过
只设大小限制还不够，Nginx 在读取 body 过程中还会触发临时文件写入、超时中断等行为，漏一项就可能失败或降级为 500 错误：
-
client_body_temp_path /var/tmp/nginx/client_body 1 2;：确认该路径磁盘空间充足，且 Nginx 运行用户（如www-data）有读写权限 -
client_body_timeout 60s;：防止慢速上传长期占用连接，建议设为略高于后端处理预期耗时 - 若用了反向代理（如
proxy_pass），还需同步检查proxy_max_temp_file_size和proxy_read_timeout
验证是否生效，别只 reload
改完配置后，常见误区是只执行 nginx -s reload，但旧 worker 进程可能缓存旧配置。尤其遇到“明明写了却还报 413”时：
- 先运行
nginx -t确认语法无误 - 再执行
sudo systemctl restart nginx（而非 reload），确保新进程完全加载 - 用 curl 发送一个略超限的 POST 请求（如 201M 文件），观察是否直接返回 413，且不进后端、不生成临时文件
