bind-address = 0.0.0.0 是最危险的默认值，它使MySQL监听所有网络接口，若防火墙或安全组配置疏漏，扫描器可在1秒内发现并爆破3306端口；需严格配合云安全组、主机防火墙、容器网络策略及MySQL用户host权限四层过滤。
bind-address = 0.0.0.0 是最危险的默认值
MySQL 启动时若未显式配置 bind-address，旧版（如 5.6）可能默认监听 0.0.0.0，新版（8.0+）在某些发行版包中也沿用该行为。这不是“开放方便”，而是把 3306 端口赤裸裸扔到公网网卡上——只要防火墙或安全组稍有疏漏，扫描器 1 秒内就能捕获并尝试爆破。
常见翻车点：
-
bind-address = 0.0.0.0和skip-networking = 1共存时，MySQL 5.6 会静默忽略前者，但日志不报错，你以为关了网络，其实没关 - 配置文件里写成
bind-address="0.0.0.0"（带引号），MySQL 启动失败且不提示具体原因，只卡在初始化阶段 - 改完配置忘记重启服务，
systemctl restart mysql执行后未检查状态，systemctl is-active mysql返回 inactive 却没发现
防火墙 DROP 规则必须前置放行 127.0.0.1
MySQL 启动过程中会自连 127.0.0.1:3306 做健康校验。如果你的 iptables 规则把所有 INPUT -p tcp --dport 3306 都 DROP，服务根本起不来——不是连接被拒，是压根启动失败。
正确顺序只有一条路：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 先加放行：
iptables -I INPUT -s 127.0.0.1 -p tcp --dport 3306 -j ACCEPT - 再加拦截：
iptables -A INPUT -p tcp --dport 3306 -j DROP - 绝对不用
REJECT：它发 RST 包，暴露端口存在；DROP才让扫描器收不到任何响应 - 规则保存后必须验证：
iptables -L INPUT -n --line-numbers确认顺序无误
云服务器的安全组不是可选项，是第一道闸机
阿里云/腾讯云/AWS 的安全组在流量抵达网卡前就完成过滤，比系统内 iptables 早一个网络层级。哪怕你 iptables 配得滴水不漏，只要安全组开了 0.0.0.0/0 → 3306，外网照样能打进来。
真实运维陷阱：
- 安全组策略被误操作清空（比如批量导入覆盖），而
iptables规则还在，导致“明明没改系统配置，怎么突然能连上了？” - 测试环境和生产环境共用同一套安全组模板，测试时开过
0.0.0.0/0，上线忘了收敛 - 应用服务器与 DB 在同一 VPC 内，却把 DB 安全组源地址设成公网 IP 段，而不是内网 CIDR（如
10.0.0.0/16）
Docker/K8s 场景下 127.0.0.1 是个假象
容器内配 bind-address = 127.0.0.1，只锁死容器内部回环；宿主机、其他 Pod 或 NodePort 服务仍可通过桥接网段（如 172.17.0.0/16）直连 3306。这不是配置失效，是网络模型根本不同。
必须额外补两层：
- Docker：用
--network=host不解决本质问题，应配合iptables -A DOCKER-USER自定义链限制源 IP - Kubernetes：仅靠
PodSecurityPolicy不够，必须配NetworkPolicy显式拒绝非白名单 namespace 的入向 3306 流量 - StatefulSet 中 MySQL Pod 若用了
hostNetwork: true，等同于裸机暴露，bind-address必须同步改为内网 IP，不能留127.0.0.1
