MySQL 8.0 仅支持基于源IP地址的精确或通配符匹配（如'user'@'192.168.1.%'），不识别国家、城市等地理信息；实现地理限制需依赖外部组件（如Nginx+GeoIP2、HAProxy、云WAF）或防火墙IP段规则，MySQL本身无感且不可直接配置地域策略。
MySQL 8.0 本身不支持按“地理位置”（如国家、城市、运营商）限制访问，它只认客户端连接时暴露的源 IP 地址，并基于该 IP 做精确匹配或通配符匹配。所谓“地理限制”，实际是靠外部手段把 IP 映射到地域，再做策略控制——MySQL 层只负责最基础的 user@host 鉴权，真要拦住某片区域的流量，得在更上层动手。
MySQL 层只能做 IP 级别的 host 匹配，不是地理识别
MySQL 的 Host 字段只接受字符串，支持 % 和 _ 通配符，例如：
-
'app'@'192.168.5.%'→ 匹配 192.168.5.0–192.168.5.255 范围，但不保证这些 IP 真属同一地理区域 -
'report'@'%.example.com'→ 依赖 DNS 反查，且需skip_name_resolve=OFF，不稳定、易被绕过、有性能开销 -
'admin'@'203.0.113.45'→ 精确单 IP，这是唯一可靠的方式
它不会解析 IP 归属地，也不读取 GeoIP 数据库。你给它一个 'user'@'CN' 或 'user'@'beijing'，会直接报语法错误。
想实现地理限制，必须用代理或前置网关做 IP 分类
常见可行路径是：在 MySQL 前加一层能做 IP 地理标签的组件，把请求打标后再透传给 MySQL，让 MySQL 基于打标后的 IP（比如内网转发 IP）做权限控制。典型组合：
- Nginx + geoip2 模块：根据客户端真实 IP 查 GeoIP2 数据库，提取
country_code或city_name，再用proxy_set_header X-Forwarded-For $remote_addr和自定义 header 透传；后端应用读 header 决定是否连 MySQL，或连哪个账号 - HAProxy：用
acl+geoipmap 文件识别来源地域，然后use_backend分流到不同 MySQL 实例（如mysql-cn/mysql-us），各实例只开放对应地域白名单账号 - 云厂商 WAF（如阿里云 Web 应用防火墙）：可配置“地域封禁”规则，直接在七层拦截来自特定国家/地区的 TCP 连接请求，MySQL 根本收不到包
注意：这些方案里，MySQL 本身完全无感，它只看到代理发来的连接，源 IP 是代理内网地址（如 10.0.1.5）。所以你仍需为代理 IP 创建账号，比如 'app'@'10.0.1.%'，并关闭 skip_name_resolve 避免 DNS 查询拖慢连接。
防火墙层可配合 IP 段做粗粒度“准地理”控制
虽然 MySQL 不懂地理，但你可以从公开渠道（如 APNIC、IPdeny）下载国家 IP 段列表，转成防火墙规则。例如，封禁全部俄罗斯 IP：
sudo iptables -I INPUT -s 193.32.0.0/12 -p tcp --dport 3306 -j DROP sudo iptables -I INPUT -s 195.208.0.0/13 -p tcp --dport 3306 -j DROP
这类操作风险高，容易误伤，且 IP 归属常滞后、不准确（比如 CDN 节点、云主机混用）。更稳妥的做法是：
- 只对明确恶意扫描源 IP 单点封禁（用
iptables -j DROP或firewalld --add-rich-rule） - 允许白名单 IP 段（如公司办公网、IDC 出口 IP），其余默认拒绝
- 配合 MySQL 8.0 的
CONNECTION_CONTROL插件，对频繁失败登录的 IP 自动延迟响应，防爆破而非地理过滤
别试图在 MySQL 里建 whitelist 表 + 触发器去查 IP 归属——触发器无法在连接建立前运行，mysql.user 表也不支持动态函数调用，这种设计既无效又破坏权限系统一致性。
验证时务必从目标 IP 实测，别信本地 curl 或 telnet
很多问题出在验证方式错位：
- 你在服务器本机跑
mysql -h 127.0.0.1 -u app -p，测的是'app'@'127.0.0.1'，和地理无关 - 用
telnet your-mysql-ip 3306只能确认端口通不通，不能验证账号是否被Host限制 - 真正有效的是：从你要限制/允许的那个真实外网 IP 上，执行
mysql -h your-mysql-ip -u app -p，看错误是Access denied for user 'app'@'xxx.xxx.xxx.xxx'（MySQL 层拒绝）还是连接超时（防火墙或bind-address拦截）
最容易被忽略的一点：MySQL 是否监听了正确的网卡。用 ss -tlnp | grep :3306 确认输出含 *:3306 或 0.0.0.0:3306，而不是只有 127.0.0.1:3306——后者意味着所有远程请求在 TCP 层就被拒了，后面所有地理策略都白搭。
