网站打不开怎么做DNS查询？域名解析故障排查指南

网站突然打不开时，很多人的第一反应都是先看服务器：CPU 有没有跑满、Nginx 是否正常、数据库是不是挂了，或者干脆先把服务器重启一遍。很多时候你会看到服务器本身没有任何异常，直接访问源站 IP 也能正常响应，可一换成域名就打不开；又或者自己电脑访问一切正常，客户却反馈某些地区一直提示找不到服务器。这时大多是在 DNS 解析出了问题。

域名访问网站之前，需要先通过 DNS 找到对应的服务器 IP。如果 A 记录仍然指向旧服务器、CNAME 配置错误、本地 DNS 缓存没有刷新，或者不同运营商的递归 DNS 返回结果不一致，最终表现出来都可能是“网站打不开”。

所以，碰到域名突然无法访问时，与其一上来就折腾服务器，不如先查清楚：这个域名现在到底被解析到了哪里？下面就按照实际网站运维中的排查顺序，看看如何通过 DNS 查询快速判断故障究竟出在域名解析、CDN、网络线路还是源站服务器。

一、网站打不开，为什么要先检查DNS？

用户在浏览器中输入一个域名之后，并不会直接连接网站服务器。正常的访问过程大致是：

用户输入域名
    ↓
本地 DNS 缓存
    ↓
递归 DNS 服务器
    ↓
权威 DNS 服务器
    ↓
A / AAAA / CNAME 解析记录
    ↓
CDN 节点或源站 IP
    ↓
网站服务器

也就是说，在浏览器真正建立 HTTP 或 HTTPS 连接之前，首先要完成 DNS 查询。如果 DNS 没有返回正确地址，后面的服务器即使完全正常，用户一样打不开网站。

例如网站原本部署在：

103.10.1.10

后来服务器迁移到了：

103.20.2.20

但 DNS 记录仍然返回旧 IP：

example.com → 103.10.1.10

这时候新服务器配置得再完善也没有意义，因为用户请求压根没有到达新服务器。实际排障时，可以先通过几个现象快速判断是否值得优先检查 DNS：

因此，网站打不开时，DNS 查询通常是成本最低、定位速度最快的一步。

二、网站打不开怎么做DNS查询？

排查 DNS 时，不需要一开始就研究大量复杂记录。

对于普通网站无法访问的问题，首先看三个东西就够了：

• A 记录

• AAAA 记录

• CNAME 记录

其中最关键的问题是：

当前查询到的 IP 或 CNAME，是否和你实际配置的一致？

1. 使用在线DNS查询工具

如果不习惯使用命令行，可以直接通过在线 DNS 查询工具检查。

例如使用 Chahu DNS 查询，输入需要排查的域名后，可以查看当前返回的 A、AAAA、CNAME 等记录。

假设查询：

www.example.com

得到：

A → 203.0.113.20

这时候首先去服务器或 CDN 控制台确认：

203.0.113.20

是不是你现在真正使用的服务器地址。

如果后台已经换成：

203.0.113.80

而 DNS 仍然返回.20，问题基本已经定位到了 DNS 记录或缓存这一层。在线查询还有一个好处，就是可以避免只看自己电脑里的 DNS 缓存结果。

2. 使用nslookup查询

Windows、macOS 和 Linux 都可以通过命令行查询 DNS。

Windows 中可以使用：

nslookup example.com

正常情况下会返回类似：

Name:    example.com
Address: 203.0.113.20

如果出现：

Non-existent domain

或者完全查不到有效地址，就需要检查域名本身和 DNS 配置。

也可以指定公共 DNS，例如：

nslookup example.com 8.8.8.8

然后再换一个 DNS：

nslookup example.com 1.1.1.1

如果不同 DNS 返回的结果不同，就说明问题可能和 DNS 缓存或同步有关。

3. 使用dig进一步检查

Linux、macOS 或安装了相关工具的环境，可以使用：

dig example.com

只想查看 A 记录时：

dig example.com A

查询 CNAME：

dig www.example.com CNAME

查看指定 DNS：

dig @8.8.8.8 example.com

dig相比nslookup能看到的信息更多，特别适合排查 TTL、权威 DNS、CNAME 链路等问题。

不过对于普通站长来说，核心仍然不是工具本身，而是确认：

不同查询方式得到的解析结果，到底是不是你预期的结果。

三、A记录和CNAME最常见的4种解析故障

DNS 能查到结果，并不代表解析配置一定没有问题。

很多网站打不开，恰恰是因为 DNS “有结果，但结果错了”。

1. A记录还指向旧服务器

这是服务器迁移以后非常常见的问题。

