mysql远程连接失败的根源在于权限、绑定地址、防火墙三重限制，需依次执行grant授权、修改bind-address为0.0.0.0、开放3306端口并验证监听状态。
MySQL 用户权限没开远程访问，localhost 限制是默认拦路虎
宝塔面板连不上远程数据库，八成不是宝塔的问题，而是 MySQL 本身拒绝了非本地连接。MySQL 默认只允许 root@localhost 登录，哪怕你用的是正确的账号密码、IP 和端口，也会直接报错：Access denied for user 'xxx'@'xxx.xxx.xxx.xxx'（注意后面那个 IP 是你的服务器公网 IP 或内网 IP，不是 localhost）。
解决方法不是改宝塔配置，而是进远程数据库服务器执行授权：
GRANT ALL PRIVILEGES ON *.* TO 'your_user'@'%' IDENTIFIED BY 'your_password' WITH GRANT OPTION; FLUSH PRIVILEGES;
关键点：
-
@'%'表示允许从任意 IP 连接；生产环境建议写死 IP，比如@'192.168.1.100' - 如果用户已存在，不能只用
CREATE USER，必须用GRANT显式赋予远程访问权限 -
FLUSH PRIVILEGES必须执行，否则权限不生效 - 某些 MySQL 8+ 版本默认认证插件是
caching_sha2_password，PHP/旧客户端可能不兼容，可加一句：ALTER USER 'your_user'@'%' IDENTIFIED WITH mysql_native_password BY 'your_password';
MySQL 绑定地址仍是 127.0.0.1，根本没监听外网请求
即使权限开了，MySQL 进程如果只绑定了 127.0.0.1，它压根就不会接收来自其他机器的 TCP 连接。检查配置文件（通常是 /etc/my.cnf 或 /etc/mysql/mysql.conf.d/mysqld.cnf）里的 bind-address 项：
bind-address = 127.0.0.1
改成：
bind-address = 0.0.0.0
或更安全的指定内网 IP（如 192.168.1.10），然后重启 MySQL：systemctl restart mysql（或 mysqld）。验证是否生效：netstat -tlnp | grep :3306，看到 0.0.0.0:3306 或具体 IP:3306 才算监听成功。
注意：改完不重启服务 = 白改；改完不验证监听状态 = 猜测式排障。
防火墙或云厂商安全组没放行 3306 端口，流量在半路就被掐了
MySQL 启动了、权限给了、也监听外网了，但还是连不上？大概率卡在「网络层」。要逐级排查：
- 本地服务器防火墙：
ufw status（Ubuntu）或firewall-cmd --list-ports（CentOS），确认3306/tcp已放行。没开就执行：ufw allow 3306或firewall-cmd --permanent --add-port=3306/tcp - 云服务器（阿里云/腾讯云/华为云）必须进控制台 → 安全组 → 添加入方向规则，协议类型选
TCP，端口范围填3306，源 IP 建议限制为宝塔所在服务器的 IP，别直接填0.0.0.0/0 - 宝塔面板本身不拦截数据库连接，但它运行在目标服务器上，所以它连远程库时，走的是远程库服务器的防火墙 + 安全组，和宝塔的防火墙设置无关
宝塔里填的连接信息看似正确，但细节常被忽略
在宝塔「数据库」→「添加远程数据库」时，这些字段最容易出错：
-
数据库地址：不能填localhost或127.0.0.1（那是远程库自己的回环地址），得填远程库服务器的**实际可访问 IP**，比如公网 IP 或同内网下的私有 IP -
端口：确认远程库 MySQL 实际监听的端口，不一定是3306（有些环境改过） -
用户名/密码：必须是上一步GRANT授权时指定的用户，不是宝塔本地数据库的账号 - 测试连接失败后，不要只看宝塔提示的「连接失败」——去远程库服务器执行：
tail -f /var/log/mysql/error.log，真实错误日志比前端提示详细得多
远程数据库连接本质是跨机器、跨网络、跨权限模型的链路，任何一个环节断掉都会失败。最稳妥的验证顺序是：先在宝塔服务器上用 mysql -h 远程IP -P 3306 -u 用户 -p 手动连，能通再配宝塔；手动都连不通，说明问题不在宝塔侧。
