必须同时修改 client_max_body_size、post_max_size 和 upload_max_filesize 三处参数并重启服务，缺一不可；其中 post_max_size ≥ upload_max_filesize，client_max_body_size ≥ post_max_size，且 nginx 需重载配置、php 需重启。
只改 upload_max_filesize 一定失败，它只是上传限制链条里最浅的一环。
为什么改了 upload_max_filesize 还是报错？
因为 PHP 实际执行上传前会先校验两个值：upload_max_filesize 和 post_max_size。前者管“单个文件”，后者管“整个 POST 请求体（含所有文件 + 表单字段）”。如果 post_max_size 比 upload_max_filesize 小，哪怕只传一个文件，PHP 也会在解析请求头阶段就直接拒绝——根本不会走到文件写入逻辑。
常见错误现象：
– 改完 upload_max_filesize = 512M，但上传 100MB 文件仍失败
– 浏览器 Network 面板看到响应状态是 500 或空白，/www/server/panel/logs/request.log 里出现 POST Content-Length of XXXX bytes exceeds the limit of YYYY bytes
-
post_max_size必须 ≥upload_max_filesize，建议设成相同值（如都设为512M） - 改完后必须重启对应 PHP 版本服务（不是“重载”，是“重启”），否则配置不加载
-
宝塔面板里点“一键修改上传限制”只动
upload_max_filesize，不碰post_max_size，慎用
为什么改了 PHP 参数还是 413 错误？
413 Request Entity Too Large 是 Nginx 在收到 HTTP 请求体时就拦下的，PHP 根本没启动。这意味着你连 PHP 的门都没进到，只调 php.ini 完全无效。
关键点：
– Nginx 默认 client_max_body_size 是 1M
– 该参数必须显式写在站点的 server { } 块内（不能放在 http 或 location 里）
– 它的值应 ≥ 你设的 post_max_size（比如都设为 512M）
- 路径：宝塔 → 网站 → 设置 → 配置文件 → 在
server块开头附近添加client_max_body_size 512m; - 保存后必须点击右上角「重载配置」，不是「重启网站」
- 如果用了反代访问宝塔面板（比如通过域名或 HTTPS），还要单独去那个反代站点的配置里加一遍
client_max_body_size
为什么改完所有参数还是上传中断？
大文件上传过程长、数据量大，中间还有 FastCGI 缓冲、PHP 执行超时、内存不足等隐性关卡。
-
max_execution_time和max_input_time建议同步调大（如设为600），否则上传中途 PHP 主动 kill 进程 -
memory_limit至少是目标文件大小的 1.5 倍（例如传 500MB 文件，设memory_limit = 1024M） - Nginx + PHP-FPM 场景下，
fastcgi_buffer_size和fastcgi_buffers过小会导致 413 或 502；可在站点配置的location ~ \.php$ { }块内加：fastcgi_buffer_size 128k;和fastcgi_buffers 256 16k; - 别忘了宝塔面板自身的上传限制：编辑
/www/server/panel/data/config.json，加或改"upload_max_size": 2048（单位 MB），然后执行bt restart
最容易被忽略的是：Nginx 的 client_max_body_size 和 PHP 的 post_max_size 不匹配，或者改了却没重启服务/没重载配置。链路上任意一环卡住，上传都会静默失败。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
