phpMyAdmin不控制MySQL超时参数，真正需调的是MySQL的net_read_timeout、PHP的mysqli_options读写超时及Nginx等反代的对应超时值，三者须对齐且取最大合理值。
phpMyAdmin本身不控制MySQL连接超时和keepalive
这是最容易误解的一点：phpMyAdmin只是前端界面，它不直接设置 MySQL 的 connect_timeout、net_read_timeout 或 TCP keepalive 参数。这些全由后端 MySQL 服务端配置、PHP MySQL 扩展行为、以及网络中间件（如 Nginx、云防火墙）共同决定。
你看到的“连接超时”报错，90% 是 MySQL 服务端主动断连，而非 phpMyAdmin 卡住。所以别在 config.inc.php 里找类似 $cfg['ConnectTimeout'] 这种不存在的选项。
真正要调的是 MySQL 服务端的 net_read_timeout（尤其跨境/高延迟场景）
当 phpMyAdmin 执行一个大查询或导出操作时，建连成功后卡在读取响应阶段——这时起作用的是 net_read_timeout，默认仅 30 秒。跨境链路抖动、大结果集传输慢，极易触发它，报错表现为：
MySQL said: Lost connection to MySQL server during query
立即学习“PHP免费学习笔记（深入）”；
- 登录 MySQL 后执行：
SHOW VARIABLES LIKE 'net_read_timeout'; - 临时生效：运行
SET GLOBAL net_read_timeout = 180;（需 SUPER 权限） - 永久生效：在 MySQL 配置文件（如
/etc/mysql/my.cnf）的[mysqld]段下加：net_read_timeout = 180 - 注意：
connect_timeout只管建连阶段，一般不用调太高；wait_timeout和interactive_timeout是空闲超时，跟传输过程无关
PHP 层需同步调整 mysqli 连接行为（非 phpMyAdmin 配置）
PHP 的 mysqli 扩展在建立连接后，默认不启用 TCP keepalive，一旦中间 NAT 网关（如阿里云 SLB、AWS ALB）静默回收空闲连接，下次查询就会突然失败，报错类似：
MySQL server has gone away
- 这不是 phpMyAdmin 的 bug，是底层连接被中间设备掐断了
- 解决方案：在 PHP 启动时强制开启 keepalive，需修改 PHP 配置（如
/etc/php/8.2/fpm/php.ini）：mysqli.reconnect = On（允许自动重连） - 更可靠的做法：在 phpMyAdmin 启动前注入连接参数，在
config.inc.php开头加（注意位置）：mysqli_options(mysqli_init(), MYSQLI_OPT_CONNECT_TIMEOUT, 30); mysqli_options(mysqli_init(), MYSQLI_OPT_READ_TIMEOUT, 180); mysqli_options(mysqli_init(), MYSQLI_OPT_WRITE_TIMEOUT, 180);
- 但注意：这些
mysqli_options必须在mysqli_init()后立即调用，且 phpMyAdmin 自身不提供 hook，所以实际生效依赖你是否能控制其启动流程（Docker 用户可在 entrypoint.sh 中提前设）
反向代理与 CDN 会覆盖所有超时设置
即使 MySQL 和 PHP 都调好了，Nginx、Apache 或 Cloudflare 仍可能在半路截断连接：
- Nginx 用户检查：
fastcgi_read_timeout（对应 PHP-FPM）、proxy_read_timeout（对应反代 MySQL）必须 ≥net_read_timeout - Cloudflare 免费版硬性限制 100 秒，无法绕过；若用它代理 phpMyAdmin 访问远程 DB，必然超时
- Docker 容器间通信：确认宿主机或 Docker daemon 没启用
--iptables=false，否则 conntrack 表老化策略可能比 MySQL 的net_read_timeout更激进
最常被忽略的是：这些超时参数必须对齐——MySQL 的 net_read_timeout、PHP 的 mysqli_options(...READ_TIMEOUT)、Nginx 的 fastcgi_read_timeout，三者中最小的那个就是实际生效值。
