mysql安全组必须限制源ip而非0.0.0.0/0，且需与bind-address双重收敛，并配合iptables/nftables兜底，多安全组按优先级匹配，规则须逐层验证。
MySQL安全组规则必须限制源IP，不能填0.0.0.0/0
云上MySQL暴露在公网等于裸奔，几小时内就会被扫描器盯上。安全组不是“要不要开3306端口”的问题，而是“只允许谁连”的问题。填0.0.0.0/0等于把锁打开扔在地上。
- 开发调试时，用
curl ifconfig.me查当前真实出口IP，填成203.0.113.45/32（单IP CIDR） - 应用服务器直连DB时，填内网IP段，如
172.16.10.0/24，而非整个VPC网段 - 跳板机访问场景，填跳板机的内网IP，比如
10.0.5.12/32，别用安全组ID引用——部分云平台不支持跨安全组放行 - 阿里云/腾讯云安全组不解析域名，填
jump-server.example.com会直接失效
安全组和MySQL bind-address要双重收敛
只配安全组不改bind-address，等于门锁了但窗户大开。MySQL进程仍可能监听0.0.0.0:3306，一旦安全组误配或绕过（如绑定弹性公网IP），立刻失守。
- 检查配置文件：
/etc/mysql/mysql.conf.d/mysqld.cnf或/etc/my.cnf，确认bind-address设为127.0.0.1（本地）或具体内网IP（如172.16.0.5） - 重启后验证：
ss -tlnp | grep :3306，输出应为*:3306（表示监听所有接口）→ 错；应为172.16.0.5:3306或127.0.0.1:3306→ 正确 - 若用Docker部署，
my.cnf需挂载进容器，且启动命令不能加--network host——这会让容器共享宿主机网络，绕过安全组
多个安全组共存时，优先级决定实际生效规则
TDSQL-C MySQL版等支持多安全组绑定，但规则不是叠加生效，而是按优先级顺序匹配——遇到第一条匹配就停止，后面规则无效。很多人以为“加一条白名单就行”，结果被前面的拒绝规则拦住。
- 腾讯云控制台中，安全组列表右侧有“上调/下调”按钮，数字越小优先级越高
- 建议：把精确放行规则（如
172.16.10.22/32 → 3306）设为优先级1，把宽泛拒绝规则（如0.0.0.0/0 → deny）设为优先级最后 - 阿里云不显示显式优先级，但规则添加顺序即匹配顺序，新规则默认追加到末尾——所以删旧规则、重加新规则比直接编辑更可靠
- 一个安全组内规则超过50条会明显增加首包延时，别堆几十条
/32IP规则，合并成/24或用IP地址组（如腾讯云支持“IP地址模板”）
安全组只是第一道防线，iptables/nftables必须兜底
轻量应用服务器没安全组，弹性公网IP直绑实例会绕过安全组，运维误操作可能临时放开大网段——系统防火墙是最后一道确定性防线。
- Ubuntu 22.04+ 默认用
nftables，执行：nft add rule inet filter input tcp dport 3306 ct state new drop先拒所有，再加白名单 - CentOS 7用
iptables：iptables -A INPUT -p tcp --dport 3306 ! -s 172.16.10.22 -j DROP - 规则要持久化：
nft list ruleset > /etc/nftables.conf或service iptables save - 别依赖“云平台控制台里开了3306就万事大吉”——安全组在内核网络栈之上，iptables在之下，漏配任何一个都可能让DB裸奔
0.0.0.0；iptables写了拒绝，但忘了lo回环接口要放行；多安全组优先级调错，白名单被隐式拒绝覆盖。每层都得单独验证，不能假设上层正确就跳过下层。
