必须网络层（iptables/firewalld）和数据库层（mysql.user Host字段）双重封禁IP段，仅单层无效；iptables需用-I插入链首并指定--dport 3306；MySQL Host不支持CIDR，须用'x.x.x.%'通配；三者（防火墙、bind-address、user@host）协同生效，且应启用skip_name_resolve。
直接封禁特定 IP 段，必须分两层做：网络层用 iptables 或 firewalld 拦在 MySQL 握手之前；数据库层用 mysql.user 表的 Host 字段控制账号级来源匹配。只做一层，大概率失效。
iptables 封禁 IP 段必须用 -I 插入最前，且明确指定 --dport 3306
MySQL 连接失败时如果还返回 Access denied for user，说明请求已抵达 mysqld，iptables 规则没生效或位置错了。常见错误是用 -A INPUT 追加规则，结果被前面的 ACCEPT 规则提前放行。
- 正确写法：
iptables -I INPUT -s 203.0.113.0/24 -p tcp --dport 3306 -j DROP（-I确保插入链首） - 别漏掉
--dport 3306：不加端口限制会误杀 SSH、HTTP 等其他服务 - 封完立刻测试：
telnet 203.0.113.5 3306—— 应该超时或直接拒绝，而不是出现Connection refused - 持久化保存：
iptables-save > /etc/iptables/rules.v4（Debian/Ubuntu）或service iptables save（CentOS 6）
mysql.user 表中 Host 字段不支持 CIDR，只能用 % 和 _ 通配符
执行 UPDATE mysql.user SET Host = '192.168.1.0/24' WHERE User = 'app'; 是无效的。MySQL 解析 Host 时只认字面量、%（匹配任意字符）、_（匹配单字符），不识别斜杠和数字。
- 想放行整个 C 段：用
'app'@'192.168.1.%'—— 注意末尾是点加 %，不是/24 - 这个写法有风险：它会匹配
192.168.1.999（MySQL 静默截断为192.168.1.99），但无法阻止192.168.11.5 - 禁止某 IP 段用户登录，不能靠
REVOKE已有账号：比如已有'app'@'%'，再执行REVOKE ALL ON *.* FROM 'app'@'192.168.1.%'不起作用，因为权限记录里根本不存在这个 host 组合 - 真正有效的是删掉通配账号：
DROP USER 'app'@'%';，再重建精确账号：CREATE USER 'app'@'192.168.1.%' IDENTIFIED BY 'pwd';
bind-address + 防火墙 + 用户 Host 必须协同，缺一不可
只改 my.cnf 里的 bind-address = 192.168.1.10，不代表安全。如果服务器有多张网卡，而防火墙没关公网 3306 端口，攻击者仍可能从另一接口连上——只要 MySQL 监听了那个地址。
-
bind-address控制监听范围：设为127.0.0.1则只响应本地连接；设为内网 IP 则只监听该接口 - 防火墙（
iptables/firewalld）控制谁能把包发到这个端口：即使 MySQL 监听0.0.0.0，防火墙也能只放行白名单 IP -
mysql.user.Host控制谁通过鉴权：哪怕包进来了、mysqld 接收了，没有匹配的user@host记录，照样报Access denied - 三者顺序是：防火墙 → bind-address → 用户 host 匹配。任一环节放行，就可能绕过下一层
最容易被忽略的是 skip_name_resolve 设置。如果它是 OFF（默认），MySQL 会对每个连接做反向 DNS 查询，慢且可能被利用；设为 ON 后，Host 字段只按 IP 比较，行为更确定，也避免因 DNS 延迟拖慢连接建立。
