Nginx泛域名冲突排查核心是确认实际匹配块：*.api.example.com优先于*.example.com匹配二级子域，需显式配置或正则支持；未匹配时落入default_server或首个块，须用nginx -T和curl -H "Host"验证真实路由。
排查多级泛域名 server_name 的隐蔽冲突，核心不是“有没有配”，而是“谁真正被选中”——Nginx 不报错、不警告，只悄悄把请求交给错误的 server 块。比如你配了 *.example.com 和 *.api.example.com，访问 dev.api.example.com 却进了前者，页面能打开但证书错、日志乱、静态资源 404，问题极难定位。
确认泛域名是否真在生效范围里
通配符有严格层级限制：*.example.com 只匹配一级子域（www.example.com、api.example.com），不匹配根域（example.com）也不匹配二级子域（dev.api.example.com）。若需支持后者，必须单独加 *.api.example.com 或显式列出 dev.api.example.com。
- 用
openssl x509 -in cert.pem -text -noout | grep "DNS:"检查证书 SAN 是否包含对应泛域名（如DNS:*.api.example.com） - 运行
nginx -T 2>/dev/null | grep "server_name" -A 2，看所有泛域名配置是否都被加载，尤其注意文件加载顺序（字典序）是否导致后定义的被覆盖
验证匹配优先级是否被高阶规则截断
Nginx 匹配顺序是：精确匹配 > 前导通配符（*.example.com） > 正则匹配。多个泛域名共存时，最长前缀通配符胜出。例如：
-
server_name *.api.example.com;和server_name *.example.com;同时存在 →dev.api.example.com会命中前者 -
server_name ~^([a-z]+)\.api\.example\.com$;是正则，一旦匹配立即终止，后续块完全不参与比对 - 如果漏写了
example.com，而只配了*.example.com，那么直接访问根域就会落到default_server或第一个块
用真实请求穿透 DNS 和缓存验证路由路径
别信配置名或目录位置，用带 Host 头的直连请求验证实际走向：
- 执行
curl -v -H "Host: dev.api.example.com" http://127.0.0.1，观察返回的Server头、响应内容、状态码，再对比 access_log 路径 - 在疑似“兜底”的泛域名块里临时加
return 444;或写独立日志：access_log /var/log/nginx/dev-api-catch.log;，看是否有非预期请求打进来 - 把高优先级泛域名配置（如
*.api.example.com）改名为00-api-wildcard.conf，重启后测试是否原先进错块的请求恢复正常
检查 default_server 和隐式兜底是否干扰泛域名逻辑
没设 default_server 不代表安全。Nginx 会把同一端口下第一个定义的 server 块当作隐式兜底——当 Host 头为空、非法或不匹配任何 server_name 时（如 IP 直接访问、HTTP/1.0 请求、SNI 缺失的老设备），流量就全进这里。
- 运行
nginx -T 2>/dev/null | grep "listen.*443" -A 5，确认 HTTPS 端口下哪个块带default_server，且该块是否意外包含了泛域名配置 - 确保兜底块（如
99-default.conf）明确声明listen 443 ssl default_server，且server_name仅留空或写一个无意义占位符（如_），避免与业务泛域名冲突 - 检查是否在同一个
server块里混用了listen 80和listen 443 ssl——SSL 指令在纯 HTTP 块中无效，容易引发证书加载失败却无提示
