413 是什么
413 Content Too Large 表示请求体超过了服务器允许的大小上限，服务器直接拒收。它绝大多数时候是配置问题而非程序缺陷：Nginx 默认 client_max_body_size 只有 1m，文件上传、批量导入、大 JSON 提交是最容易撞上的三类场景。规范里这个码原名 Payload Too Large，RFC 9110 起改用现名。
基本信息
| 语义 | 请求体超出服务器接受上限 |
|---|---|
| 规范 | RFC 9110 §15.5.14 |
| 常见限制层 | Nginx client_max_body_size、Apache LimitRequestBody、Tomcat maxPostSize、Spring max-http-request-size |
| 典型触发 | 文件上传、批量接口、富文本与图片 Base64 提交 |
| 排查入口 | 先看响应头是哪个 Server，再逐层核对阈值 |
Nginx 调整上传上限
Nginx 调整上传上限
server {
client_max_body_size 100m; # 默认 1m，上传接口常需上调
client_body_timeout 60s; # 大文件上传要同步放宽读超时
proxy_read_timeout 300s; # 反代到后端时后端处理大文件更慢
}
# 改完先校验语法再平滑重载
# nginx -t && nginx -s reload逐层核对清单
| 所在层 | 参数或表现 | 注意点 |
|---|---|---|
| 反向代理/网关 | client_max_body_size | 默认 1m，最容易漏的一层 |
| 应用框架 | Tomcat maxPostSize、Spring max-http-request-size | 框架层拒绝常被统一记成 500 |
| CDN/WAF | 请求体上限、单请求超时 | 413 可能来自边缘节点，源站日志里什么都没有 |
| 对象存储直传 | 用预签名 URL 绕过业务服务器 | 大文件首选方案，可以从根上避开 413 |
上调上限前先评估内存与磁盘压力：请求体在落盘缓冲前会占用内存，盲目调到几百兆，并发上传时容易把服务器拖到 OOM。
排查顺序
- 先用 curl -v 看响应头的 Server 字段，判断 413 是哪一层返回的
- 对比直连源站与经过 CDN 的结果，快速锁定是否边缘节点拦截
- 翻 Nginx error.log 里的 client intended to send too large body 记录
- 核对后端框架的上传上限参数，框架层拒绝常被包装成 500
- 确认真实请求体大小，multipart 边界与编码膨胀会让实际体积大于原始文件
根治方案
- 大文件改走对象存储预签名直传，业务服务器只接收元数据，从根上避开限制
- 批量接口改为服务端拉取或分片提交，避免单请求承载海量数据
- 把网关、框架、CDN 三处的阈值统一登记在配置清单里，改动时同步
- 在接口文档里写明体积上限与超限返回码，让调用方提前分片