报错是这么冒出来的。上传 20MB 的 PDF 到文件接口返回 413，nginx 错误日志里写着 client intended to send too large body，配置里 client_max_body_size 只有 1m，本地直连服务端口却完全正常。
中间走过弯路，把「请求用 multipart 未压缩，体积比文件大」当成主因，改完现象没变。
真正麻烦的地方在于，几个原因的现象几乎一样。nginx 的 client_max_body_size 还是默认 1m。少数情况下是前面还有一层 API 网关有独立的体积限制。
不容易想到的是，前端 SDK 开了二次分片但后端没实现合并。
定位是哪一层返回的 413
curl -s -o /dev/null -w '%{http_code} %{size_upload}\n' -F "file=@report.pdf" https://api.example.com/v1/files再往下把 nginx 的上限调到接口允许的值
echo 'client_max_body_size 512m;' > /etc/nginx/conf.d/upload.conf && nginx -t && nginx -s reload然后用 curl 复验大文件能过网关
curl -s -o resp.json -w '%{http_code}\n' -F "purpose=batch" -F "file=@report.pdf" https://api.example.com/v1/files等前面都确认过，再在网关层加一条体积超限的告警
python watch_413.py --log /var/log/nginx/error.log --threshold 5 --window 10m这次没动代码，只在配置和运行环境上找原因。
恢复的判定其实很直接。同样 20MB 的文件上传返回 200 并拿到 file id，nginx 错误日志里不再出现 too large body。
这里还有个坑。413 是链路上最靠前的那层挡的，改应用配置没用，先用响应头里的 server 字段判断是哪一层。监控比日志更早给出信号，事后回看经常能提前半小时发现异常。