根本原因是session.gc_maxlifetime、$cfg['LoginCookieValidity']和Web服务器超时（如fastcgi_read_timeout）三者未对齐，导致导入大SQL时会话被提前销毁；必须同步设置三者且满足session.gc_maxlifetime≥$cfg['LoginCookieValidity']≥Web服务器超时值，并确保session.save_path可写、IP透传正确及cookie_samesite设为Lax。
phpMyAdmin 5.2 导入大 SQL 文件时中途跳回登录页，根本不是“登录过期”，而是 session.gc_maxlifetime、$cfg['LoginCookieValidity'] 和 PHP-FPM/反代超时三者没对齐，导致会话被提前销毁。
为什么导入一半就登出？Session 被服务端主动丢弃了
phpMyAdmin 5.2 默认用 session 存储上传进度、临时文件路径和 CSRF token。导入过程是长 HTTP 请求（非后台任务），只要请求耗时超过任一环节的会话存活阈值，PHP 就会清理该 session 数据——下次任何操作（包括续传或重定向）都会因 token 或 session_id 失效而强制跳转到登录页。
常见错误现象：
- 导入进行到 60–90 秒左右突然跳回 /phpmyadmin/index.php?token=xxx 页面
- 浏览器开发者工具 Network 面板看到
import.php返回 302 + Location 到登录页，而非 200 或错误信息 - 日志里查不到 MySQL 错误，但
/var/log/php-fpm.log出现session_start(): Failed to read session data
必须同步调整的三个超时参数
只改其中一项毫无意义。三者必须满足：session.gc_maxlifetime ≥ $cfg['LoginCookieValidity'] ≥ Nginx/Apache 的 fastcgi_read_timeout（或 proxy_read_timeout）。
立即学习“PHP免费学习笔记（深入）”；
由 ReMe 驱动的记忆管理系统，支持跨会话记忆持久化、自动应用用户偏好以及智能上下文压缩...
-
session.gc_maxlifetime：PHP 底层 session 文件/存储的存活秒数，单位秒。在php.ini中设置，改完需重启 PHP-FPM -
$cfg['LoginCookieValidity']：phpMyAdmin 自身登录 cookie 过期时间，单位秒。在站点根目录下的config.inc.php末尾添加，如$cfg['LoginCookieValidity'] = 7200; -
fastcgi_read_timeout（LNMP）或proxy_read_timeout（反代场景）：Web 服务器等待 php-fpm 返回响应的最大时间，单位秒。Nginx 中写在location ~ \.php$块内，Apache 对应ProxyTimeout
推荐值（以导入 10 分钟级 SQL 为例）：
$cfg['LoginCookieValidity'] = 7200;
// php.ini
session.gc_maxlifetime = 7200;
// nginx.conf location ~ \.php$ { ... }
fastcgi_read_timeout 7200;
phpMyAdmin 5.2 特有的 token 绑定问题
5.2+ 强制 token 与会话 ID 和 IP 哈希前缀绑定。导入过程中若发生 IP 变动（如经多层 NAT、CDN、移动网络切换）、或反代未透传原始 IP，会导致后续请求校验失败，直接清空 session 并跳转登录页。
- 检查 Nginx 是否设置了
fastcgi_param REMOTE_ADDR $remote_addr;（不是$http_x_forwarded_for） - 确认
session.cookie_samesite没设为Strict；设为Lax更稳妥 - 宝塔用户注意：【网站】→【设置】→【反向代理】→【高级】中勾选「强制 HTTPS」或「缓存」可能干扰 cookie 传递，临时关闭测试
别忽略的底层存储问题
phpMyAdmin 5.2 导入时会把整个 SQL 文件先读入内存再分块执行，同时写 session。如果 PHP 的 session.save_path 所在磁盘满、权限不对（如 www-data 无写权限），或使用 Redis/Memcached 但连接不稳定，都会导致 session 写失败——表现就是每次请求都新建 session，token 不一致，自然登出。
验证方式：
- 执行
php -i | grep session.save_path，然后ls -ld /path/to/save看权限和磁盘空间 - 临时切回 files 存储：在
php.ini中确保session.save_handler = files，避免中间件引入额外故障点 - 不要在
config.inc.php里加ini_set('session.save_path', ...)—— phpMyAdmin 5.2 的初始化顺序可能导致它被忽略
最易被忽略的一点：phpMyAdmin 5.2 的 session 初始化发生在 token 校验之后，如果 token 已失效（比如因超时被删），它不会尝试重建 session，而是直接重定向。所以排查必须从超时参数对齐开始，而不是先翻日志找 token mismatch。
