MySQL连不上八成是防火墙或安全组拦截:先用ss -tlnp | grep :3306确认监听地址,若仅为127.0.0.1需改bind-address为0.0.0.0并重启;再依序检查ufw/firewalld规则、云安全组(TCP 3306入向)、conntrack超时等。

MySQL连不上,八成不是服务没起来,是流量被防火墙拦在门外了——端口没开、规则写错、或者云平台安全组根本没配。
先确认MySQL自己监听的是哪个地址
别急着动防火墙,先看MySQL有没有“开门”。执行 ss -tlnp | grep :3306(或netstat -tlnp | grep :3306),观察输出的监听地址:
- 如果只看到
127.0.0.1:3306,说明它拒绝所有外部连接,此时开防火墙毫无意义;必须改my.cnf或mysqld.cnf里的bind-address为0.0.0.0或具体内网 IP,然后sudo systemctl restart mysql(或mysqld) - 如果看到
0.0.0.0:3306或*:3306,说明 MySQL 已准备就绪,可以继续配置防火墙 - Windows 用户注意:还要检查 Windows Defender 防火墙的入站规则是否启用,且协议选 TCP、端口填 3306、配置文件勾选“私有”和“域”(“公共”慎选)
ufw 下只允许指定 IP 访问 3306
sudo ufw allow 3306/tcp 是全放开,生产环境绝不能用。要精确控制来源:
- 单个 IP:
sudo ufw allow from 192.168.1.50 to any port 3306 proto tcp - 局域网段:
sudo ufw allow from 10.0.3.0/24 to any port 3306 proto tcp - 执行后务必运行
sudo ufw status numbered,确认规则已出现在列表中,且顺序靠前(ufw 规则按编号从上到下匹配) - 如果之前误加过全放开规则,用
sudo ufw delete删除,再 reload
firewalld 添加永久且带源限制的规则
临时规则重启即失效,必须加 --permanent 并重载:
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录,或需要将该能力封装成可公开复用的 Codex skill。
- 基础放行(不推荐):
sudo firewall-cmd --zone=public --add-port=3306/tcp --permanent - 带源 IP 限制(推荐):
sudo firewall-cmd --zone=public --add-rich-rule='rule family="ipv4" source address="172.16.5.10" port port="3306" protocol="tcp" accept' --permanent - 执行
sudo firewall-cmd --reload后,用sudo firewall-cmd --list-all检查ports:行是否含3306/tcp,rich rules:行是否显示对应 source - 注意:CentOS/RHEL 7+ 默认启用 firewalld,不要同时开 iptables,会冲突
云服务器必须同步配安全组
本地防火墙开了、MySQL 也监听 0.0.0.0:3306,还是连不上?大概率卡在阿里云/腾讯云/AWS 的安全组。
- 进控制台 → 找到对应 ECS 实例 → 安全组 → 入方向规则 → 新建规则
- 协议类型选
TCP,端口范围填3306/3306,源 IP 填192.168.5.20/32(单 IP)或10.0.0.0/16(内网段),**严禁填0.0.0.0/0** - 安全组和系统防火墙是“与”关系:两者都放行,连接才成功;任一拒绝,直接断连
- 改完安全组后等 10–30 秒再测,部分平台策略下发有延迟
最容易被忽略的是 conntrack 超时导致空闲连接被静默中断,现象是查询中途报 Lost connection to MySQL server during query,而 MySQL 日志里完全没记录——这时候得调内核参数 nf_conntrack_tcp_timeout_established,而不是反复查用户权限或 bind-address。










