Nginx在接收请求体阶段主动拦截超限上传，未转发至后端；需根据日志字节数对比默认1MB限制，逐层检查http/server/location中client_max_body_size配置，同步放宽后端及代理链路限制，并排除权限、单位、重载等隐性问题。
看到 client intended to send too large body 这条错误日志，说明 Nginx 在接收请求体（request body）阶段就主动拒绝了上传，根本没把请求发给后端。这不是网络卡顿、后端崩溃或代码 bug，而是 Nginx 的“守门员”按规则拦下了超限文件。
看日志数字，快速判断超了多少
错误行末尾的字节数是关键线索，比如：
- 1797176 bytes → ≈ 1.7 MB
- 7562419 bytes → ≈ 7.2 MB
对比 Nginx 默认限制（1048576 字节 = 1 MB）：只要超过这个数，就是它在拦截。如果报的是 10485760 字节，而你配了 client_max_body_size 10m，说明配置已生效且刚好卡在边界。
改对位置，避免配置被覆盖
client_max_body_size 支持三层作用域，优先级从高到低：
-
location { } —— 比如
location /upload { }，只影响该路径，优先级最高 - server { } —— 只对该域名或 IP 的站点生效
- http { } —— 全局默认值，所有未显式覆盖的地方都继承它
多个地方都写了，以最内层（location）为准；某一层没写，就往上继承。别只改了 http 块，结果上传接口落在 location 里，却被它自己的旧配置覆盖了。
同步调后端，别让 Nginx 成唯一瓶颈
Nginx 放宽了，后端若还卡着，默认照样失败。常见组合需一起调：
-
PHP：改
upload_max_filesize和post_max_size（后者必须 ≥ 前者），还要调max_execution_time防止超时中断 -
FastCGI / PHP-FPM：检查
php_admin_value[upload_max_filesize]等运行时配置是否覆盖了 php.ini -
Java（Tomcat）：确认
maxPostSize（如maxPostSize="104857600"）已设够大 - Node.js（Express/Koa）：检查 body-parser 或 multer 的 limit 配置
别漏掉隐性障碍
重启后仍失败？先排查这些容易被忽略的点：
-
临时目录权限：Nginx 需往
client_body_temp_path（默认在 nginx 安装目录下）写临时文件。报Permission denied就说明磁盘不可写，和大小无关 -
单位写错：写成
client_max_body_size 20;（缺单位）会被当成 20 字节；正确写法是20m或20M -
没重载配置：用
nginx -t验证语法后，必须执行nginx -s reload；用restart可能中断连接，且某些系统会清空临时文件导致上传失败 - 代理链路断层：前端有 CDN、WAF 或多层 Nginx 代理时，每一层都要检查并统一放宽限制，否则卡在中间某一层
