看到 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），那可能是后端服务没跟上或超时设置太短