bind-address仅支持单个ipv4地址或0.0.0.0，不支持网段、cidr、通配符或主机名；限制网段需结合防火墙规则与mysql用户host字段匹配，且bind-address设为具体ip后localhost连接将失效。
bind-address 本身不支持网段，只接受单个 IPv4 地址或 0.0.0.0；想限制特定网段访问，必须靠防火墙 + MySQL 用户 host 匹配双层控制。
bind-address = 192.168.1.100 是唯一合法的“指定网段内IP”写法
MySQL 的 bind-address 参数根本不认 CIDR（如 192.168.1.0/24）、不认通配符、不认主机名。它只接受：一个真实存在的 IPv4 地址（如 192.168.1.100），或 0.0.0.0（监听所有接口）。写成 bind-address = 192.168.1.% 或 bind-address = "192.168.1.0/24" 会导致 mysqld 启动失败，日志里出现 Invalid argument 或 unknown variable 'bind-address='。
如果你的服务器在 192.168.1.0/24 网段有一块网卡，且 IP 是 192.168.1.100，那你就只能设成：
bind-address = 192.168.1.100
然后确保：
- 该 IP 真实存在：ip addr show 能查到
- 没有其他配置覆盖它：检查 !include 引入的文件、多个 [mysqld] 段、systemd ExecStart 中硬编码的 --bind-address
- 重启服务：sudo systemctl restart mysql，不是 reload
用户 host 字段才是真正的“网段控制层”
MySQL 层面对客户端来源的过滤，靠的是 mysql.user 表里的 Host 列。它支持 % 和 _ 通配符，能模拟网段效果：
-
'app'@'192.168.1.%'→ 允许192.168.1.1到192.168.1.255所有地址（但不包括192.168.2.1） -
'report'@'10.0.%'→ 匹配10.0.0.0/16范围（注意是点分三段，不是 CIDR） -
'dev'@'%'→ 允许任意 IP，等同于开放全网——不推荐
执行授权后必须 FLUSH PRIVILEGES;（MySQL 8.0+ 多数情况不需要，但 CREATE/ALTER USER 后加一句更稳妥）。
注意：Host 匹配发生在连接建立后，所以前提是 bind-address 已让 MySQL “听得到”这个请求——如果绑在 127.0.0.1，那 192.168.1.50 根本连不上，Host 规则压根没机会生效。
防火墙才是第一道也是最可靠的网段闸门
仅靠 MySQL 用户 Host 匹配不够安全，因为错误配置可能意外放行。真正阻断非目标网段流量的，是系统防火墙：
- Ubuntu（ufw）：
sudo ufw allow from 192.168.1.0/24 to any port 3306 - CentOS/RHEL（firewalld）：
sudo firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.1.0/24" port port="3306" protocol="tcp" accept' - 云服务器（阿里云/腾讯云/AWS）：必须在控制台安全组中添加入方向规则，源地址填
192.168.1.0/24，协议 TCP，端口 3306
这条规则比 MySQL 层的 Host 更早拦截请求，不发包到 MySQL 进程，性能开销更低，也避免因权限误配导致的暴露风险。
常见翻车点：localhost 连接突然失效
一旦你把 bind-address 设为具体 IP（比如 192.168.1.100），MySQL 就不再监听 127.0.0.1。这意味着：
-
mysql -h 127.0.0.1 -u root -p会直接拒绝（TCP 连接被拒） - 本地脚本、Docker 容器内应用若硬编码了
-h 127.0.0.1，会全部中断 - 想保留本地调试能力，要么改用
mysql -h 192.168.1.100（确保路由可达），要么放弃绑定单 IP，改用bind-address = 0.0.0.0+ 防火墙 + 用户Host三层收紧
最容易被忽略的是：很多运维工具默认走 127.0.0.1，而你改完 bind-address 后没同步检查这些调用点——问题不是出在 MySQL 权限，而是连接根本没发出去。
