检查域名解析结果最直接的办法不是刷新浏览器，而是在命令行里用 nslookup 或 dig 向指定 DNS 服务器发起查询，看权威 DNS 返回的记录、IP 和 TTL 是否正确。只要这条链路能对上，剩下的就是缓存和传播时间的问题,跟网站程序本身关系不大。
先搞清楚一次解析要走哪几段路
很多人一遇到"网站打不开"就怀疑服务器挂了，其实域名解析是一段有明确节点的旅程，理解这段路,后面排查才不会乱。
浏览器不是直接问权威 DNS 的
你输入域名后，请求会先落到本地 DNS（运营商分配的，或者你手动设的 223.5.5.5、8.8.8.8 这类公共 DNS），本地 DNS 如果没有缓存，会去问根服务器、顶级域服务器，最后问到你的域名所指向的权威 DNS也就是你在域名服务商那里配置 NS 记录时绑定的那台服务器。
权威 DNS 返回 A 记录、AAAA 记录、CNAME 记录，本地 DNS 缓存一份，再把结果给你，所以检查解析结果时，你查的其实是"某一台 DNS 服务器此刻认为这个域名指向哪里"，而不是"全世界所有服务器都这么认为"。
TTL 决定了你看到的是新数据还是旧数据
每条解析记录都有一个 TTL，单位是秒，常见的配置是 600 秒（10 分钟）和 3600 秒（1 小时），TTL 没到期，本地 DNS 就会一直返回缓存里的旧结果。
行业共识认为，修改解析前把 TTL 临时调小到 60 到 300 秒，等旧 TTL 过期后再改指向，能明显减少切换期间的访问异常,这个习惯比事后反复刷新缓存管用得多。
nslookup和dig检查域名解析结果有什么区别
两个工具干的是同一件事，只是使用场景不同，Windows 自带 nslookup，Linux 和 macOS 一般自带 dig，日常检查用哪个都行，但 dig 的输出信息更全,适合深挖。
Windows 下用 nslookup 检查解析结果
打开命令提示符,直接敲：
nslookup example.com用系统默认 DNS 查询 A 记录nslookup example.com 223.5.5.5指定用阿里公共 DNS 查询nslookup example.com 8.8.8.8指定用 Google 公共 DNS 查询nslookup -type=MX example.com查邮件记录nslookup -type=NS example.com查这个域名委托给了哪几台权威 DNS
结果里有两段信息：上面一段是"Server"和"Address"，告诉你是哪台 DNS 在回答；下面一段才是真正的解析结果，看结果时别只看 IP,先确认回答你的服务器是不是你想查的那台。
Linux 和 macOS 用 dig 更细
dig 的常用写法：
dig example.com +short只输出 IP，适合快速确认dig @8.8.8.8 example.com A指定 DNS 服务器查 A 记录dig example.com NS +short看 NS 记录dig +trace example.com从根服务器一路追到权威 DNS，完整展示解析路径dig example.com CNAME查是否配置了 CNAME，接 CDN 的站点必看
+trace 是排查"解析到底卡在哪一层"的利器，trace 走到某一级就没有应答，问题基本锁定在那一段,而不是你本地网络。
换一台 DNS 再查一次，是对比的关键
这是最容易被跳过的一步，同一个域名，用运营商 DNS 查出来是旧 IP，用 8.8.8.8 查出来是新 IP，说明权威记录已经更新，只是部分本地 DNS 还在缓存期，此时不需要改配置，等 TTL 走完即可。
如果两台 DNS 查出来都是旧 IP，那就要回到权威 DNS 那边看记录到底改没改、有没有保存成功。
域名解析失败怎么排查：从权威DNS到本地缓存逐层验证
解析失败的表现有很多种：返回 NXDOMAIN、返回 SERVFAIL、返回的 IP 打不开、时好时坏，按下面的顺序走,基本能定位。
第一步：确认权威 DNS 有没有正常应答
先查 NS 记录,看域名委托给了哪几台服务器：
dig example.com NS +short
然后直接向其中一台权威 DNS 发起查询：
dig @ns1.example.com example.com A
如果权威 DNS 直接返回正确 IP，说明记录配置没问题，问题出在中间的缓存层，如果权威 DNS 报 SERVFAIL 或者没有应答，那就是权威服务器本身的问题,需要联系域名服务商确认解析服务状态。
第二步：确认记录类型和主机记录没写错
这是实操中最常见的坑,检查清单如下：
- 主机记录填的是 还是
www，还是写成了完整域名 - 记录类型选的是 A 还是 CNAME，两者不能在同一主机名上共存
- 记录值末尾有没有多打一个点，有没有带 http:// 前缀
- CNAME 指向的目标域名本身能不能解析出来
子域名解析不出来,九成是主机记录写错了层级。
第三步：清掉本地缓存再查
本机也有 DNS 缓存，Windows 下执行 ipconfig /flushdns；macOS 下执行 sudo dscacheutil -flushcache 和 sudo killall -HUP mDNSResponder；Linux 用 systemd-resolved 的系统执行 resolvectl flush-caches。
清完再查一次，如果结果变了，说明之前看到的就是本地缓存，浏览器自己还有一层缓存，Chrome 可以在 chrome://net-internals/#dns 里清。
第四步：排除本地网络和 hosts 文件干扰
检查一下 hosts 文件里有没有手动写过这个域名，Windows 在 C:\Windows\System32\drivers\etc\hosts，macOS 和 Linux 在 /etc/hosts，这里写死的记录优先级高于 DNS 查询，很容易造成"别人能打开我打不开"的假象。
国内多地检查域名解析结果不一致怎么办
做站点的人经常会遇到这种情况：自己在公司查是正常的，客户在另一个省份反馈打不开，这时候单点查询没有意义,要看多地结果。
用在线工具做多地探测
主流做法是用 DNS 多地检测工具，输入域名和记录类型，它会从国内多个省份、多家运营商的递归 DNS 同时发起查询，把每个节点的返回 IP 列出来，常用的有站长工具的 DNS 查询、DNSPod 的解析检测、17CE 的 DNS 检测，这些都有免费额度，据行业内的普遍反馈,免费版覆盖的节点数量够日常判断用。
看多地结果时注意两点：一是不同地区返回不同 IP，如果是接了 CDN 或者用了智能解析，这是正常现象，不算故障；二是部分地区返回 NXDOMAIN 或者空结果，那才是真的有问题，通常是该地区的本地 DNS 缓存了旧的 NS 记录。
智能解析场景下的判断标准
用了分线路解析的域名，判断标准不是"所有地方结果一致"，而是"每个地区返回的 IP 属于该地区应该命中的线路"，比如华东返回的是华东节点的 IP，这就是对的，要验证线路配置，可以在权威 DNS 后台看解析线路的设置,再对照多地检测结果。
常见解析异常对照表
| 查询现象 | 大概率原因 | 下一步动作 |
|---|---|---|
| 返回 NXDOMAIN | 记录不存在，或 NS 未生效 | 查权威 DNS 是否有该主机记录 |
| 返回 SERVFAIL | 权威 DNS 异常或 DNSSEC 校验失败 | 直接向权威 DNS 查询验证 |
| 返回旧 IP | 本地或运营商 DNS 缓存未过期 | 等 TTL，或换公共 DNS 对比 |
| 多地结果不一致 | 智能解析或 CDN 调度 | 对照线路配置判断是否正常 |
| 解析正常但打不开 | 服务器、端口、证书或防火墙问题 | 用 IP 直连测试，排查 Web 服务 |
业内专家指出，把"解析层"和"应用层"分开验证，是缩短故障定位时间最有效的方式，先确认 DNS 返回的 IP 是对的，再去查服务器上 80 和 443 端口通不通,顺序反了就会绕远路。
关于检查域名解析结果的常见问题
检查域名解析结果时返回了两个不同 IP 是怎么回事
一个域名配置了多条 A 记录，DNS 会轮询返回，这是正常的负载均衡做法，接了 CDN 的站点，不同地区、不同运营商返回不同 IP 也属正常调度，只有当某个 IP 已经下线、却还在被返回时，才需要去权威 DNS 删掉那条记录。
域名解析生效要多久，改完一直没变怎么办
生效时间取决于原来的 TTL，TTL 设的是 3600 秒，最坏情况要等一小时；设的是 600 秒，十分钟左右，改完没变化，先用 dig @权威DNS地址 域名 确认权威那边已经是新记录，再用不同公共 DNS 对比，权威已经是新的、公共 DNS 还是旧的，剩下的只是等待,不需要重复操作。
检查域名解析结果正常但网站打不开，问题在哪
解析正常只说明域名能指向正确的 IP，不保证服务可用，此时用 ping 或 telnet IP 443 测端口连通性，再在服务器上确认 Web 服务进程是否在跑、证书是否过期、安全组和防火墙是否放行了对应端口，解析和建站是两件事,分开查就不会互相干扰。
把检查顺序固定下来：先看权威 DNS 返回什么，再看不同递归 DNS 返回什么，最后才动本地缓存，这条线走顺了，绝大多数"网站打不开"的怀疑都能在几分钟内被证实或者排除。