www.yourdomain.com 能正常打开。yourdomain.com（apex / 根域名）却显示 This site can't be reached 或 DNS_PROBE_FINISHED_NXDOMAIN。或者反过来。输短版地址的用户碰到错误就直接走了。
最快的修法： 问题几乎总是两件事之一，而且这两件常被混为一谈。(1) 两个主机名都需要一条能正常工作、指向你主机的 DNS 记录。(2) 还要有一条 301 重定向，把访客统一到那个 canonical 版本。先跑下面”原因 1”里的两条 dig 命令，确认是哪一半坏了，再跳到对应步骤。
本文讲清楚两半，并给出 Vercel、Netlify、Firebase 各平台的实现，内容截至 2026 年 6 月。
先判断你属于哪一类
跑这两条命令并对比：
dig yourdomain.com +short
dig www.yourdomain.com +short| 你看到的现象 | 诊断 | 跳转 |
|---|---|---|
| 有一条命令返回为空 | 缺 DNS 记录（NXDOMAIN 的那一边） | 原因 1 |
| 两边都解析、都加载，但都不重定向 | 缺 301 重定向 | 原因 2 |
apex 的 dig 在你的 DNS 商那里报错 | apex 上的 CNAME / 记录冲突 | 原因 3 |
| 两边都解析，但有一个返回 404 | 该域名没加到主机上 | 原因 6 |
| 重定向只在页面渲染后才发生 | 重定向写在了应用代码里，不在平台层 | 原因 5 |
常见原因
按命中率从高到低排列。
1. 只配了一条 DNS 记录
你给 apex 配了 A 记录，但没给 www 配 CNAME；或者反过来，配了 www 的 CNAME 却漏了 apex。没配的那一边返回 NXDOMAIN。
怎么判断：
dig yourdomain.com +short
dig www.yourdomain.com +short其中一个返回为空，就是缺那条记录。（注意：刚加的记录需要时间传播——见修复步骤里的 DNS 传播说明。）
2. 两条 DNS 都配了但没重定向
两个版本都解析、都能加载站点，但各自独立提供内容。Google 会把它当作重复内容，可能拆分你的排名信号；用户看到的 URL 也不一致。
怎么判断：
curl -sI https://yourdomain.com | head -3
curl -sI https://www.yourdomain.com | head -3如果两边都返回 HTTP/2 200（而不是有一边返回带 Location 头、指向另一个的 301），说明缺重定向。
3. apex 上用了 CNAME（违反 RFC）
你在 apex（根域名）上设了 CNAME。按 RFC 1034，CNAME 不能和同名下的任何其它记录共存，而 apex 永远带着 SOA 和 NS 记录——所以 apex 上的 CNAME 本身就是非法的。严格的 DNS 商会直接拒绝；宽松的可能接受，但会破坏 MX 邮件投递、并与 TXT 验证记录冲突。
怎么判断： DNS 商报错如 CNAME cannot coexist with other records at apex，或者只是静默地部分失败。可用的替代方案是某些商提供的扁平化记录——ALIAS、ANAME、或 Cloudflare 的 CNAME flattening——以及较新的 HTTPS 记录类型（RFC 9460）。这些都能实现类似 CNAME 的效果，但在 apex 上是合法的。
4. 主机平台要求特定的 apex / www 取值
如果你把 apex 的 A 记录指向了错误的 IP，或 www 的 CNAME 目标过期了，主机就无法把请求匹配到你的项目。截至 2026 年 6 月：
- Vercel apex：
A记录指向76.76.21.21。www：CNAME指向cname.vercel-dns.com（较新的项目可能显示cname.vercel-dns-0.com——请严格按你项目 Settings > Domains 页面显示的值填）。Vercel 不支持 IPv6，所以不要加AAAA记录。 - Netlify：用外部 DNS 时，apex 指向 Netlify 负载均衡器的
A，www用CNAME指向你的your-site.netlify.app；具体取值控制台会给出。 - Firebase Hosting：添加自定义域名时，会给你两条 apex
A记录让你复制。
怎么判断： 用 dig 取出线上实际的 A / CNAME 值，跟平台控制台为这个确切域名显示的值对比。不一致就改记录。
5. 重定向写在了应用代码里，不在平台层
你在应用里加了重定向（例如 React Router 规则，或一个执行得较晚的 Next.js middleware）。它只在页面或 JS 加载后才触发，所以初始 HTTP 响应仍是 200，爬虫和直接命中永远看不到一条干净的 301。
怎么判断： 即使浏览器最终跳到了 canonical URL，curl -sI 仍返回 200。重定向应该是在平台 / DNS 边缘发出的 HTTP 301，在任何 HTML 被返回之前就完成。
6. www（或 apex）没在主机上配好
你把 yourdomain.com 加到了主机，但没加 www.yourdomain.com（或反过来）。DNS 记录指对了，但主机上没有绑定到那个主机名的项目，于是返回 404 或一个通用的平台错误页。
怎么判断： 打开平台的域名列表（Vercel Settings > Domains、Netlify Domain management > Production domains、Firebase Hosting）。如果只列出一个主机名，就把另一个加上。
最短修复路径
第 1 步：选 canonical
要么 apex，要么 www。定一个，之后别再改。两者权衡：
- Apex（
yourdomain.com）：更短，印在名片上更干净。但在某些主机上需要 apex 扁平化（ALIAS/ANAME/HTTPS），而不是每家注册商都支持。 - www（
www.yourdomain.com）：www主机用普通的CNAME即可，彻底绕开 apex-CNAME 问题，在 CDN 后解析也更快。用第三方（外部）DNS 时，Vercel 和 Netlify 都推荐把www设为 primary，因为 apex 的A记录无法像它们的 anycast 路由那样高效跟随。
如果没有强烈偏好，选 www 作 canonical 摩擦最小。把决定写下来，免得回头自己又纠结。
第 2 步：两条 DNS 记录都配
不管选哪个作 canonical，两个主机名都得有记录——非 canonical 那一个仍需先解析，才能被重定向。
Vercel + www 作 canonical：
CNAME www cname.vercel-dns.com
A @ 76.76.21.21Vercel + apex 作 canonical：
A @ 76.76.21.21
CNAME www cname.vercel-dns.com请用 Settings > Domains 页面显示的确切目标；有些项目显示的是 cname.vercel-dns-0.com。保存后，传播可能从几分钟到 24–48 小时不等；可以在 whatsmydns.net 查进度。
第 3 步：两个域名都加到主机
在 Vercel、Netlify 或 Firebase 控制台里，把 yourdomain.com 和 www.yourdomain.com 两个都加为项目域名。平台只能重定向它认识的主机名。很多平台两个都加上后会自动重定向非 canonical 那个;其它的则需要下面这一步显式配置。
第 4 步：在平台层配重定向
Vercel — 项目 Settings > Domains。把两个主机名都加上，然后在非 canonical 那一行打开菜单选 Edit，把它设成重定向到你的 canonical 域名（Vercel 给的是 307/308 临时/永久选项，选永久那个）。加第二个域名时，Vercel 也会直接给一个 “Redirect to” 一键字段。
Netlify — Domain management > Production domains。把你的 canonical 主机名设为 primary domain;Netlify 会自动 301 重定向另一个。不用改任何文件。
Firebase Hosting — 这件事不在 firebase.json 里做。www↔apex 这种跨域重定向是控制台里的一个选项。在 Firebase 控制台进 Hosting > Add custom domain，输入非 canonical 主机名，勾选 Redirect [domain] to an existing website，填入你的 canonical 域名，点 Continue。（firebase.json 的 redirects 只处理同域名的路径规则，比如 /old → /new，不处理主机到主机的重定向。）
第 5 步：验证重定向
# 非 canonical 应返回 30x，并带一个指向 canonical 主机的 Location 头
curl -sI https://www.yourdomain.com | head -5
# 预期类似：
# HTTP/2 301
# location: https://yourdomain.com/如果两个主机名仍都返回 200，说明重定向还没生效——回去检查第 4 步，或等传播完成。也测一下 http:// 版本;它们应尽量一跳就重定向到 canonical 主机的 https://。
第 6 步：HTML 和 JSON-LD 里的 canonical 也对齐
即便 301 已经能正常工作，渲染出来的页面也应自指 canonical 版本，这样爬虫不必只靠重定向：
<link rel="canonical" href="https://yourdomain.com/article/" />要和你选的 canonical 完全一致——如果 canonical 是 apex，就别写成 https://www.yourdomain.com/article/。rel="canonical" 里的主机名、sitemap 里的 URL、以及 301 的目标，三者必须一致。
怎么确认已经修好
下面四项全过就算搞定：
dig yourdomain.com +short和dig www.yourdomain.com +short都返回一个值。- 对非 canonical 主机跑
curl -sI返回301（或308），并带一个指向 canonical 主机的location:头。 - 对 canonical 主机跑
curl -sI返回200。 - HTML 里的
<link rel="canonical">与 canonical 主机一致。
在 Google Search Console 里，重定向上线后几天内，用 URL 检查工具查两个主机名都应归并到 canonical 版本。
预防建议
- 上线时就定下 canonical，之后别改——切换会带来好几周的 Search Console 变动。
- 第一天就把两条 DNS 都配好（apex 的
A/扁平化记录 和www的CNAME）。 - 立刻把两个主机名都加到主机上，别只加你常输的那个。
- 用
curl -sI确认重定向是真正的301，不是客户端 JS 重定向。 - 让
rel="canonical"、sitemap URL、重定向目标，全部指向同一个主机。
常见问题
该把 apex 还是 www 设为 canonical？
两个对 SEO 都行;只要一个重定向到另一个，Google 没有偏好。用第三方 DNS 时图省事就选 www，因为它用普通 CNAME，避开了 apex 扁平化。选一个并坚持下去。
为什么我的 apex 域名拒绝 CNAME 记录？
按 RFC 1034，CNAME 不能和每个 apex 都带着的 SOA、NS 记录共存。改用你 DNS 商的 ALIAS/ANAME 扁平化、Cloudflare 的 CNAME flattening，或 HTTPS 记录——或者让 apex 指向一个 A/IP，只在 www 上保留 CNAME。
两个版本都返回 200——这真的算问题吗？
算。在两个主机名上提供完全相同的内容却不重定向，会拆分外链权重，还可能让 Google 收录错误的版本。从非 canonical 主机加一条 301 到 canonical 主机。
重定向多久才生效？
DNS 改动的传播视之前的 TTL 而定，从几分钟到 24–48 小时不等。重定向规则本身在 Vercel/Netlify 上保存后通常几秒就生效，但你可能要清浏览器缓存，因为浏览器会激进地缓存 301 响应。
如果我把所有流量都重定向到 www，还需要 apex 记录吗？ 需要。apex 仍得解析到某个地址，主机才能收到请求并发出重定向。apex 记录是死的，重定向就根本没机会触发。