MySQL连不上localhost:3306的首要原因是服务未真正在3306监听或防火墙规则未生效；需依次验证：mysqld是否LISTEN 3306、Windows/Linux防火墙入站规则是否启用并匹配网络配置、云服务器安全组与实例防火墙是否双重放行。
MySQL服务起来了，但Workbench连不上 localhost:3306？先看防火墙是否真放行了
不是“开了防火墙”就等于“放行了3306”，很多用户卡在这一步：明明在防火墙设置里加了规则，netstat -an | findstr :3306 也显示监听中，可 Workbench 还是报 failed to connect to mysql at localhost:3306 with user root。问题往往出在「规则没生效」或「规则方向错了」。
Windows 防火墙默认只管入站，而 Workbench 本地连接虽走 loopback，但某些版本或组策略下仍会被拦截。必须确认：
-
Windows Defender 防火墙 → 高级设置 → 入站规则中存在一条启用状态、协议为 TCP、端口为3306的规则（名称随意，但目标端口必须精确匹配） - 该规则的「配置文件」勾选了当前网络类型（如你连的是「专用」网络，规则里就得勾「专用」）
- 没有同名但被禁用的旧规则干扰（禁用规则不生效，哪怕名字一样）
- 若使用第三方安全软件（如 360、火绒），它们的防火墙模块可能独立于系统防火墙，需单独检查其「网络防护」或「端口控制」列表
Linux 上 ufw 或 firewalld 放行了 3306，为什么 telnet localhost 3306 仍超时？
常见错觉：执行了 sudo ufw allow 3306 或 firewall-cmd --add-port=3306/tcp --permanent 就完事。但 Linux 防火墙有两道关卡：规则添加 ≠ 规则加载 ≠ 规则对 loopback 生效。
务必验证三件事：
- 运行
sudo ufw status verbose（Ubuntu）或sudo firewall-cmd --list-ports（CentOS/RHEL），确认输出里真有3306/tcp - 如果用了
--permanent，必须跟sudo firewall-cmd --reload；ufw 则需sudo ufw reload - MySQL 本地连接走的是
127.0.0.1，而某些防火墙策略默认不限制 loopback 流量——但如果你手动加了reject或drop的通用规则，它可能意外拦截了lo接口。此时应优先用telnet 127.0.0.1 3306测试，而非telnet localhost 3306（DNS 解析可能引入干扰）
腾讯云/阿里云等云服务器上，安全组开了 3306，Workbench 还是连不上？
云厂商的安全组 ≠ 本地防火墙，它是第一层网络 ACL，必须和实例内防火墙协同生效。很多人只配了安全组，忘了实例系统自身的防火墙还在拦着。
典型排查链路：
- 登录云控制台 → 找到对应 ECS 实例 → 进入「安全组」→ 确认入站规则含
3306/tcp，且源 IP 设置合理（如0.0.0.0/0或你的办公 IP） - SSH 登录服务器 → 运行
sudo systemctl status firewalld或sudo ufw status，确认防火墙服务正在运行 - 再执行
sudo firewall-cmd --list-all或sudo ufw status verbose，确认 3306 端口确实在放行列表中 - 最后用
telnet 公网IP 3306（从本地命令行）测试通路——如果这步失败，90% 是安全组或实例防火墙没配对；如果成功，问题才回到 MySQL 配置或用户权限
绕过防火墙直接验证 MySQL 是否真在监听 3306
防火墙只是中间环节，真正决定能否连上的，是 MySQL 进程本身有没有绑定到 3306 并接受连接。别急着改防火墙，先用最底层方式确认服务状态。
在服务器上执行：
-
sudo lsof -i :3306（Linux/macOS）或netstat -ano | findstr :3306（Windows），看输出中是否有LISTEN状态且 PID 对应mysqld - 若有结果，再检查这一行的
Address字段：如果是*:3306或0.0.0.0:3306，说明监听所有接口；如果是127.0.0.1:3306，则仅限本地回环——Workbench 用localhost能连，但用127.0.0.1或实际 IP 可能失败（取决于 DNS 解析和 MySQL 的bind-address配置） - 若无任何输出，说明 MySQL 根本没在 3306 启动：可能是配置文件里改了
port，也可能是服务启动失败（查journalctl -u mysql或 Windows 事件查看器里的 MySQL 日志）
防火墙规则容易配错、容易叠加、容易被其他安全软件覆盖。真正可靠的验证，永远是从 mysqld 进程是否在监听开始，一层层往上推——否则你可能在正确的位置，反复修改一个根本没被触发的规则。
