你在 DNS 控制台加了一条 A 记录，ping 也能通，可浏览器打开 example.com 就是一直转圈，要么跳出来一个陌生的默认页面；换成 www.example.com 却一切正常。或者反过来：www 好好的，根域名打不开。这种“一半能用”的故障，几乎都源于同一个误解：把“DNS 解析成功”当成了“网站配置完成”。
实际上，一次网站访问要经过三个独立环节：DNS 解析（把名字变成 IP）、网络连通（公网能连上服务器的 80/443 端口）、站点匹配（Web 服务根据请求里的主机名找到对应的网站配置）。DNS 记录只是第一步的凭证，后面两步没配好，浏览器照样打不开。下面按这个链路逐层排查，比反复删了重建省时间得多。
先理解：根域名和 www 是两个完全不同的名字
example.com（常叫根域名、裸域名、apex）和 www.example.com，在 DNS 眼里是两个独立的主机名，各自需要记录。最常见的做法是：
- 根域名加一条 A 记录指向服务器的 IPv4 地址（有 IPv6 再加一条 AAAA）；
- www 加一条 A 记录，或者加一条 CNAME 指向根域名（www.example.com → example.com）。
注意一个经典限制：根域名一般不建议直接挂 CNAME（这是 DNS 协议层面的约束），部分服务商提供 ALIAS / ANAME 或“CNAME 展开”功能来曲线实现，具体以你所用 DNS 服务商的文档为准。拿不准就给根域名用 A 记录，这是兼容性最好的方案。
“只配了 www，根域名自然也能用”是新手最高频的假设，反过来也一样。两边都要配，两边都要单独验证。
第一步：验证 DNS——别用浏览器，用 dig
浏览器有缓存，ping 走的也不一定是网站端口。用 dig 直接问公共解析器，看到的才是真实生效的值：
dig example.com +short dig www.example.com +short dig @8.8.8.8 example.com A +short
逐项核对：返回的 IP 是不是你的服务器？有没有残留的旧记录？IPv6 的 AAAA 记录是不是还指向已经退役的机器——很多人换服务器只改了 A 记录，AAAA 还留着旧 IP，在 IPv6 优先的网络下就会出现“别人能打开、我打不开”的间歇故障。
刚改完记录不生效，先看 TTL：dig example.com 的返回里有 TTL 秒数，缓存过期之前全球不会同时生效。用 dig +trace example.com 可以看到权威服务器上的真实值，帮你区分“DNS 没配对”还是“缓存还没过期”。
第二步：验证网络连通——端口和安全组
DNS 对了，下一步确认公网能不能连到你的 80/443 端口：
curl -v http://example.com --connect-timeout 5 curl -v https://example.com --connect-timeout 5
连不上时按这个顺序查：① 云平台安全组有没有放行 80、443；② 服务器本机防火墙（ufw / firewalld）；③ Web 服务到底有没有在监听公网地址（ss -tlnp | grep -E ':(80|443)'）。记住：服务器上 curl localhost 能通，不代表公网能通，这是两条完全不同的路径。
第三步：验证站点匹配——主机名绑定
请求到了服务器，Web 服务还要根据 Host 头找到对应的网站。以 Nginx 为例：
server {
listen 80;
server_name example.com www.example.com;
...
}
如果你只在 server_name 里写了 www.example.com，那么直接访问根域名的请求就会落到默认站点——经常是一个空白页，甚至别人的页面。Apache 对应的是 ServerName / ServerAlias。用面板（宝塔、1Panel 等）建站时填写的“域名”列表，干的就是这个绑定：漏填哪个，哪个就打不开。
HTTPS 还要多确认一层：证书覆盖了哪些主机名。curl -vI https://example.com 2>&1 | grep -E 'subject|expire'，或直接看浏览器地址栏的证书详情。证书只签了 www，根域名就会报证书错误——这是证书问题，不是 DNS 问题，别混在一起查。
收尾：选定一个主地址，另一个做 301 重定向
两个入口都通了之后，不要让它们长期并存：搜索引擎会把 example.com 和 www.example.com 当成两个站点，分散权重和统计。选定一个（统一用 www，或统一用根域名），另一个做 301 永久重定向：
# 不带 www 的统一跳转到 www 版本
server {
listen 80;
server_name example.com;
return 301 https://www.example.com$request_uri;
}
用 curl -I http://example.com 确认返回的是 301 而不是 200，这才算重定向配对了。
给自己留一张配置表
每次改动前记下：主机名、记录类型、目标地址、是否经过 CDN/代理、用途；每次只改一层，记下变更时间，再用手机流量（独立网络）复查。开了 CDN 代理后，dig 看到的可能是 CDN 节点 IP，这是正常的——此时还要单独确认“CDN 到源站”这一段是否正常，别只看边缘节点。源站可以用改本地 hosts 的方式单独验证。
这张表还有一个长期价值：半年后你要迁移服务器、换 DNS 服务商或交接给别人时，它就是唯一的事实来源。很多“改了个小记录结果全站挂”的事故，根因都是没人记得当初为什么加那条解析。配置表不用花哨，一个表格记下“主机名 / 类型 / 值 / TTL / 用途 / 变更时间”六列就够了。
常见坑
只配了 www，根域名没配。两边是独立的主机名，逐一加记录、逐一验证，没有“顺带生效”这回事。
AAAA 记录指向旧机器。IPv6 优先时部分用户会被带到旧服务器，表现为间歇性打不开，极难排查，先查它。
改完 DNS 就承诺“几分钟生效”。TTL 和各地缓存决定生效时间，重要迁移前先把 TTL 调小，稳定后再调回去。
开了 CDN 代理还按直连思路排查。代理后链路变成两段，边缘节点正常不代表源站正常，分段验证。
常见问题
根域名到底能不能用 CNAME？按 DNS 协议，apex 点不建议直接挂 CNAME；部分服务商提供 ALIAS/ANAME 或 CNAME 展开能力。拿不准就用 A 记录，兼容性最好。
dig 返回的是 CDN 的 IP，算正常吗？如果你开了 CDN 代理，正常。此时排查分两段：用户到 CDN、CDN 到源站，源站可通过改本地 hosts 单独验证。
HTTP 能打开，HTTPS 报证书错？先看证书的签发对象包不包含你访问的主机名，再看是否过期、证书链是否完整。证书故障和 DNS 故障分开查。
两个地址都能开，需要二选一吗？需要。长期并存会分散搜索权重和访问统计，选定一个做 301 到另一个。
参考资料
资料核查：2026年10月8日。本文根据公开官方资料独立整理撰写；封面为 AI 生成的概念插画，不是产品实拍。
