nginx 报“client intended to send too large body”错误是因 client_max_body_size 限制触发413响应，需在 location/server/http 块中正确配置带单位的值（如100m），并重载配置、同步调整后端限制及检查临时目录权限。
看到 client intended to send too large body 错误，说明 Nginx 在接收请求体时主动拦截了超限数据，并未转发给后端——这不是日志“捕捉”问题，而是配置限制触发的 413 响应。解决核心是调大限制并确保生效，而非调整错误日志本身。
确认错误来源就是 client_max_body_size 限制
该错误固定格式为：client intended to send too large body: XXX bytes，末尾字节数很关键：
- 换算成 MB：用数值 ÷ 1048576（即 1024²），例如 2274148 ÷ 1048576 ≈ 2.17 MB
- 只要超过 1048576 字节（1 MB），就说明触发了 Nginx 默认限制
- 若你已配了 20m 却报 20971520 字节（刚好 20 MB），说明配置已起效，只是上传文件略超
正确设置 client_max_body_size 配置位置
该指令作用域有优先级，必须逐层检查，以最内层为准：
-
location 块（如
location /upload { }）：优先级最高，建议在此处设值，精准控制上传路径 - server 块：对该域名或 IP 下所有路径生效，适合统一上传服务
- http 块：全局生效，影响所有虚拟主机，慎用，避免过度放宽
示例（推荐写在 location 中）：
location /api/file/upload {client_max_body_size 100m;
}
避开常见配置陷阱
改完常仍失败？重点排查这些隐性问题：
-
单位漏写：写成
client_max_body_size 50;是 50 字节，必须带单位，如50m或50M -
未重载配置：运行
nginx -t验证语法后，必须执行nginx -s reload，不是 restart -
后端未同步放宽：Nginx 放行后，Tomcat、PHP（
upload_max_filesize/post_max_size）、Node.js 等仍可能拒绝，需一并检查 -
临时目录不可写：Nginx 需往
client_body_temp_path写缓冲文件，权限不足会报Permission denied，和大小无关
验证是否真正修复成功
别只测一次上传成功就结束，要分层确认：
- 用 curl 模拟真实上传：
curl -X POST -F "file=@test.zip" http://your.com/api/upload - 实时观察
/var/log/nginx/error.log，确认不再出现该错误行 - 查看后端 access.log 或业务日志，确认请求已完整抵达并开始处理
- 留意是否冒出新错误，比如
upstream timed out，那可能是 proxy_read_timeout 太短，需同步调大
