nginx 返回413错误是因client_max_body_size默认仅1mb，需在匹配的location块中设为20m～1g并同步调整proxy_read_timeout等参数。
遇到静态资源上传被拦、返回 413 Request Entity Too Large，问题不在前端或后端代码，而是 Nginx 在请求刚进来时就拒绝了——它默认只允许 1MB 的请求体，而图片、PDF、压缩包动辄几十 MB，必须改它的 client_max_body_size。
关键：配置位置决定是否真正生效
这个参数支持 http、server、location 三级写法，但**最内层匹配的才起作用**。常见错误是只在 http 块加了一行，结果被某个 location 块里的默认值（比如没显式写但继承了更小值）覆盖了。
- 静态资源上传接口通常路径明确，例如
/api/upload、/uploads/、/static/upload，推荐直接在对应location块里设值 - 示例：
location /api/upload {<br> client_max_body_size 200m;<br> proxy_pass http://backend;<br>} - 如果整个站点都走同一套上传逻辑，可放在
server块；但不建议写在http块全局放开，尤其有管理后台或 API 管理路径时，安全风险高
数值设定要匹配业务，不是越大越好
单位支持 k、m、g（大小写不敏感），例如 50m、1g。设为 0 表示不限制，但生产环境不推荐——既浪费内存，也削弱对恶意大包的防护能力。
- 普通图片/文档上传：20m～50m 足够
- 视频、工程包、数据库导出文件：可设 200m～1g
- 注意检查
client_body_temp_path对应磁盘是否有足够空间，且运行 Nginx 的用户（如www-data或nginx）对该路径有读写权限，否则会转为 500 错误而非 413
配套参数必须同步调整
只放大 client_max_body_size 不够。大文件上传耗时长、数据量大，Nginx 内部转发链路上还有几个关键参数需要对齐：
-
proxy_read_timeout和proxy_send_timeout：建议设为3600（1 小时），防止 Nginx 在等待后端响应或发送响应时超时断连 -
client_body_buffer_size：建议设为512k～1m。它控制多少字节以内走内存缓存，超过才写临时磁盘；太小会频繁刷盘拖慢速度，太大则占用过多内存 - 若用了
proxy_pass，后端服务自身限制也要同步放宽，比如 Spring Boot 的max-file-size、PHP 的upload_max_filesize，且后端值必须 ≥ Nginx 设置值
快速确认是不是 Nginx 拦的
别急着改配置，先定位源头：
- 看响应头里有没有
Server: nginx，状态码是不是 413 - 查后端日志——如果完全没记录这次请求，基本就是 Nginx 在入口拦下了
- 用命令
nginx -T | grep client_max_body_size查所有已加载配置中该指令的实际值和所在位置，避免“以为改了，其实没生效”