例如旧服务器：

198.51.100.10

新服务器：

198.51.100.50

结果 DNS 查询仍然是：

example.com → 198.51.100.10

这时候要检查：

• DNS 控制台中的 A 记录是否真的修改成功；

• 是否修改错了域名；

• @和www是否分别配置；

• 是否存在多个 A 记录；

• 旧记录是否仍然保留。

不少网站迁移后会出现一种情况：

example.com → 新服务器
www.example.com → 旧服务器

于是访问不带www的域名正常，访问www却打不开。

因此排查时不要只查一个地址，至少同时检查：

example.com
www.example.com

2. CNAME配置错误

如果网站接入了 CDN，通常不会直接把域名解析到某个固定 IP，而是使用 CNAME。

例如 CDN 服务商提供：

abc123.cdn-provider.com

DNS 中应该配置：

www.example.com
        ↓
CNAME
        ↓
abc123.cdn-provider.com

如果 CNAME 拼写错误、记录没有保存成功，或者仍然指向旧 CDN 地址，网站就可能出现访问失败。

所以接入 CDN 后打不开网站，第一件事应该检查：

www.example.com 的 CNAME

是否和 CDN 控制台提供的目标域名完全一致。

这里尤其要注意复制过程中多出来的字符、错误的主机记录以及旧配置没有删除等问题。

3. A记录和CNAME发生冲突

同一个主机名通常不应该同时存在 A 和 CNAME。

例如：

www.example.com → A → 203.0.113.20

同时又配置：

www.example.com → CNAME → abc.cdn.com

这类冲突配置可能导致 DNS 服务商直接不允许保存，也可能在迁移或历史配置中留下异常记录。

如果网站刚接入 CDN，建议重新检查原有 A 记录是否已经按照服务商要求处理。

尤其不要看到“以前网站就是这样配置的”，就默认旧记录可以继续留着。

4. AAAA记录指向了错误的IPv6服务器

这是一个非常容易被忽略的问题。

假设网站的 A 记录正常：

A → 203.0.113.20

但同时存在：

AAAA → 2001:db8::1234

而这个 IPv6 地址已经失效。

部分支持 IPv6 的用户设备可能会优先访问 AAAA 记录，于是就出现一种很奇怪的现象：

有些人访问完全正常，有些人却一直打不开。

如果服务器并没有正常部署 IPv6，而 DNS 中还保留着旧 AAAA 记录，可以重点检查这一项。

四、为什么自己能打开，其他地区却打不开？

网站故障中最麻烦的一类情况，不是所有人都打不开，而是：

自己这里秒开，客户那里却始终访问失败。

这种情况很容易让运维误以为“网站明明没问题”。

实际上，DNS 并不是全球所有用户同时拿到同一个缓存结果。

DNS缓存和TTL会造成解析不同步

假设网站之前的解析为：

example.com → 103.10.10.10
TTL = 3600

现在修改成：

example.com → 103.20.20.20

权威 DNS 上的记录虽然已经修改，但不同地区的递归 DNS 可能仍然缓存旧结果。

于是短时间内可能出现：

上海电信    → 103.20.20.20
北京联通    → 103.10.10.10
广州移动    → 103.10.10.10
海外 DNS   → 103.20.20.20

这样一来，访问体验自然就不一样。

如果旧服务器已经关闭，那么仍然拿到旧 IP 的用户就会直接打不开网站。

这时候不要只查自己电脑

本地运行一次：

nslookup example.com

只能说明你当前使用的 DNS 返回了什么。

并不能代表其他省份、运营商或海外网络看到的解析结果。

更有效的方法是使用多节点 DNS 查询，例如通过 Chahu 查看不同地区、不同运营商对同一个域名的解析结果。

如果绝大多数节点已经返回新 IP，而少部分节点仍然是旧 IP，那么问题通常更接近：

• TTL 尚未完全过期；

• 部分递归 DNS 仍有缓存；

• 运营商 DNS 更新较慢。

如果出现完全不相关的 IP，则需要进一步排查 DNS 污染、解析线路配置或 CDN 调度。

五、DNS正常但网站仍打不开，该查哪里？

如果查询结果已经确认：

example.com → 正确 IP

这只能说明 DNS 这一关基本通过了。

后面还有 TCP、TLS、HTTP、CDN 和源站等多个环节。

这时候就不要继续围着 DNS 转，而应该往下一层检查。

1. 先做Ping测试

可以先尝试：

ping example.com

重点看两件事：

第一，Ping 时解析出来的 IP 是否仍然正确。

第二，目标网络是否存在明显丢包或延迟异常。

