413错误本质是请求体超过任一中间件限制而被拦截；微服务链路中需在客户端→网关（Nginx/Envoy）→微服务网关（如Spring Cloud Gateway）→业务服务（PHP/Spring Boot/Node.js）各层同步配置body大小限制，且Nginx默认1MB限制最易被忽略，须优先调整并确认生效。
413 错误本质是请求体过大被中间件拦截，微服务场景下难点不在“怎么配”，而在于“在哪配、配几处、谁生效”。因为请求路径常为：客户端 → 网关（Nginx/Envoy）→ 微服务网关（如 Spring Cloud Gateway）→ 具体业务服务（如 Spring Boot 或 PHP），每一层都可能独立校验 body 大小。
网关层的 client_max_body_size 容易被忽略
很多团队只改了业务服务的配置，却忘了最外层反向代理。Nginx 默认值是 1MB，且该限制在请求进入任何后端前就触发，返回 413 后根本不会转发到下游。尤其在 Azure App Service Linux 环境中，平台内置 Nginx，必须通过 Kudu 手动复制并修改 /home/site/wwwroot/default 配置文件，在 http 或 server 块内添加：
-
client_max_body_size 50M;（建议设为具体业务最大文件上限，不建议直接设 0） - 修改后需确认 Nginx 重载生效——App Service 中无需手动 restart，保存配置即自动热更新
微服务网关自身也有上传限制
如果用了 Spring Cloud Gateway 或 Kong、Traefik 等 API 网关，它们不依赖 Nginx，但有自己的 body 大小策略：
- Spring Cloud Gateway 默认限制约 5MB，需在
application.yml中显式配置：spring:<br> cloud:<br> gateway:<br> httpclient:<br> max-in-memory-size: 50000000
- Traefik v2+ 需在路由器中间件中设置
maxRequestBodyBytes - 这些配置和 Nginx 的
client_max_body_size互不影响，必须同步调整
业务服务端的限制要分框架对齐
即使前面两层都放开，PHP、Java、Node.js 各自还有运行时级限制，必须匹配网关值：
- PHP：同时检查
upload_max_filesize和post_max_size（后者需 ≥ 前者），单位统一用M，例如upload_max_filesize = 50M - Spring Boot：
spring.servlet.multipart.max-file-size=50MB与max-request-size=50MB必须都设，且不能写成50M（仅支持 MB/KB/B） - Express（Node.js）：需用
multer显式指定limits: { fileSize: 50 * 1024 * 1024 }
调试时注意错误来源定位
不能只看返回状态码，要确认是哪一层抛出的 413：
- 响应头含
Server: nginx→ 是 Nginx 拦截，查其配置 - 响应头含
X-Powered-By: Express或Spring→ 是业务服务拒绝，查对应框架配置 - 响应体是网关默认页面（如 “Request Entity Too Large” 但无 Server 标识）→ 查网关自身限制
- 使用
curl -v或浏览器 Network 面板查看完整响应头，比日志更直接
