配置Nginx client_max_body_size 50M后仍出现413 Request Entity Too Large错误问询

你的请求负载实际只有约2MB，远低于配置的50MB阈值，且生产环境配置运行正常，问题大概率出在开发环境的配置未生效或请求链路存在其他限制层，常见原因如下：

• Nginx配置优先级覆盖：你配置的client_max_body_size仅在http块生效，但server块、location块下可能存在更小的限制数值，后者优先级更高会覆盖全局配置
• Elastic Beanstalk配置未生效：如果你使用的是Amazon Linux 2版本的EB平台，旧版.ebextensions中直接写入/etc/nginx/conf.d的配置方式已不生效，需放到.platform/nginx/conf.d/路径下才会被正确加载；也可能是部署过程中配置写入失败、Nginx未重启加载新配置
• 链路中间层限制：开发环境的请求链路中存在其他反向代理、WAF、负载均衡（比如AWS ALB、本地代理工具），这些中间层的请求大小阈值设置小于2MB，提前返回了413错误
• 后端应用限制：后端应用服务本身配置的请求大小阈值低于2MB，返回413后被Nginx透传返回

1. 验证Nginx实际加载的配置
   登录开发环境的EC2实例，执行命令nginx -T打印所有生效的配置，全局搜索client_max_body_size，确认是否存在小于50M的配置项，以及你写的50M配置是否被正常加载。如果未找到你配置的50M项，查看EB部署日志排查配置写入失败的原因。
2. 查看Nginx错误日志
   打开路径/var/log/nginx/error.log，查找对应413请求的日志：

• 如果存在client intended to send too large body的报错，说明限制确实来自当前Nginx，回到第一步确认配置即可
• 如果无对应报错，说明413是上游服务或中间层返回的

3. 核对请求链路差异
   对比开发和生产环境的请求链路，确认开发环境是否多了额外的代理、WAF、CDN等中间组件，逐一排查这些组件的请求大小限制配置。
4. 排查后端应用配置
   检查你部署的后端服务的请求大小限制参数，比如PHP的post_max_size、Python Django的DATA_UPLOAD_MAX_MEMORY_SIZE、Java Spring的spring.servlet.multipart.max-request-size等。

• 若为EB配置不生效：Amazon Linux 2版本的EB平台要求Nginx自定义配置放在项目根目录的.platform/nginx/conf.d/路径下，重新打包部署即可生效
• 若为配置优先级覆盖：在对应的server块或location块下添加client_max_body_size 50M;，执行nginx -s reload重载配置即可
• 若为中间层/后端限制：调整对应组件的请求大小阈值即可

内容的提问来源于stack exchange，提问作者Lianel