看到 client intended to send too large body 错误，说明 Nginx 主动拦截了超限请求体（默认1MB），未转发至后端；需检查 client_max_body_size 配置位置与值，并同步放宽后端限制。
看到 client intended to send too large body 这条错误日志，基本可以锁定问题出在 Nginx 对请求体（request body）的大小限制上，而不是后端应用或网络本身。它本质是 Nginx 在接收客户端数据时主动拦截并拒绝，根本没把请求转发出去——所以后端日志里往往一片空白。
看日志数值，快速判断超限程度
错误行末尾的字节数（如 1797176 bytes、7562419 bytes）非常关键：
- 换算成 MB：除以 1024²（约 1048576），比如 7562419 ÷ 1048576 ≈ 7.2 MB
- 对比 Nginx 默认值（1 MB）：只要超过 1048576 字节，就说明触发了默认限制
- 如果数值接近你已配置的
client_max_body_size（比如配了 10M 却报 10485760 字节），说明限制生效且刚好卡在边界
查配置位置，确认实际生效范围
client_max_body_size 的作用域有优先级，必须逐层检查：
- 先查
http{ }块：全局设置，影响所有 server - 再查对应
server{ }块：只对该域名或 IP 的服务生效 - 最后查具体
location{ }块（尤其是上传路径如/upload或/api/file）：优先级最高，可能覆盖上级配置 - 注意：多个地方都配了，以最内层（location）为准；如果某一层没配，就继承上一层
排除常见“假修复”陷阱
改完配置重启后仍失败？别急着怀疑后端，先检查这些隐性瓶颈：
-
权限问题：Nginx 需要往
client_body_temp目录写临时文件。若报Permission denied，说明磁盘路径不可写，和大小无关 -
代理链路不一致：Nginx 配了 100M，但后端 Tomcat/PHP/FastCGI 自己也有上传限制（如 PHP 的
upload_max_filesize和post_max_size），必须同步放宽 -
单位写错：写成
client_max_body_size 20;（缺单位）会被当成 20 字节；正确写法是20m或20M -
未重载配置：用
nginx -t验证语法后，必须执行nginx -s reload（不是 restart），否则修改不生效
验证是否真正打通
改完配置后，不要只测一次成功就收工：
- 用 curl 模拟大文件上传：
curl -X POST -F "file=@large.zip" http://your-domain.com/upload - 同时监控 Nginx error.log，确认不再出现该错误
- 检查后端 access.log 或业务日志，确认请求已完整抵达并处理
- 留意是否出现新错误（如
Connection refused或upstream timed out），那可能是后端服务没跟上或超时设置太短
