Token mismatch错误主因是跨服务器切换时session与cookie上下文不一致：session.save_path未统一、反向代理未透传Host/X-Real-IP头、Cookie域不匹配或权限不足导致token无法正确生成与校验。
多服务器配置本身不会导致 token mismatch 错误，真正触发它的，是跨服务器切换时 session 和 cookie 的上下文不一致。
为什么切换服务器后突然报“Token mismatch”？
phpMyAdmin 的 token 机制默认绑定当前会话（$_SESSION）和当前请求的来源上下文。当你在登录页选择不同服务器（比如从 localhost 切到 172.18.0.1:3307），若以下任一条件不满足，就会导致 token 校验失败：
- 多个服务器共用同一套 session 存储路径（
session.save_path），但不同服务器的域名或端口被浏览器视为不同源，导致 cookie 无法复用 - 反向代理或负载均衡未透传原始 Host 头，使 phpMyAdmin 误判请求来源，生成/校验 token 时用了错误的会话 ID 哈希前缀
- 配置中启用了
$cfg['AllowArbitraryServer'] = true，但没同步设置$cfg['CheckConfigurationPermissions'] = false（注意：这不推荐，仅用于诊断） - 多服务器配置写在
config.inc.php里，但部分服务器块漏掉了$cfg['Servers'][$i]['auth_type'] = 'cookie'，导致某些连接走 HTTP auth，token 不参与校验流程
检查 Nginx/Apache 是否透传了关键请求头
如果你用反向代理统一入口访问多个后端数据库（例如通过 phpmyadmin.example.com/db1 和 phpmyadmin.example.com/db2 路由到不同实例），必须确保代理层把原始请求上下文完整交给 phpMyAdmin：
- Nginx 中需启用
proxy_pass_request_headers on;，否则Cookie头可能被丢弃 - 确认
proxy_set_header Host $host;和proxy_set_header X-Real-IP $remote_addr;已设置，新版 phpMyAdmin 的 token 哈希前缀依赖X-Real-IP（取前两段） - Apache 用户检查是否漏了
ProxyPreserveHost On和RequestHeader set X-Real-IP "%{REMOTE_ADDR}s"
多服务器下 session 配置必须统一且可写
token 匹配失败最常被忽略的底层原因是 session 文件不可写或路径不一致——哪怕你只改了一个服务器的 host，只要 session 存储路径（session.save_path）在 PHP 层级没对齐，每次请求都可能新建 session，$_SESSION[' PMA_token '] 就永远和表单提交的 token 对不上：
- 所有服务器实例必须共用同一个
session.save_path（如/var/lib/php/sessions），不能各自指向/tmp这类易被清理的目录 - Web 服务器用户（如
www-data或www）必须对该路径有读写权限：chown www:www /var/lib/php/sessions && chmod 700 /var/lib/php/sessions - 不要在
config.inc.php里用ini_set('session.save_path', ...)动态覆盖，PHP-FPM 池级配置更可靠
临时验证：绕过 token 校验只用于定位问题
不建议长期禁用，但当你需要快速确认是不是 token 机制本身出问题（而非环境配置），可在 libraries/common.inc.php 中找到 checkToken() 调用位置（通常在第 460 行附近），**仅临时注释掉该行**：
立即学习“PHP免费学习笔记（深入）”；
/* checkToken(); */
重启服务后如果错误消失，说明问题确实在 token 传递链路上，而非数据库连接或权限。此时应立刻恢复该行，并回头检查 session、cookie 和代理配置——因为 checkToken() 是 CSRF 防护核心，跳过它等于让所有 import.php、tbl_drop.php 接口裸奔。
真正麻烦的不是多服务器本身，而是每个服务器背后对应的网络路径、cookie 作用域和 session 生命周期是否被当作一个整体来管理。漏掉任意一环，token 就会“认不出自己”。
