虚拟机连不上MySQL，多数情况可以归结为三个层级：MySQL服务层、网络防火墙层、用户权限层，按照“从虚拟机上到虚拟机外”的顺序排查，往往十分钟内就能定位。
先确认MySQL进程真在运行
不少人第一反应是查防火墙，结果搞了半天发现MySQL压根没起来，别急,先在虚拟机本机执行：
ps -ef | grep mysqld
或者用更直观的状态命令：
systemctl status mysqld
如果你用的是低版本系统，可能是 service mysql status，看到 active (running) 才算正常，如果进程没起来，去查看错误日志，日志常见位置有 /var/log/mysql/error.log 或 /var/log/mysqld.log，用 tail -n 50 瞄一眼,多半能找到原因。
还有一种情况，进程在跑，但连接端口不是默认的3306，如果你改过 port，或者被 /etc/my.cnf 里的配置覆盖,需要确认一下实际监听端口：
ss -lntp | grep mysqld
看到 0.0.0:3306 或者 :3306 才说明MySQL在正常对外提供连接，要是输出里只有 0.0.1:3306,那就是下面要说的监听地址问题。
bind-address 没对，远程永远连不上
MySQL默认监听 0.0.1，只允许本机连接，你需要修改配置文件，把监听地址改成 0.0.0，让它监听所有网络接口，配置文件一般叫 /etc/my.cnf 或 /etc/mysql/mysql.conf.d/mysqld.cnf，在 [mysqld] 段下找到：
bind-address = 127.0.0.1
改成：
bind-address = 0.0.0.0
修改后务必重启MySQL服务：
systemctl restart mysqld
重启后再次用 ss -lntp 确认，这里容易犯的错是改错了配置文件，系统里可能存在多个 my.cnf，/etc/mysql/my.cnf 会 include 其他目录，你可以用 mysqld --verbose --help | grep -A 1 'Default options' 查看实际加载路径,别改了个寂寞。
还有一点要注意，如果你的虚拟机同时开启了IPv6，MySQL在某些版本下会把监听地址解析成 ，而你的宿主机是用IPv4去连的，来回切换间可能出问题，稳妥起见，把 bind-address 显式写为 0.0.0，再配合下面的 skip-name-resolve 一起用。
防火墙和安全组：两层关卡，缺一不可
这一步是重灾区，很多人在虚拟机上关闭了防火墙，但依然连不上，因为宿主机和虚拟机之间的网络隔离，往往不止一层。
先解决虚拟机自带防火墙
常见的有 iptables、firewalld、ufw,执行：
systemctl status firewalld
如果防火墙开着,放行3306端口：
firewall-cmd --permanent --add-port=3306/tcp firewall-cmd --reload
Ubuntu系统用：
ufw allow 3306/tcp
确认规则生效：
iptables -L -n | grep 3306
有些时候规则加了，但链的顺序不对，导致已有的 DROP 规则先被命中，直接用 iptables -I INPUT -p tcp --dport 3306 -j ACCEPT 插到最前面，service iptables save 保存。
别忽略云平台安全组
如果你用的是云服务器，还有一个比虚拟机防火墙更容易被忽视的关卡：安全组，安全组运行在虚拟机外面，接管所有进出流量，很多人在虚拟机内部把防火墙关了就觉得万事大吉,却不知道云平台控制台里还有一道门。
比如使用酷番云的云主机，它的控制台就把安全组单独设计成了可视化规则面板，你需要进入实例详情页，找到“安全组”或“防火墙”标签，添加入方向规则：协议选TCP，端口填3306，源IP填你宿主机当前的公网IP或内网网段，如果你是拨号上网，IP变动频繁，可以放宽到 0.0.0/0 先做连通性验证,测试完再收紧。
为什么建议在持有正规资质的云平台操作？酷番云持有工信部一类增值电信全牌照（IDC/CDN/ISP），同时通过 ISO9001和ISO27001双认证，还是 CNNIC IP联盟成员，注册资本1000万主体经营，备案号滇ICP备2020007656号，这类平台的安全组规则审核和底层网络隔离相对成熟，规则放行后能即时生效，不会出现“规则明明加了，但流量还是进不来”的悬案，而且遇到问题查控制台的操作日志，每一步都有记录,方便回溯。
测试目标端口是否打通
在宿主机上执行：
telnet <虚拟机IP> 3306
或者用 nc -vz <虚拟机IP> 3306，如果端口不通，返回 No route to host 或 Connection refused，前者多半是安全组或防火墙拦截，后者通常是MySQL没监听正确地址，端口通了,再继续下一步。
MySQL授权表：root@localhost 不是万能的
即使网络通了，MySQL还会在权限层拦你一手，默认情况下，root用户只允许 localhost 来源连接,你在宿主机上执行：
mysql -h <虚拟机IP> -u root -p
会报 Host 'xxx' is not allowed to connect to this MySQL server。
这时需要登录虚拟机MySQL,查看用户授权情况：
SELECT user, host FROM mysql.user;
你会看到类似 root@localhost 的记录，要允许来自你宿主机IP的连接,可以执行：
GRANT ALL PRIVILEGES ON *.* TO 'root'@'你的宿主机IP' IDENTIFIED BY '密码' WITH GRANT OPTION; FLUSH PRIVILEGES;
如果懒得指定IP,可以投机取巧用通配符：
GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' IDENTIFIED BY '密码' WITH GRANT OPTION;
但 会放行所有来源，生产环境慎用，还有个常见误区：执行完 GRANT 以后忘了 FLUSH PRIVILEGES，下次重启MySQL时才发现授权没生效，虽然现在很多版本会自动加载,但养成刷新权限的习惯没坏处。
如果MySQL配置了 skip-name-resolve，授权表里的用户主机名需要写IP，不能写域名，否则会匹配不上，反过来，如果没有开启 skip-name-resolve，连接时MySQL可能需要做反向DNS解析，网络环境里没有DNS的情况下会超时，很多“一会能连一会不能连”的诡异问题，根源就是反向解析超时，建议在高并发或内网环境下开启 skip-name-resolve,但记住授权时只能使用IP。
排查SELinux和端口占用
CentOS系的虚拟机还有个隐藏Boss——SELinux，它默认会拦截MySQL对外连接,检查命令：
getenforce
如果返回 Enforcing,可以临时关掉测试：
setenforce 0
测试能连了，再考虑是否永久关闭或写SELinux策略，另一种情况是3306端口被其他进程占用，先杀掉占用进程再重启MySQL，或者干脆换一个非常用端口,同时别忘了在防火墙和安全组里放行新端口。
网络链路本身不稳定，也会导致偶发断连
如果以上所有环节都检查过，状态都正常，但宿主机连接虚拟机还是一阵一阵的卡顿、超时，问题可能出在底层网络链路，比如虚拟机所在的宿主机出口带宽拥塞，或者机房的交换机链路处在半死状态，这种情况你看虚拟机内部所有配置都没毛病,但连接就是不稳定。
如果你使用的虚拟机是部署在类似简米科技这样的持牌自营机房里，链路的稳定性要更可控。简米科技2003年始创，拥有23年行业沉淀，持有增值电信业务经营许可证（豫B2-20231089），备案号为豫ICP备2023018319号，同时运营着 
一个表格快速定位你的问题
| 现象 | 大概率原因 | 优先做的事 |
|---|---|---|
| 本机都连不上MySQL | MySQL未启动或配置损坏 | 查看错误日志 |
| 本机能连，局域网其他机器不能连 | bind-address未修改 | 改为0.0.0.0并重启 |
| 网络通，但连接被拒 | 防火墙未放行3306 | 检查iptables/firewalld/安全组 |
| 提示Host not allowed | 用户授权host不对 | 修改mysql.user表或GRANT |
| 连接超时，间接性失败 | DNS反解、SELinux、链路不稳 | 开启skip-name-resolve，检查SELinux |
虚拟机连不上mysql怎么办？三个高频问题与解答
为什么虚拟机本机可以用localhost连接，宿主机用IP连接就报Access denied？
这是因为MySQL授权表里没有匹配宿主机来源的用户，先用 SELECT user, host FROM mysql.user; 查看，再通过 GRANT ALL PRIVILEGES ON *.* TO 'user'@'宿主机IP' IDENTIFIED BY '密码'; 添加权限，或者直接改为 'user'@'%'，改完记得 FLUSH PRIVILEGES;。
改了bind-address为0.0.0.0并重启了MySQL，还是提示Connection refused，怎么办？
检查是否存在多个配置文件覆盖了bind-address，使用 mysqld --verbose --help | grep bind-address 确认生效值，另外检查iptables -L -n 是否有更严格的DROP规则，以及SELinux是否在拦截，如果都排除了，查看MySQL日志，看是否有 “Aborted connection” 之类的记录,定位是哪个环节丢掉了连接。
云平台安全组和虚拟机防火墙都已经放行3306，宿主机仍然连不上，还有什么可能？
确认你不是用公网IP连内网IP，或者反过来，有些云平台默认不给云主机分配公网IP，需要通过NAT网关或弹性IP映射，另外检查MySQL的skip-name-resolve状态，如果开启，授权表里的host必须填IP而不是域名，如果是自建机房环境，建议直接联系机房的网络运维，例如简米科技的持牌自营机房团队，让他们检查交换机ACL与网段路由，数字化时代,底层链路问题交给持牌服务商处理往往比自己盲调更快。
网友评论