结论是MySQL主动断连，主因是max_allowed_packet过小或wait_timeout过短；需同步查清服务端全局值、当前会话值及超时参数，并配平PHP上传限制、phpMyAdmin执行时限和Nginx请求体限制。
直接说结论：这不是网络断了，而是 mysql 主动踢掉了连接——大概率是 max_allowed_packet 太小或 wait_timeout 过短，两者常一起发作。
查清三个关键参数实际值
别只改配置文件，必须进 MySQL 确认当前生效值：
-
SELECT @@global.max_allowed_packet;—— 服务端全局上限 -
SELECT @@session.max_allowed_packet;—— 当前 phpMyAdmin 连接实际用的值（可能被会话 SET 覆盖，常比全局小） -
SHOW VARIABLES LIKE '%timeout%';—— 重点看wait_timeout和interactive_timeout，低于 1800（30 分钟）就危险
如果 @@session.max_allowed_packet 明显小于全局值，说明 PHP 客户端建连时被强制压低了，光调 my.cnf 没用。
PHP 层 upload_max_filesize 和 post_max_size 必须配对调
这两个参数像双保险，缺一不可：
-
upload_max_filesize控制单文件上传上限 -
post_max_size控制整个 POST 请求体大小，必须 ≥upload_max_filesize，否则请求在 PHP 解析前就被静默截断，现象是页面空白或“连接重置” - 宝塔用户特别注意：改的是 PHP-FPM 对应的
php.ini，不是 CLI 版；还得在 Nginx 配置里加client_max_body_size，否则请求根本到不了 PHP
phpMyAdmin 自己的执行时限不能忽略
它不认 PHP 的 max_execution_time，自己有一套计时器：
立即学习“PHP免费学习笔记（深入）”；
- 默认
$cfg['ExecTimeLimit'] = 300（5 分钟），超时直接弹窗报错，和 MySQL 无关 - 修改
config.inc.php，在$cfg['blowfish_secret']后加：$cfg['ExecTimeLimit'] = 0;（禁用） - 改完不用重启 Apache，但必须清浏览器缓存或换无痕窗口，否则旧 JS 缓存还在跑计时
SQL 文件开头有 BOM 或含 SET time_zone 语句也触发断连
这两类问题不报明确错误，但会导致后续语句解析错位，间接让某条 INSERT 实际超长，撞上 max_allowed_packet：
- 用 VS Code 或 Notepad++ 检查 SQL 文件是否为 UTF-8 无 BOM 编码
- 导入失败时留意是否卡在
SET time_zone = "+00:00"，报错#1298—— 这其实是时区表缺失，但 phpMyAdmin 未捕获异常，直接中断请求流，表现就是“服务器断开” - 临时解决：手动删掉 SQL 文件开头的
SET time_zone行；长期方案是运行mysql_tzinfo_to_sql补全时区表
真正麻烦的不是单点参数，而是 MySQL 包大小、PHP 上传限制、phpMyAdmin 执行计时、Nginx 请求体拦截这四层限制叠在一起，漏调任何一层都白忙活。
