泛域名解析失效需按dns链路逐层排查：一、确认*记录格式正确且根域名无cname冲突；二、检查智能解析默认线路、cdn兼容性及无关记录干扰；三、直连权威dns验证并比对公共dns缓存；四、核查域名状态、服务商支持及ttl设置。
泛域名解析（*.example.com）不生效，表面看是“通配符没起作用”，实际常因配置细节、缓存机制或系统限制被卡在某个环节。排查不能只盯着“星号有没有填”，得按 DNS 查询链路一层层验证。
一、确认泛解析记录本身是否配置正确
这是最常踩的坑，看似写了 *，实则格式或逻辑有误：
- 主机记录必须严格填 *（一个半角星号），不能是
star、all、*.或留空；Namecheap、阿里云等平台对*的识别非常敏感，多一个点或空格就匹配失败。 - 根域名（
example.com）不能同时存在CNAME记录——RFC 明确禁止。如果 @ 主机已设 CNAME，泛解析的 A/AAAA 记录会被权威 DNS 忽略（即使后台允许提交）。 - 泛解析只匹配**一级子域名**，不覆盖已明确配置的其他记录。例如你设置了
www.example.com → A 1.1.1.1，再加*.example.com → A 2.2.2.2，那么访问www仍走www的 A 记录，不会命中泛解析；但test.example.com或api.example.com就会走泛解析。 - 记录值必须合规：A 记录填 IPv4 地址（如
192.0.2.100），不能带http://或端口；CNAME 值必须是完整域名（如vercel.app），结尾不能有句点（vercel.app.是错误写法）。
二、检查是否被更优先的记录或策略覆盖
泛解析不是“兜底万能键”，很多场景下它根本不会被触发：
IntoDNS.ai
下载
免费 DNS 与邮件安全分析（IntoDNS.ai）：包括 DNSSEC、SPF、DKIM、DMARC、MTA-STS、BIMI、SMTP STARTTLS、FCrDNS、黑名单、发件人要求及报告。
- 如果域名已配置了 智能解析（如按地域、运营商分流），且未设置默认线路，那么所有未匹配到具体线路的请求（包括泛解析匹配的子域名）将无响应——务必补上“默认”线路指向目标 IP。
- 部分 CDN 或 SaaS 平台（如 Vercel、Cloudflare）要求泛解析必须配合特定 CNAME 格式（如
*.example.com → example.vercel.app），且目标域名自身需支持泛解析。若example.vercel.app不支持*.example.vercel.app，你的泛解析就会失效。 - 企业邮箱 MX 记录、TXT 验证记录等，与泛解析无关，但若这些记录配置错误，可能让人误判为“整个域名都不解析”。建议用
dig MX example.com单独验证邮箱相关记录。
三、验证泛解析是否真正进入权威 DNS 并被递归服务器获取
配置正确 ≠ 全网可见。关键看权威 DNS 是否返回了泛解析结果，以及各地递归 DNS 是否已更新：
- 用
dig *.test123.example.com @ns1.your-dns-provider.com（替换为你的权威 DNS 服务器）直连查询。如果返回ANSWER SECTION中有对应 IP，说明权威侧已生效；若返回NOERROR但无 ANSWER，说明记录未生效或被忽略。 - 用公共 DNS 对比测试：
dig *.test123.example.com @8.8.8.8（Google）、@1.1.1.1（Cloudflare）。若某些 DNS 能解析、某些不能，大概率是部分递归 DNS 缓存未刷新，或本地网络劫持了 DNS 请求。 - TTL 值影响极大。如果之前 TTL 设为 86400（24 小时），改泛解析后需等最长 24 小时才能全量生效。修改前应提前数小时把 TTL 调至 300（5 分钟），再更新记录。
四、排除域名状态与服务商限制
泛解析依赖域名整体处于可解析状态：
- 登录注册商后台，确认域名状态为 Active / OK，非
clientHold、serverHold或过期。国内域名未完成实名认证，泛解析会被直接拦截。 - 部分低价域名商或免费 DNS 服务（如某些自建 Bind）不支持泛解析，或对
*解析做额外限制。可临时将 NS 切换至 Cloudflare 或阿里云 DNS，看是否立即生效——快速定位是否为服务商能力问题。 - HTTPS 证书不支持泛解析域名自动签发（Let’s Encrypt 对
*.example.com支持，但需通过 DNS-01 验证；而*.*.example.com这类二级泛解析不被任何主流 CA 支持）。
