Nginx 返回413错误表明请求在代理前已被拦截，需通过error.log字节数换算文件大小、access.log匹配URI定位上传路径，并检查对应location块中client_max_body_size配置优先级。
看到 client intended to send too large body 错误，说明 Nginx 在接收阶段就拒绝了请求，返回 413 状态码，根本没把请求发给后端。这不是后端问题，而是上传路径被 Nginx 主动拦截了——关键在于从日志里快速反推这个“被拦在哪条路”。
看错误行末尾字节数，估算文件实际大小
日志中这串数字（如 7562419 bytes）是核心线索：
- 除以 1048576（即 1024²），换算成 MB：7562419 ÷ 1048576 ≈ 7.2 MB
- 若结果明显大于 1 MB（Nginx 默认限制），说明触发了限制；若接近你配置的值（比如报 20971520 字节，而你配了 20m），说明该配置已生效，且上传路径确实走到了这里
- 这个数值不是“后端报的”，而是 Nginx 自己读到一半就断掉时记录的已接收量，能反映客户端真实发送意图
结合 $request 和 $uri 匹配上传入口路径
Nginx error.log 本身不记录 URI，但你可以同步打开 access.log 并按时间戳比对：
- 找到 error.log 中出错那行的时间（如 2026/06/19 12:01:44）
- 在 access.log 里搜索同一秒或前后 1 秒内的请求，重点关注状态码为 413 的条目，例如：
192.168.1.100 - - [19/Jun/2026:12:01:44 +0800] "POST /api/v1/upload HTTP/1.1" 413 154 "-" "curl/7.68.0" - 这样就能直接锁定触发点是 /api/v1/upload 这类具体路径，而非笼统说“整个网站”
检查对应 location 块是否独立设限
上传路径往往落在特定 location 中（如 location /upload { ... } 或 location ~ \.(php|cgi)$），而 client_max_body_size 在 location 块中的优先级最高：
- 即使 http 或 server 块配了 100m，只要该 location 块里写了
client_max_body_size 1m;，上传就会在这里被卡住 - 用
nginx -T | grep -A 5 -B 5 "location.*upload\|location.*\.php"快速筛出相关配置段 - 重点看 location 内有没有显式设置、注释掉、或继承了更小的值
用 curl 复现并验证路径与限制关系
不靠猜，直接构造请求确认：
- 执行：
curl -X POST -F "file=@test_8M.zip" https://yoursite.com/api/v1/upload -i - 观察响应头是否含
Status: 413 Request Entity Too Large，同时 tail -f error.log 看是否打出对应字节数日志 - 再试一个非上传路径（如
/health）传同样文件，应无 413 —— 这能反向证明限制只作用于特定 location
