413错误本质是某一层（网关/nginx/api网关/业务框架）主动拒绝过大的请求体，需从前到后逐层对齐限制值：nginx层设client_max_body_size、网关层配对应参数、业务端同步调高框架上传限制且后端值≥nginx值。
413 错误本质是某一层拒绝了过大的请求体，不是前端没传好，而是中间某道关卡“量尺太短”。要真正解决，必须从前到后逐层对齐限制值，不能只改一处。
网关层：最先拦截的位置，最容易被漏掉
Nginx 作为最外层反向代理，默认 client_max_body_size 1M，请求还没进业务服务就被拦下，返回 413 时根本不会带后端响应头。这个值必须在 server 块（推荐）或 http 块中显式设置：
- 单站点调整：在对应 server 块内加 client_max_body_size 100M;
- 多站点统一：在 nginx.conf 的 http 块开头添加同一行
- Azure App Service Linux 用户：需通过 Kudu 修改 /home/site/wwwroot/default，保存即热更新，无需 restart
- 不建议设为 0，生产环境应按业务最大文件上限设定（如 50M、2G）
API 网关层：独立于 Nginx，需单独配置
如果用了 Spring Cloud Gateway、Kong 或 Traefik，它们不走 Nginx 的 client_max_body_size，各自有等效机制：
- Spring Cloud Gateway：在 application.yml 中配 spring.cloud.gateway.httpclient.max-in-memory-size: 50000000
- Traefik v2+：需在路由中间件中设置 maxRequestBodyBytes
- Kong：通过 request-size-limiting 插件启用并设 limit-by
- 这些配置和 Nginx 互不影响，必须同步调大，否则前一层放行，后一层仍报 413
业务服务端：框架级限制必须匹配
即使网关全放开，PHP/Java/Node.js 运行时仍有自己的一套上传阈值，且部分参数需成对设置：
- PHP：同时改 upload_max_filesize = 50M 和 post_max_size = 50M（后者 ≥ 前者）
- Spring Boot：两个配置缺一不可：spring.servlet.multipart.max-file-size=50MB 和 spring.servlet.multipart.max-request-size=50MB（单位必须写 MB，不能写 M）
- Express + multer：初始化时明确 limits：fileSize: 50 * 1024 * 1024
验证哪一层出的问题？看响应头就能定位
别只盯着状态码 413，关键看响应头特征：
- 响应头含 Server: nginx → 是 Nginx 拦截，检查其配置文件与重载状态
- 含 X-Powered-By: Express 或 Spring → 是业务服务拒绝，查对应框架配置
- 含 Server: envoy 或 Server: traefik → 对应网关层未配好
- 用 curl -v 或 HTTPie 发起上传测试，比浏览器更易观察原始响应
