413错误是Nginx在请求体进入PHP前拦截所致，需在对应location或server块中配置client_max_body_size（如50M），并同步调低PHP的upload_max_filesize和post_max_size（≤Nginx值），且必须重载Nginx；大文件导入应改用mysql命令行。
413 request entity too large 错误不是 phpmyadmin 的问题，是 nginx 在请求体进入 php 前就直接拒绝了——你连 upload_max_filesize 的门槛都没摸到。
为什么改了 php.ini 还是报 413？
Nginx 默认只允许 1MB 请求体，client_max_body_size 不配置或配错作用域，它根本不会把大文件转发给 PHP。哪怕你把 upload_max_filesize 设成 2G，Nginx 早就在 location 或 server 块外拦下了。
- 必须在 Nginx 配置中对应 phpMyAdmin 的
location块里写，比如location /phpmyadmin { client_max_body_size 50M; } - 如果 phpMyAdmin 是根路径（
http://example.com/），就得放在server块顶层，不能只丢在http块里 - 值别设
0或off——这等于放弃防御，给 DoS 攻击留后门 - 改完必须执行
nginx -t && systemctl reload nginx，否则配置不生效
PHP 层限制为什么也要调，且必须 ≤ Nginx 值？
Nginx 放行之后，PHP 才开始解析 POST 数据。upload_max_filesize 和 post_max_size 这时才起作用，但它们的上限不能超过 Nginx 的 client_max_body_size，否则会出现“Nginx 让进了，PHP 又拒了”的错乱现象。
-
post_max_size必须 ≥upload_max_filesize（推荐设为相等，如都设50M） - 修改的是 phpMyAdmin 实际运行的 PHP 配置：如果是 PHP-FPM，得在 pool 配置里用
php_admin_value[upload_max_filesize]，不是改 CLI 的php.ini - 确认生效路径：访问
phpinfo.php，搜Loaded Configuration File，只改这个文件
为什么选完大文件浏览器就卡死或静默失败？
这不是服务端限制，是前端行为：phpMyAdmin 用原生 <input type="file"> 表单上传，浏览器一读取几百 MB 文件就会占用大量内存和主线程，导致界面冻结、假死，甚至无响应提交。
- 禁用 Web 界面导入是最稳妥解法：用
mysql -u user -p database < file.sql直导 - 若必须走 Web，确保服务器与浏览器时区一致，否则
client_body_timeout（默认 60s）容易中途断连 -
max_execution_time对上传阶段完全无效——它只管 PHP 脚本执行时间，不管文件传输耗时
真正容易被忽略的是作用域和生效链：Nginx 拦截发生在最外层，PHP 配置只在 Nginx 放行后才参与；而浏览器卡死是纯客户端问题，调任何服务端参数都救不了它。三者不在同一层，不能混为一谈。
