HTTP 413错误是Nginx在入口拦截导致的，因其默认client_max_body_size仅1MB，超出即直接返回错误且不触达后端；需在location/server/http块中配置该参数（推荐location级），并同步调整proxy_read_timeout、client_body_buffer_size等配套参数，且须执行nginx -t && nginx -s reload生效。

413 错误不是后端没收到请求，而是 Nginx 在入口就拦下了——默认只允许 1MB 请求体，超了直接返回错误，连后端日志都不会有。关键不在“怎么写”，而在“在哪写、写几处、谁真正起作用”。

必须改 Nginx 的 client_max_body_size

Nginx 是第一道关卡，它不看后端配得多大，只认自己配置的值。默认 1MB 远不够传图片、视频或压缩包。

• 单位支持 m（MB）、g（GB），大小写不敏感，例如 client_max_body_size 100m;
• 设为 0 表示不限制（仅限可信内网或调试环境）
• 生效位置优先级：location > server > http，推荐在上传路径的 location 块里单独设，比如：
  location /api/upload { client_max_body_size 500m; }
• 改完必须执行 nginx -t && nginx -s reload，否则不生效

配套参数也得同步调

光放大 body 大小还不够。大文件上传慢、数据量大，Nginx 内部处理机制也要适配：

• proxy_read_timeout 和 proxy_send_timeout 建议设为 3600（1 小时），防转发中途超时断连
• client_body_buffer_size 建议设为 512k～1m，控制内存缓存阈值，太小易刷盘，太大浪费资源
• client_body_temp_path 要确认磁盘空间够、Nginx 用户有读写权限，否则会报 500 而非 413

微服务链路中每层都得检查

请求从客户端进来，可能经过：Nginx → API 网关（如 Spring Cloud Gateway）→ 业务服务（如 Spring Boot/PHP/Node.js）。每一层都可能独立拦截：

• Nginx 层：已说明，最常被忽略
• API 网关层：Spring Cloud Gateway 默认约 5MB，需配 spring.cloud.gateway.httpclient.max-in-memory-size；Traefik 需设 maxRequestBodyBytes
• 业务服务层：
  • Spring Boot：两个都要设——spring.servlet.multipart.max-file-size=50MB 和 max-request-size=50MB（注意单位只能是 MB/KB/B，不能写 50M）
  • PHP：upload_max_filesize 和 post_max_size 都要调，且后者 ≥ 前者，单位统一用 M
  • Node.js（Express）：用 express.json({ limit: '50mb' }) 和 express.urlencoded({ limit: '50mb', extended: true })，multer 还要额外设 limits.fileSize

怎么确认到底哪一层拦的？

别只看状态码。413 可能来自任意一层，定位靠细节：

• 响应头含 Server: nginx，且后端无对应请求日志 → 基本是 Nginx 拦的
• 响应头是 Server: envoy 或 Server: cloudflare → 查对应代理层配置
• 后端有日志但报错是“request too large”类提示 → 查该服务框架的上传限制
• 用 nginx -T | grep client_max_body_size 查所有生效配置，避免被低优先级设置覆盖