nginx泛域名配置核心是按精确匹配＞前导通配符＞正则的优先级顺序，确保.example.com仅兜底未显式声明的二级域名，且需单独配置example.com和https证书覆盖.example.com及裸域。
生产环境中配置泛域名虚拟主机，核心是让 *.example.com 能正确匹配所有二级域名，同时不干扰已明确声明的特定域名（如 www.example.com、api.example.com），还要兼顾 HTTPS、证书兼容性和请求路由准确性。这不是简单加个 server_name *.example.com 就能跑通的事。
server_name 匹配顺序必须理清
Nginx 按固定优先级匹配 server 块，顺序不可逆：
- 精确匹配（如
server_name www.example.com;）最高优先 - 以
*开头的通配符（如*.example.com）次之 - 以
*结尾的通配符（如www.*）再后 - 正则表达式（如
~^([a-z0-9]+)\.example\.com$）最低
这意味着：如果同时存在 server_name social.example.com; 和 server_name *.example.com;，访问 social.example.com 一定走前者；但若漏配 social.example.com，才会落到泛域名块——所以泛域名块本质是“兜底”，不是“默认”。
泛域名不能覆盖根域名
*.example.com 不匹配 example.com（即裸域）。生产环境必须显式声明：
-
server_name example.com www.example.com;（可共用一个 server 块处理跳转或内容） -
server_name *.example.com;单独一个块，专用于动态二级域名
否则用户直接访问 example.com 会命中默认 server（通常是第一个或 listen 80 里没指定 server_name 的那个），导致内容错乱或 404。
HTTPS 下泛域名需 SAN 证书支持
泛域名 HTTPS 不是靠 Nginx 配置就能生效的，依赖证书本身：
- SSL 证书必须包含
*.example.com（且推荐同时包含example.com） - 使用 Certbot 申请时要明确指定：
certbot -d example.com -d *.example.com - 每个
listen 443 ssl的 server 块，其ssl_certificate必须能覆盖该块的server_name—— 泛域名块不能复用只含www.example.com的证书
否则浏览器会在 TLS 握手阶段报证书无效，根本到不了 Nginx 的 HTTP 路由层。
避免多 server 块间冲突的实操建议
常见陷阱是把泛域名和具体域名写在不同 server 块却共享同一 listen 端口，结果因配置疏漏导致请求被错误分发：
- 所有同端口（如都
listen 80或都listen 443 ssl）的 server 块，server_name值不能重叠，尤其注意大小写和末尾点号（example.com.≠example.com） - 泛域名块建议单独拆出，不要混入其他业务逻辑（比如别在
*.example.com块里硬编码root /var/www/app，而应根据$host动态设置路径或转发） - 上线前务必执行：
nginx -t验证语法 +nginx -T | grep "server_name"查看实际加载的匹配项
泛域名本身不复杂，但容易忽略匹配优先级、证书覆盖和 DNS 解析一致性这三个关键环节。
