MySQL 默认监听0.0.0.0:3306，必须通过bind-address限制监听地址、系统防火墙（ufw/firewalld）设置IP白名单、云平台安全组精确放行，并与MySQL用户host字段协同配置，四层防护缺一不可。
MySQL 默认监听所有网卡，不设防火墙等于裸奔
MySQL 安装后默认绑定 0.0.0.0:3306，只要端口开放，任何能连上服务器的机器都可能暴力试探 root 密码。权限控制（比如 GRANT）只管「登录后能做什么」，不管「谁可以连上来」——这是网络层的事，得靠防火墙兜底。
实操建议：
- 先确认 MySQL 实际监听地址：
ss -tlnp | grep :3306或查my.cnf中的bind-address；若为0.0.0.0或注释掉，说明已暴露全网 - 生产环境必须设为
127.0.0.1（仅本地）或具体内网 IP（如192.168.10.5），再配合防火墙白名单 - 别依赖
skip-networking：它会禁用 TCP 连接，导致无法远程管理、备份工具（如mysqldump通过网络调用）失效
ufw / firewalld 开放指定 IP 访问 3306 端口
Linux 主流发行版用 ufw（Ubuntu）或 firewalld（CentOS/RHEL），核心原则是：默认拒绝所有入站，只放行可信来源。
常见错误现象：开了 ufw allow 3306，结果整个互联网都能连 —— 因为这等价于放行所有 IP 的 3306 端口。
正确做法：
- Ubuntu（ufw）：
ufw allow from 192.168.10.100 to any port 3306（仅允许可信应用服务器） - CentOS（firewalld）：
firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.10.100" port port="3306" protocol="tcp" accept'，之后firewall-cmd --reload - 若需多 IP，逐条添加；别用
/24网段掩码，除非该网段内所有机器都可信 - 检查是否生效：
ufw status verbose或firewall-cmd --list-all
云服务器安全组比系统防火墙更优先
阿里云、AWS、腾讯云等平台的安全组是第一道网关，规则匹配早于系统防火墙。即使你本地 ufw 拒绝了所有连接，安全组开着 3306 全放行，MySQL 依然裸奔。
使用场景：数据库与应用部署在不同云主机，且走内网通信。
关键点：
- 安全组入方向规则必须精确到源 IP 或内网网段，协议选
TCP，端口填3306 - 不要勾选「0.0.0.0/0」，哪怕临时调试也不建议；可用弹性公网 IP 绑定跳板机，再从跳板机连数据库
- 安全组无日志，排查连不上时，先看安全组，再查系统防火墙，最后看 MySQL 的
bind-address和用户host字段（如'user'@'192.168.10.%'）
MySQL 用户 host 字段和防火墙要协同验证
防火墙控制「能不能发包到 3306 端口」，MySQL 的 host 字段控制「连上来之后认不认识你」。两者缺一不可，但常被当成一回事。
典型坑：
- 用户建成了
'app'@'%'，以为「% 就是任意 IP」，结果防火墙没开对应 IP，连都连不上 - 用户建成了
'app'@'192.168.10.100'，但防火墙允许的是192.168.10.0/24，MySQL 层却因 host 不匹配直接拒登（错误信息：Access denied for user 'app'@'192.168.10.101'） - 云环境注意 NAT：客户端真实 IP 可能被 SNAT 成内网网关地址，此时 MySQL 用户的
host要配网关 IP，而非原始客户端 IP
验证顺序固定：安全组 → 系统防火墙 → MySQL bind-address → 用户 host 匹配 → 密码校验。漏掉任一环，表现都是「连接被拒绝」或「访问被拒绝」，但原因完全不同。
复杂点在于，这四层策略分散在不同位置、不同配置文件、不同命令里，改一处忘了同步其他地方，问题就藏得深。尤其上线前压测或迁移时，最容易只调了 MySQL 权限，忘了安全组白名单还锁着旧 IP。
