413错误主因是Nginx的client_max_body_size过小（默认1MB），需在http/server/location块中正确配置该值（如2048M），并同步调整PHP等后端限制，最后通过nginx -t和reload生效。
遇到“413 Request Entity Too Large”错误，基本就是 client_max_body_size 设得太小了。它控制 Nginx 接收请求体（比如表单上传的文件）的最大字节数，默认仅 1MB，远不够传视频、安装包等大文件。改对位置、写对格式、同步后端，三步到位。
在哪改：按需选择配置层级
这个参数支持在三个位置设置，作用范围不同，优先级从高到低：
-
location 块内：只影响匹配该路径的请求，例如
location /upload/，适合精细化控制 - server 块内：只对该域名或 IP 的虚拟主机生效，推荐大多数场景使用
- http 块内：全局生效，所有站点共用，适合统一策略或多站点一致要求
注意：Nginx 遵循“就近原则”，如果 server 块里写了值，就忽略 http 块里的；location 里又写了，就覆盖 server 的。
怎么写：单位、空格、大小写不能错
语法简单，但细节极易出错，导致 nginx -t 报错或静默失效：
- 单位必须是 K、M、G（仅大写），
100m或100MB会解析失败 - 数值和单位之间不能有空格，
100 M是非法写法 - 不支持小数和科学计数法，
2.5G或1e9会报错，应写成2500M - 设为
0表示禁用检查（不限制），仅限可信内网或调试环境，生产慎用
正确示例：client_max_body_size 2048M; 或 client_max_body_size 5G;
为什么改了还是 413 或 502？后端限制必须同步
Nginx 只是第一道关卡，PHP、Node.js 等后端服务还有自己的上传限制，必须一并调整：
-
PHP 场景：修改
php.ini中三项：-
upload_max_filesize = 2048M（单个文件上限） -
post_max_size = 2100M（整个 POST 数据上限，需 ≥ upload_max_filesize） -
memory_limit = 2560M（至少比 post_max_size 大，防内存溢出）
-
-
重启要求：改完 Nginx 配置后执行
nginx -s reload；改完 php.ini 后必须重启 PHP 进程（不是只重载 Nginx），否则不生效 -
其他后端：Node.js（如 Express 需配 multer limit）、Java（Spring Boot 配
spring.servlet.multipart.max-file-size）也需对应调整
验证是否真正生效
别只看配置保存了就认为搞定，实测才能确认：
- 用
curl -F "file=@test.zip" http://yoursite.com/upload上传一个略超原限制、略低于新限制的文件 - 查看 Nginx 错误日志：
tail -f /var/log/nginx/error.log，确认无 413 记录 - 运行
nginx -t检查语法，再nginx -s reload重载 - 若用宝塔、phpEnv 等集成环境，注意其特殊路径（如 phpEnv 改
C:\phpEnv\config\nginx\nginx.conf的 http 块）
