网站换了服务器、改了解析记录，结果页面死活打不开——这种问题几乎每个站长都遇到过。很多人第一反应是”主机商有问题”，但根据我这几年的排障经验，多数”打不开”其实是 DNS（域名解析系统，负责把域名翻译成服务器 IP）没有按预期生效。这篇文章解决的就是这个问题：如何只用 dig 和 nslookup 两条命令，在十分钟内判断故障出在本地缓存、解析记录、还是主机本身，帮你少走弯路、少提无效工单。
先给结论（TL;DR）：排查域名解析不生效，按”本机缓存 → 权威记录 → 递归链路 → 业务验证”四步走。dig 适合看完整解析链路和 TTL（记录缓存存活时间），nslookup 适合快速交互式验证，两个工具配合使用，绝大多数解析类故障都能定位到具体环节。
一、动手前先确认：你用的到底是哪台 DNS 服务器
排查前必须搞清楚一件事：你的电脑或服务器向哪台 DNS 服务器发起查询。同样的域名，用运营商默认 DNS 和用公共 DNS（如 8.8.8.8 这类第三方递归解析服务）查出来的结果可能完全不同——因为缓存刷新时间不一样。
以 Linux 服务器为例，先看本机配置：
cat /etc/resolv.conf
如果输出里 nameserver 指向内网地址（比如 192.168.x.x 或 100.100.x.x），说明查询走的是内网或云厂商的默认递归。这类递归节点对记录变更的缓存往往更顽固，是”改了解析迟迟不生效”的常见原因。Windows 用户可以用 ipconfig /all 查看同样信息。
二、用 dig 查权威记录：判断解析到底有没有改对
dig 是排查 DNS 的主力工具。它最大的价值是能指定”问谁”：你可以绕过所有中间缓存，直接向域名的权威服务器查询，拿到最真实的结果。
第一步，查权威服务器地址：
dig NS example.com +short
第二步，直接向权威服务器确认 A 记录（域名指向 IPv4 地址的记录）：
dig A example.com @ns1.example-dns.com +short
判定标准很简单：如果权威服务器返回的已经是新 IP，说明你在解析服务商后台的修改是成功的，问题出在下游缓存；如果返回的还是旧 IP，甚至返回 SERVFAIL（服务器失败状态码），那是记录本身没配好，回解析后台检查即可，不用怀疑主机。
还有一个新手容易忽略的细节：看 TTL。用 dig A example.com 不加 +short，输出里有一列数字就是 TTL（缓存存活秒数）。旧记录 TTL 设了 86400（24 小时），就意味着全球递归节点最长要 24 小时才彻底换血。改解析前提前把 TTL 降到 300，能把这个窗口从一天压缩到五分钟。
确认权威记录没问题后，下一步就要弄清楚：为什么”权威已经改对”，用户那边却还是旧结果？答案通常藏在中间的递归缓存里。
三、用 nslookup 验证递归链路：缓存到底刷新了没有
nslookup 的优势是交互式、跨平台——Windows 自带，排查用户侧问题特别方便。它的用法是显式指定递归服务器，逐个对比结果。
先问公共 DNS：
nslookup example.com 8.8.8.8
再问运营商 DNS（以 114.114.114.114 为例）：
nslookup example.com 114.114.114.114
典型场景：8.8.8.8 已经返回新 IP，114 还是旧 IP，而你的用户恰好集中在后者的网络里——这就是典型的”部分生效”状态，不是故障，只是缓存时间差。应对办法是等 TTL 到期，或者引导受影响用户刷新本地缓存（Windows 用 ipconfig /flushdns，macOS 用 sudo dscacheutil -flushcache）。
如果所有递归都返回 NXDOMAIN（域名不存在），而权威服务器上明明有记录，通常要优先检查两件事：一是域名是否到期或被注册商暂停解析（clientHold 状态会直接摘掉解析）；二是 NS 记录是否指向了已经废弃的 DNS 服务商，导致整个解析链路断裂。
四、进阶工具：dig +trace 看完整解析链路
当上面几步都正常、问题却依然存在时，用 dig +trace example.com 可以看到从根服务器开始的完整迭代查询过程。哪一环节断掉、哪一环节返回了异常数据，输出里一目了然。这个命令也是向主机商或解析商提交工单时最有说服力的证据——直接把 trace 输出贴给对方，能省掉大量来回沟通。
五、别把主机问题误判成解析问题
解析排查的最后一步永远是验证：域名解析到的 IP，是不是一台”活着的、跑了 Web 服务”的服务器。
curl -I http://example.com
如果 dig 返回的 IP 是正确的新 IP，但 curl 连不上或返回 5xx，那问题在服务器侧：Web 服务没起、防火墙拦了 80/443 端口、或者证书配置异常。这类问题属于主机排障范畴，和 DNS 无关。打算用 VPS（虚拟专用服务器，一台物理机划分出的独立运行环境）建站时间不久的读者，可以先看这篇部署教程，确认 Web 环境本身是通的：外贸建站新手如何用海外 VPS 部署 WordPress。
实际排障中还有一种高频情况：域名解析正常，但国内访问特别慢或不稳定，这通常是线路质量问题而非解析问题，可以参考这篇 BGP 线路实测分析来区分：BGP 线路在国内的真实表现。
六、总结与行动建议
把整套排查流程压缩成一张速查表：
- 权威记录未更新 → 回解析服务商后台改记录，检查域名是否到期或被 hold
- 权威已更新、递归未更新 → 等 TTL 到期，或让用户刷新本地缓存
- 全部返回 NXDOMAIN → 检查域名状态和 NS 记录指向
- 解析正确但页面打不开 → 转向服务器侧排障：Web 服务、防火墙、证书
三条日常建议：改解析前先把 TTL 降到 300 秒，改完再调回去；重要变更安排在低峰期，留足缓存传播时间；提交工单时附上 dig +trace 的完整输出，双方都能少走弯路。如果你正在选一台方便做 DNS 排障的主机，可以关注一下 Hostease，其对中文用户的支持（中文客服、中文文档）在处理这类问题时沟通成本会低不少。按这四步流程走一遍，域名解析不生效这类问题基本都能在十分钟内定位。
