需将 nginx 的 client_max_body_size 设为至少 30m，并在 http 块全局设置、上传接口 location 块精准覆盖，同时调优 client_header_timeout、client_body_timeout 等超时参数及后端框架文件大小限制，最后通过 curl 实测和日志验证。
要避免大宗商品图片上传时返回 413 Request Entity Too Large 错误，核心是确保 Nginx 的 client_max_body_size 值 ≥ 实际上传文件的最大体积，并覆盖所有可能的请求路径。
确认实际图片大小上限
大宗商品图（如仓单扫描件、质检报告、实物拍摄图）常含高分辨率 PDF、TIFF 或压缩不佳的 PNG/JPG。需统计业务中真实上传文件的 P95 体积——例如内部数据显示，带印章和多页的 PDF 仓单平均 8–12 MB，个别可达 25 MB。建议以 30 MB 为安全阈值，预留增长余量。
在正确作用域设置 client_max_body_size
该指令必须出现在能匹配上传接口的配置块中，常见错误是只写在 http 块却忽略 server 或 location 的覆盖。推荐分层设置：
-
全局兜底：在
http块设client_max_body_size 30M; -
接口精准控制：在上传路径 location 中显式声明，例如：
location /api/v1/upload/image {<br> client_max_body_size 30M;<br> proxy_pass http://backend;<br>} -
避免被子配置覆盖：检查是否有嵌套的
location ~ \.php$或正则匹配块无意重置了该值
同步调优关联参数
仅改 client_max_body_size 不足，还需配套调整：
-
client_header_timeout 60;和client_body_timeout 300;：防止大文件上传中途因超时断连 -
fastcgi_read_timeout 300;（若走 PHP-FPM）或proxy_read_timeout 300;（若反向代理）：确保后端处理时间不被 Nginx 中断 - 确认后端框架限制（如 Spring Boot 的
spring.servlet.multipart.max-file-size、Django 的DATA_UPLOAD_MAX_MEMORY_SIZE）也同步放宽，否则 Nginx 通过后仍会 400/500
验证与观测手段
上线后必须实测+日志交叉验证：
- 用
curl -X POST -F "file=@large.jpg" https://api.example.com/upload上传接近 30 MB 的文件，观察响应码与耗时 - 检查 Nginx error log 是否仍有
client intended to send too large body记录 - 在 access log 中加入
$request_length变量，监控真实请求体大小分布