如果需要看多个地区，可以继续使用 Chahu 的多节点 Ping 测试，对比不同网络下的连通情况。不过这里要注意：

Ping 不通不等于网站一定打不开。

很多 CDN、云服务器或者防火墙会主动禁用 ICMP，因此 Ping 超时只能作为参考，不能直接认定服务器故障。

2. 检查80和443端口

对于普通网站，最重要的通常是：

TCP 80
TCP 443

假设 DNS 查询正常：

example.com → 203.0.113.20

但 443 端口无法建立连接，那么问题已经不再是 DNS。可能原因包括：

• Nginx 或 Apache 没有启动；

• 云服务器安全组未开放 443；

• 系统防火墙拦截；

• CDN 节点无法连接源站；

• Web 服务监听地址错误。

尤其是 HTTPS 网站，如果 443 不通，浏览器基本无法正常访问。

3. 再做HTTP/HTTPS测试

网站真正提供服务使用的是 HTTP/HTTPS。所以 DNS 和 Ping 都正常后，最好继续测试 HTTP 响应。重点观察：

• HTTP 状态码；

• TCP 建连；

• TLS 握手；

• TTFB；

• 页面是否成功返回。

不同状态码对应的问题方向也不同：

例如：

DNS 正常
Ping 正常
HTTPS 返回 502

这种情况继续修改 DNS 基本没有意义，应该重点排查 CDN 回源或者源站 Web 服务。

六、浏览器常见错误分别代表什么问题？

其实排查网站打不开的问题，最忌讳的就是一句大而无当的“网页报错了”。浏览器弹出的那行英文字母，往往已经把最直接的线索甩到了我们脸上。遇到问题时，第一步先把那行错误代码复制下来，然后再对着下面的几种常见情况去逐一排查：

1. DNS_PROBE_FINISHED_NXDOMAIN

这句话通俗点说，就是“网络上的导航仪根本找不到这个域名”。

如果你的用户看到这个，大概率是域名解析层直接断了。可以顺着这个思路查：

• 域名本身： 看看域名是不是欠费过期了，或者域名状态被注册商锁了。

• 解析记录： 检查 DNS 的 NS（ Name Server ）配置有没有乱，A 记录或者 CNAME 记录是不是被误删了，或者刚改完解析还没生效。

• 安全配置： 如果开过 DNSSEC，瞅瞅是不是签名配错了导致解析校验失败。

排查建议： 先用站长工具或者终端查一下公开 DNS。如果连第三方工具都什么也查不到，那就不用折腾服务器了，赶紧去域名控制台看解析。

2. ERR_NAME_NOT_RESOLVED

这个也是 DNS 报错，但跟上边的 NXDOMAIN 有点区别，它往往更偏向于客户端（也就是你自己电脑/网络）查不到解析。

排查建议： 直接在命令行打nslookup 你的域名。

• 如果外网和公共 DNS（比如 114 或 8.8.8.8）能查到 IP，但你本地电脑查不到，问题肯定在本地：

  • 检查电脑手动设的 DNS 是不是挂了。

  • 清一下本地 DNS 缓存（ Windows 执行ipconfig /flushdns）。

  • 重启下路由器，或者怀疑是不是运营商 ISP 的 DNS 在抽风。

3. ERR_CONNECTION_TIMED_OUT

这个报错意味着：域名已经成功找到了 IP，但你的电脑发过去请求，对方迟迟没有给你任何回应，直到超时。

既然 IP 能拿到，说明 DNS 没大问题，这时候就要往网络链路和服务器方向去想了：

• 服务器状态： 机子是不是死机了？或者 CPU/内存爆了导致响应不过来？

• 网络与线路： 中间的网络线路是不是断了，或者丢包极其严重？

• 安全防护： 检查云服务器的安全组有没有放行端口，服务器内部的防火墙（如 iptables/ufw）是不是把请求拦截了。

• CDN 与源站： 如果用了 CDN，看下是节点没连上源站，还是源站本身网路堵死了。

4. ERR_CONNECTION_REFUSED

超时（ TIMED_OUT ）是“压根没回应”，而拒绝连接（ REFUSED ）则是“目标服务器收到了请求，但明确把你弹回来了”。

这说明网络通路是顺畅的，IP 和端口也找到了，但目标端口根本没有程序在监听，或者被直接拒绝了。

比如 DNS 和 IP 都正常，但请求https时报这个错，通常排查：

• 服务有没有开： Nginx、Apache 或者你的 Node/Java 程序到底跑起来没有？

• 端口监听： Web 服务是不是漏配了 443 端口？或者只监听了127.0.0.1而没监听0.0.0.0？

