413错误是Nginx在请求进入PHP前硬拦截所致，必须同步修改Nginx的client_max_body_size（置于server或location块）、PHP的upload_max_filesize和post_max_size（后者≥前者），并重载Nginx与PHP配置。
为什么phpMyAdmin导入大文件会报413？
因为nginx在请求刚进入时就拦截了超限的请求体，根本没传到php或phpmyadmin——所以改config.inc.php或前端js毫无作用。这个错误本质是web服务器层的“硬拦截”，不是应用层能绕过的。
必须同步调整的三个配置位置
漏掉任意一个都会失败，且顺序不能错：
-
php.ini里调大upload_max_filesize和post_max_size（注意：post_max_size必须 ≥upload_max_filesize，否则上传直接被PHP丢弃） - Nginx配置中，在
server块或更精准的location /phpmyadmin块内加client_max_body_size 200M（别只写在http块，容易被子块覆盖） - 如果用了宝塔面板，记得在PHP服务管理页点“重载配置”，再在Nginx管理页点“重载配置”——只重启PHP-FPM不生效
常见踩坑点：数值单位、生效范围与验证方式
很多人改完配置仍失败，问题往往出在细节：
- 单位写成
200MB（大写B）会报语法错误，必须用200M或209715200（字节） - 宝塔面板下，PHP配置修改后要确认是否编辑的是当前站点所用PHP版本的
php.ini（比如PHP 8.2和7.4的配置文件是分开的） - 验证是否真由Nginx触发：curl -I http://你的域名/phpmyadmin/ —— 如果响应头含
Server: nginx且状态码是413，说明还没进PHP；如果看到500或空白页，才是PHP层问题
导入超大SQL文件的替代方案
当文件超过500MB或频繁遇到超时，硬调参数反而增加风险：
- 用命令行导入：
mysql -u 用户名 -p 数据库名 （跳过Web层所有限制） - 拆分SQL文件：用
split -b 100M xxx.sql part_切片，再逐个在phpMyAdmin里导入 - 临时禁用
client_max_body_size不是好主意——设为0等于敞开大门，生产环境慎用
真正卡住人的从来不是改哪几行配置，而是搞不清哪一层先拦下了请求。先用curl -I看响应头，再查日志，比盲目改配置快得多。
立即学习“PHP免费学习笔记（深入）”；
