nginx主动拦截超限请求体返回413，排查重点是确认限制层级、是否生效及被覆盖，并结合error.log中“client intended to send too large body”字节数判断真实超限值，同步校验后端与代理层限制。
这个错误不是日志“捕获”问题，而是 Nginx 主动拦截超限请求体后返回 413 的结果。排查重点是确认限制在哪、是否生效、是否被覆盖，以及是否真被业务需要——而不是去改 error_log 格式或级别。
看日志末尾字节数，快速判断是否真超限
错误行固定带具体字节数，例如：
client intended to send too large body: 7562419 bytes
- 换算成 MB：7562419 ÷ 1048576 ≈ 7.21 MB → 明显超过默认 1 MB 限制
- 若你已配了
client_max_body_size 20m，却报20971520 bytes（刚好 20 MB），说明配置已起效，只是上传文件略超 - 若业务只允许 5 MB，却频繁出现 50 MB、200 MB 请求，大概率是恶意试探，不是配置失误
查配置位置和优先级，避免被覆盖
client_max_body_size 作用域有明确优先级：location > server > http。常见失败原因是“写了但没生效”：
- 检查实际请求匹配的
location块（如location /api/upload { ... }）是否显式设置了该指令 - 别只看
http{}里写了 100m，可能server{}或某个location{}里写了1m，直接覆盖 - 单位必须写全：写成
50是 50 字节，要写50m或50M
验证配置是否真正生效
不能只靠 nginx -t 语法检查，必须实测+观察日志：
- 执行
nginx -s reload（不是 restart），确保新配置加载 - 用
curl -X POST -F "file=@large.zip" http://your.com/upload模拟上传 - 实时运行
tail -f /var/log/nginx/error.log，确认该错误不再出现 - 再查后端 access.log 或业务日志，确认请求已抵达并开始处理——否则可能是后端（PHP/Tomcat/Node）自己又拦了一道
同步检查关联项，防止连锁报错
调大 body 限制后，常冒出新问题，需一并排查：
-
临时目录权限：Nginx 需往
client_body_temp_path写缓冲文件，若目录不可写，会报Permission denied，和大小无关 -
后端限制未同步：PHP 要调
upload_max_filesize和post_max_size；Tomcat 要调maxHttpPostSize；Node.js 框架也有各自限制 -
代理超时过短：大文件上传耗时长，
proxy_read_timeout默认 60 秒，容易触发upstream timed out
