域名通配符与正则表达式都能匹配多个子域名，但两者的工作层级和匹配逻辑完全不同：通配符依赖DNS层面的泛解析，正则表达式则主要用于服务器配置中的路径与域名规则匹配。换句话说，通配符管的是“解析到哪台服务器”，正则管的是“服务器收到请求后如何处理”。
域名的层级结构与子域名匹配前提
理解通配符和正则之前，先明确一个基础共识：域名由点号分隔的多个标签组成，www.example.com 中，com 是顶级域，example 是主域名，www 是子域名，子域名可以无限层级，a.b.example.com,但每一层都必须符合域名规范。
业内的共识是，最常用的子域名匹配需求集中在两级以内，即 .example.com 这种形式,因为三级及以上的泛解析在实际业务中容易引发安全和维护问题。
域名通配符：DNS层面的泛解析
通配符的工作原理
通配符域名，通常写作 .example.com，在DNS解析记录中属于特殊记录类型，当用户访问一个不存在的子域名时，DNS服务器会检查是否存在匹配的通配符记录，如果有,则返回该记录指向的IP地址。
实际操作中,你在域名管理后台的DNS解析面板添加一条记录：
- 主机记录填写
- 记录类型选择
A或CNAME - 记录值填写你的服务器IP或目标域名
添加完成后，任意层级的子域名，如 blog.example.com、shop.example.com、anything.example.com，只要DNS查询时找不到精确匹配的A记录,都会自动命中这条泛解析规则。
通配符的适用场景
批量绑定测试环境是通配符最常见的用途，开发团队往往需要为每次代码提交生成独立的预览地址，pr-1234.example.com，通过通配符解析加上服务器端的自动配置，不需要为每个子域名单独添加DNS记录,极大减少运维工作量。
多租户SaaS平台也是典型场景，每个用户获得一个独立的子域名（如 user1.saas.com），平台在用户注册时动态生成子域名，DNS层只需一条 .saas.com 的泛解析即可覆盖所有用户。
通配符的局限性
通配符匹配不了主域名本身。.example.com 只能匹配 blog.example.com
，但无法匹配裸域 example.com,这二者需要分别解析。
通配符也不支持“部分匹配”，你无法通过通配符实现 dev-.example.com 这种模式，因为DNS的通配符规则规定， 只能出现在最左侧的标签位置上,且是完整的标签。
还有一个容易被忽略的点：通配符会让所有未定义子域名都指向同一台服务器，如果攻击者利用这一点做子域名枚举，或者滥用未绑定域名进行恶意操作，就可能导致资源消耗或安全风险,日常运维需要定期检查访问日志中是否出现乱写的子域名。
正则表达式：Nginx等服务器软件的灵活匹配
正则匹配子域名的典型场景
当通配符请求到达服务器后，真正决定返回哪个应用的是Web服务器配置，Nginx是当前使用最广泛的反向代理软件，在其server_name配置中，既支持通配符,也支持正则表达式。
正则表达式的优势在于精准和灵活，比如你希望只匹配以 api 开头且以 dev 结尾的子域名,可以这样写：
server {
listen 80;
server_name ~^api.(?<env>.+).example.com$;
location / {
proxy_pass http://backend_$env;
}
}这段配置使用 开头声明启用正则匹配，^ 和 限定边界，(?<env>.+) 是命名捕获组,将中间的环境名提取出来传给后端。
如果你希望匹配 dev- 或 test- 开头的子域名，dev-frontend.example.com 和 test-frontend.example.com,可以这样写：
server_name ~^(dev|test)-.+.example.com$;如何选择通配符还是正则
这里需要做一个关键对比。如果只是需要将任意子域名转发到同一台服务器，通配符显然更高效，因为DNS解析速度快且配置简单。如果不同的子域名需要分配到不同端口或不同目录，正则或精确配置更可控。
许多运营者做过实际验证，在多域名配置的场景下，Nginx里直接使用精确的server_name匹配性能最佳，其次是通过正则进行少量规则的匹配，而滥用正则且规则冗长时,每一层代理中正则都会作为一个单独的请求匹配项参与比较。
| 匹配方式 | 工作层级 | 灵活度 | 适用场景 |
|---|---|---|---|
| 域名通配符 | DNS解析 | 低，仅匹配完整标签 | 批量解析、泛解析到统一入口 |
| 正则表达式 | Web服务器配置 | 高，可精准匹配模式 | 多环境路由、动静分离 |
| 精确匹配 | DNS+Web | 最高，但需逐条配置 | 重要业务域名、核心API |
通配符与正则的组合用法
真正规范的线上架构，往往是将二者结合使用，比如你用通配符 .example.com 将所有子域名解析到Nginx服务器，然后在Nginx里维护多组正则规则，实现对 api、admin、static 等不同前缀的精细化分发。
实际操作中会遇到一个常见的坑：如果DNS层配置了通配符，但Nginx里没有匹配的server_name，请求会被Nginx默认的server块接管，建议在配置中显式设置一个默认站点并返回404状态码,避免未被定义的环境泄露服务器信息。
HTTPS证书：匹配多个子域名时的必选项
通配符证书与多域名证书的取舍
浏览器对HTTP请求会提示不安全，想做HTTPS加密就得为子域名配置证书，这一步涉及两种最常见的证书选择：通配符证书和SAN多域名证书。
通配符证书（Wildcard Certificate）能保护 .example.com 这一层级下的所有子域名，适合子域名数量多且命名规律明显的场景，比如为每个客户分一个 clientid.example.com。
SAN证书（Subject Alternative Name）则可以在同一张证书里列出多个完全不相关的域名，example.com、api.another.com、static.example.org，适合业务范围分散、域名不规律的场景。
这两类证书在购买价格上有明显差异，通配符证书通常比单域名证书贵，比同等数量的SAN证书便宜，具体看品牌，业内专家指出，选择证书时优先看兼容性，目前主流系统均已支持SAN扩展,通配符证书对于非同一主域下的跨域场景无能为力。
证书在Nginx中的配置示例
拿到证书后,在Nginx配置中启用HTTPS：
server {
listen 443 ssl;
server_name .example.com;
ssl_certificate /etc/nginx/ssl/example_com_wildcard.crt;
ssl_certificate_key /etc/nginx/ssl/example_com.key;
}配置只监听443端口，且用server_name匹配子域名,浏览器访问任意子域名都能获得有效的加密连接。
常见问题与排查思路
泛解析后子域名无法访问
现象：添加了 .example.com 的A记录，但访问 abc.example.com 仍然超时。
排查步骤：
- 先用
dig abc.example.com确认解析是否生效，如果返回了服务器IP，说明解析正常 - 在服务器上执行
curl -H "Host: abc.example.com" http://127.0.0.1，检查Web服务器是否正确响应 - 如果返回Nginx默认页面而不是你的业务页面，问题在server_name配置段没有匹配到该子域名
正则中特殊字符转义
子域名中包含点号 ，在正则里有“匹配任意字符”的特殊含义，所以在server_name正则中必须写 . 来代表真正的点号,漏掉转义字符是配置正则时最高频的报错原因之一。
匹配多个子域名时优先级
Nginx官方文档的明确指引是：精确匹配的server_name优先于以 开头的通配符名称，通配符名称优先于正则表达式，也就是说，如果你同时配置了 .example.com 和 ~^api. 两条规则，访问 api.example.com 时不会走通配符那条，而是先命中精确匹配或通配符规则,正则总是最后尝试。
Q&A：域名通配符与正则表达式匹配常见问题
配置了 `.example.com后，主域名example.com` 会自动受保护吗？
不会，通配符证书的 只能替代一个标签，不能匹配裸域名，你需要额外为 example.com 申请包含该域名的证书,或者选择同时覆盖裸域和通配符的证书组合。
Nginx正则匹配中，变量引用的语法有哪些版本差异？
Nginx较新版本推荐使用命名捕获组 (?<name>...) 方式，在proxy_pass参数中直接通过 $name 引用，早期版本曾使用 $1 这类数字编号方式，但数字编号在配置复杂、存在多个捕获组时容易出现混淆,主流操作系统发行版自带的Nginx版本均已支持命名捕获组。
多个子域名配置共用同一组正则规则，会在性能上带来很大影响吗？
性能影响有限，Nginx对正则匹配进行了缓存并按照配置文件中出现的顺序依次比较，每条普通规则在常量级开销内完成，常规需求下几十条正则规则不会造成可感知的延迟，但建议正则的数量保持在百余条以内,否则会增加每次请求的匹配成本。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/631363.html
