要让Nginx正确支持超大文件上传，必须在匹配路径的location块中配置client_max_body_size，并同步调优client_body_buffer_size、client_body_temp_path、proxy_read_timeout等参数，且需检查后端服务限制。
要让 Nginx 正确支持超大文件上传，不能只改 client_max_body_size 这一个参数。413 错误只是表层现象，背后往往是缓冲、权限、超时等环节连环失效。关键是要在匹配上传路径的 location 块中精准配置，并同步调优配套参数。
必须写在 location 块里才真正生效
Nginx 的配置优先级是 location > server > http。如果你的上传接口地址是 /upload 或 /api/file，就必须在对应的 location 块里显式设置：
location /upload { client_max_body_size 500m; }location /api/file { client_max_body_size 2g; proxy_pass http://backend; }- 避免只在
http或server块设——那样会让所有 POST 请求（包括登录、表单）都放宽限制，扩大攻击面 - 单位注意大小写兼容性：用
500m或2g，别写成500Mb或2GB，否则可能被忽略
配套参数必须一起调优
client_max_body_size 只决定“让不让进”，不保证“稳不稳传”。以下三项缺一不可：
-
client_body_buffer_size 1m;：建议设为 512k～1m。太小（如默认 8k）会频繁刷盘；太大（比如设成 500m）会吃光内存 -
client_body_temp_path /var/tmp/nginx_client_body 1 2;：确认该路径磁盘空间充足，且 Nginx 运行用户（如www-data或nginx）有读写权限。否则日志会出现Permission denied -
proxy_read_timeout 3600;和proxy_send_timeout 3600;：Nginx 需完整接收请求体再转发给后端，超时就断连，前端看到的是网络错误而非 413
验证是否真生效，别信浏览器点选
前端 JS 校验、缓存或网络抖动容易干扰判断。真实验证要用命令行发原始 multipart 请求：
- 执行：
curl -F "file=@large.zip" http://your-domain.com/upload - 观察返回码：200 表示成功，413 表示限制仍起作用
- 实时查看错误日志：
tail -f /var/log/nginx/error.log - 出现
client intended to send too large body→ 限制已生效 - 出现
Permission denied或upstream timed out→ 是权限或超时问题
后端服务也得同步检查
如果后端是 PHP，Nginx 放行后还会卡在 PHP 层：
-
upload_max_filesize和post_max_size必须 ≥ Nginx 的client_max_body_size -
max_execution_time和max_input_time要足够长，避免脚本超时中断 - 如果是 Java 或 Node.js 后端，也要检查对应框架的请求体大小限制（如 Spring 的
spring.servlet.multipart.max-file-size）