• 容器映射： 如果用 Docker 跑的服务，检查-p端口映射有没有漏写或者写错。

5. SSL 证书错误

SSL 报错看着是加密问题，但很多时候它的根子其实在 DNS 解析不一致上。

最典型的场景：你刚给网站换了新服务器、切了新 IP，或者重新部署了证书。但因为各地的 DNS 刷新有延迟，一部分地区访问的是新服务器（证书正常），另一部分地区还在请求旧服务器（证书已过期或未配置），这就导致“有人访问正常，有人提示证书不安全”。

排查建议： 遇到这种报错，别急着重跑证书脚本，先看报错用户的实际访问情况：

• 让他们 ping 一下域名，看解析出来的 IP 到底是新站还是旧站。

• 检查 CDN 上面部署的证书状态，看是不是只更新了源站，忘更新 CDN 了。

• 确认一下证书的域名匹配范围，看看是不是漏掉了www子域名或者根域名。

七、怎么区分DNS、CDN和源站故障？

网站访问涉及很多环节，真正高效的排障方式并不是一次把所有配置翻一遍，而是逐层排除。可以参考下面这张表：

八、网站打不开时，推荐按照这个顺序排查

如果不确定从哪里开始，可以直接按照下面这套顺序执行：

网站打不开
   ↓
① 查询DNS
   ↓
能否获得IP或CNAME？
 ├─ 否 → 检查域名、NS、A/CNAME
 └─ 是
      ↓
② 返回结果是否正确？
 ├─ 否 → 检查DNS记录、TTL、缓存
 └─ 是
      ↓
③ 多地区DNS结果是否一致？
 ├─ 否 → 检查区域DNS缓存、线路解析
 └─ 是
      ↓
④ 测试Ping / TCP 80 / 443
      ↓
⑤ 测试HTTP/HTTPS
      ↓
⑥ 检查CDN节点与回源
      ↓
⑦ 检查源站服务器

这套顺序最大的好处，是可以先把不同故障层分开。例如 DNS 都没有解析成功，就没有必要先去调 Nginx；如果 DNS 已经正确，而网站返回的是 502，也没有必要不停刷新 DNS 缓存。

实际排障中，最浪费时间的往往不是问题有多复杂，而是一开始就在错误的层级反复修改配置。

九、修改DNS以后多久才能恢复？

不少站长修改完 A 记录或者 CNAME 后，会不断刷新网页，发现十几分钟过去还没恢复，就以为 DNS 配置错了。

实际上，DNS 修改并不代表所有用户会在同一秒拿到新记录。

影响更新时间的主要因素是 TTL（Time To Live）。

例如原解析记录：

TTL = 3600

代表递归 DNS 理论上可以缓存这条记录 3600 秒，也就是约 1 小时。

如果在缓存尚未过期时修改 IP，那么部分 DNS 服务器可能仍然继续返回旧地址。

除此之外，还可能受到：

• 本地操作系统 DNS 缓存；

• 浏览器缓存；

• 路由器 DNS 缓存；

• ISP 递归 DNS；

• 公共 DNS 更新状态；

等因素影响。因此修改 DNS 后，最好不要只在一台电脑上反复测试，而是通过多个 DNS 节点确认新的解析结果是否已经逐步生效。

服务器迁移前可以提前降低TTL

如果提前知道要更换服务器或 CDN，可以在正式切换之前把 TTL 调低。比如原来是：

3600

可以提前调整为：

300

等旧 TTL 基本失效以后再迁移服务器。这样切换时，新旧 IP 同时存在的时间通常会明显缩短。迁移完成并确认业务稳定以后，再根据实际情况恢复正常 TTL。

网站打不开只是最终表现，背后的原因可能完全不同。有时候只是 A 记录还指向旧 IP，有时候是 CNAME 没有正确接入 CDN，有时候则是 DNS 已经完全正常，真正的问题出在 443 端口、SSL、CDN 回源或者源站服务。所以实际排查时，可以先从 DNS 开始。

先确认域名能不能正常解析，再确认解析出来的 IP 或 CNAME 是否正确；如果只是部分地区异常，再通过 Chahu 这类多节点查询工具对比不同运营商的 DNS 返回结果。DNS 确认正常以后，再继续往 Ping、TCP、HTTP、CDN 和源站方向检查。

按照这种从前往后的方式逐层排除，通常比一看到网站打不开就反复重启服务器，更容易找到真正的问题所在。DNS 查询并不是一个单独的测速动作，它更像是整个网站故障排查流程的第一道分界线：DNS 都没走通，就先别碰服务器；DNS 已经正确，就继续往下一层查。