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 是全放开，生产环境绝不能用。要精确控制来源：
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 单个 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 并重载：
- 基础放行（不推荐）：
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。
