如何设置基于域名的数据库访问权限_Host通配符配置-phpMyAdmin-PHP中文网

mysql host字段仅支持%（匹配任意长字符串）和_（匹配单个字符）两种通配符；%不跨点匹配，不触发dns解析，纯字符串比对；开启skip_name_resolve=on可避免反向dns解析陷阱。

mysql 中 `host` 字段支持哪些通配符写法

mysql 的用户权限表（mysql.user）里，host 列决定谁可以从哪连上来。它不支持正则或模糊匹配，只认两种通配符：%（匹配任意长度字符串，包括空）和 _（匹配单个字符）。注意：% 不能跨点（比如 %.example.com 不匹配 sub.sub.example.com），也不等价于 dns 解析通配——它只是字符串比对。

常见错误现象：CREATE USER 'app'@'%.example.com' 看起来能覆盖所有子域名，但实际连 api.example.com 成功、db1.prod.example.com 却失败，就是因为中间多了一个点，% 只吃掉第一段。

'%'：允许任意主机（含 localhost，但注意：MySQL 会优先匹配更具体的 Host 条目）
'localhost'：仅限 Unix socket 或 127.0.0.1（取决于连接方式），不走 TCP
'192.168.1.%'：匹配整个 C 段 IPv4
'db-*.prod.example.com'：合法，* 不是通配符，这是字面量；真正生效的是 'db-%.prod.example.com'

用域名代替 IP 配置 `Host` 时的 DNS 解析陷阱

MySQL 默认在每次连接时反向解析客户端 IP 为域名（skip_name_resolve=OFF），然后拿这个域名去匹配 Host 字段。这意味着：你写了 'app'@'web1.example.com'，但只要客户端 IP 反解出的域名不是严格一致（大小写、别名、PTR 记录缺失），就会匹配失败，降级到 'app'@'%' 或直接拒绝。

使用场景：Kubernetes Pod IP 动态变化，想靠 Service 域名（如 web-svc.default.svc.cluster.local）控制权限——这不可行，因为 MySQL 不解析 Service DNS，只做客户端 IP 的 PTR 查询。

生产环境强烈建议设 skip_name_resolve=ON，关闭 DNS 反查，改用 IP 或 CIDR 段管理 Host
如果必须用域名，确保客户端机器的 PTR 记录准确且稳定（运维成本高）
SELECT USER(), CURRENT_USER(); 可查实际匹配的用户条目，用于调试权限是否按预期生效

`GRANT` 语句中 `Host` 写错导致权限不生效的典型表现

最常踩的坑是：执行了 GRANT SELECT ON db.* TO 'reader'@'web.example.com'，但应用连的是 web1.example.com，结果报 Access denied for user 'reader'@'web1.example.com'——错误信息里写的正是实际尝试匹配的 Host 值，不是你 GRANT 时写的那个。

另一个隐蔽问题：同一个用户名不同 Host 是独立账号。比如 'app'@'localhost' 和 'app'@'%' 可以有完全不同的密码和权限，互不影响。

检查当前有哪些匹配项：SELECT User, Host FROM mysql.user WHERE User = 'app';
删除冗余条目用 DROP USER 'app'@'old-host.example.com';，别只改密码
修改后必须 FLUSH PRIVILEGES;，否则变更不生效（尤其在非 GRANT 方式更新表后）

PostgreSQL 和 MySQL 在域名权限上的关键区别

PostgreSQL 根本没有 Host 字段这种设计，它的访问控制全靠 pg_hba.conf 文件，规则按顺序匹配，支持 CIDR、主机名（需系统级 DNS 解析）、甚至 hostssl 等条件。所以“基于域名的数据库访问权限”在 PostgreSQL 里是配置文件行为，不是用户属性。

这意味着：你在 PostgreSQL 里写 host all app .example.com md5，它会调用系统的 gethostbyname() 查 .example.com 的 A 记录，再做 IP 匹配；而 MySQL 的 %.example.com 是纯字符串前缀比对，不查 DNS。