$cfg['AllowArbitraryServer'] = true 本质不安全，因它绕过所有预设服务器白名单校验，允许用户任意填写host/port/credentials直连数据库，易导致内网渗透、文件读写及会话失控。
开启 $cfg['AllowArbitraryServer'] = true 会直接暴露登录表单给任意服务器地址输入，绕过所有预设信任边界，不是“不方便”，而是主动引入高危攻击面。
为什么它本质上是不安全的登录机制
phpMyAdmin 的 cookie 认证流程默认只接受配置在 $cfg['Servers'] 数组里的服务器。一旦启用 $cfg['AllowArbitraryServer']，认证逻辑就退化为：用户填什么 host、port、user、password，就拿什么去连——中间没有任何白名单校验、协议约束或上下文隔离。
- 攻击者可在登录页直接填入内网数据库地址（如
10.0.1.5:3306），只要 phpMyAdmin 所在服务器能通，就可能连上并执行 SQL - 若后端 PHP 进程以较高权限运行（常见于宝塔/XAMPP 默认部署），攻击者还可通过
LOAD DATA INFILE或SELECT ... INTO OUTFILE读写服务器文件系统 - 浏览器地址栏里明文出现目标数据库地址（如
?server=192.168.2.100），极易被代理日志、CDN 缓存、审计系统捕获
它和多服务器配置根本不是一回事
很多人误以为 $cfg['AllowArbitraryServer'] 是“支持多个服务器”的必要开关，其实完全相反：真正的多服务器管理靠的是静态声明 $cfg['Servers'][1]、$cfg['Servers'][2]…… 并在登录页下拉框中选择——每个条目都经过配置校验、连接测试、凭据绑定，且 session 与该服务器实例强关联。
- 启用
$cfg['AllowArbitraryServer']后，你无法在不同服务器间保持独立会话，切标签页就掉登录（因为 cookie domain/path 不匹配） - 它禁用
$cfg['ServerDefault']和$cfg['Servers'][$i]['host']的预加载逻辑，导致每次请求都尝试探测所有已配服务器连通性，加剧max_connections溢出风险 - XAMPP 或宝塔中手动添加多个
$cfg['Servers'][$i]条目，不需要也不应该开这个选项
哪些场景真需要它？以及怎么收窄风险
极少数运维场景确实要临时接入未预配的数据库（比如故障排查、第三方交付验证），但必须做硬性限制：
立即学习“PHP免费学习笔记（深入）”；
- 仅在调试环境启用，生产环境配置文件里绝不能出现
$cfg['AllowArbitraryServer'] = true - 配合反向代理加 IP 白名单，例如 Nginx 中用
allow 192.168.10.0/24; deny all;锁死访问来源 - 把
$cfg['Servers'][0]（即索引为 0 的空配置）设为唯一入口，并在config.inc.php末尾加判断：if ($cfg['AllowArbitraryServer'] && !in_array($_SERVER['REMOTE_ADDR'], ['127.0.0.1', '192.168.1.100'])) { die('Arbitrary server access denied'); }
真正难处理的从来不是“能不能连”，而是“连上之后谁来管权限、会话、连接生命周期”。$cfg['AllowArbitraryServer'] 把这些问题全推给使用者，而大多数部署根本没有配套的网络隔离、审计日志和凭据轮换机制。
