域名查询服务器：3步查出真实解析

本地打开正常，外地客户说打不开——这种事儿十次里有七八次，根子不在服务器，在解析。「域名查询服务器」这几个字听着像要再买台机器，实际说的是另一码事：你拿谁去问这个域名。问的服务器不同、问的位置不同，拿回来的答案可能就是两套。先把这点记住，后面三步才不至于白忙一场。

域名查询服务器的3步，顺序别搞反

顺序这事儿很关键。正常的走法是：先拿权威服务器的一手答案，再换几个地方交叉比对，最后才回头看缓存和 TTL。多数人的做法正好相反——在自己电脑上敲个命令就当结论了，可那台机器给的往往是几小时前缓存下来的旧记录。顺序一颠倒，你查的是「我这边的样子」，不是域名真实的样子。

第一步：直接问权威NS，绕开所有缓存

域名真实解析成什么，权威服务器说了算。先在域名控制台或者 whois 结果里找到这个域名挂着哪组 NS，一般两到四条，长得像 ns1.xxx.com 这种。然后指定它来查：Linux 和 macOS 上用 dig @ns1.xxx.com 你的域名 A，Windows 上写 nslookup 你的域名 ns1.xxx.com，效果一样。

这一步的价值就是绕过中间那一堆递归缓存。如果权威给的 IP 和你电脑上查到的不一样，基本能断定是缓存还没过期，而不是解析配错了。反过来，两边一致但网站依然打不开，那问题的方向就该往服务器那边挪了。

第二步：多地交叉，找出差异在哪一段

单点结果最容易骗人。拿 8.8.8.8、1.1.1.1、223.5.5.5 这几个公共 DNS 分别问一次，或者直接用在线多地探测的工具，重点不是判断谁对谁错，而是看差异长成什么形状：是所有节点都指着新 IP、只有零星几个还留着旧的，还是一整片区域全都不对。

还有一种情况特别容易被误判——线路解析。电信、联通、移动分别给不同 IP，本来就是故意的配置，多地结果不一致属于预期内的正常现象。除非某一条线路整片全军覆没，否则别急着下「解析出问题了」的结论。

第三步：盯住TTL，算清楚要等多久

TTL 是这条记录允许被缓存多久，单位是秒。老手的做法是改解析之前先把 TTL 调小，比如提前一天改成 300，等旧的一轮缓存自然过期，再动记录，切换就干净。要是 TTL 还挂着 86400，改完之后最长可能得等上一天才全球一致，这期间不同人访问到不同 IP 太正常了，不是故障。

所以碰到「我这边已经生效、别人还没生效」这种投诉，先去翻 TTL，别急着来回改。改一次等一轮，比折腾三遍快得多。

工具怎么挑：dig、nslookup、在线探测

dig 信息最全，加个 +trace 还能沿着根域一路问下去，能看出是哪一层给的答案，排查时特别管用。nslookup 各平台自带，够用，就是输出啰嗦点。在线多地探测适合不想敲命令、或者想把截图直接甩给同事看的人。

提醒一句，各家在线工具的节点分布和缓存策略都不一样，结果只作参考，具体以服务商或官方页面说明为准，别把某一个工具的单点结果当成铁证。

CNAME和A记录一起看，不然越查越乱

现在域名前面套 CDN 的太多了。你查 A 记录拿到的，很可能是 CDN 边缘节点的 IP，压根不是源站。这时候还拿这个 IP 去反查、去和源站对比，纯属给自己找活儿干。看到 CNAME 指向某个 CDN 域名，就该去 CDN 控制台看回源配置，DNS 那边已经没什么可挖的了。

三步都干净了，才轮到怀疑服务器

权威答案一致，各地查询一致，TTL 也早过了，页面还是打不开——到这一步再去看服务器。登录上去 curl 一下本机、检查监听端口、翻防火墙规则、看 web 服务的错误日志。这两件事混在一起排查，最后往往是两边各查一半，哪个都没查透。

别忘了你本机也能骗你

动手之前先扫一眼 hosts 文件，看有没有人手写死过一条记录。浏览器自己也会缓存 DNS，换个浏览器、或者手机切到流量再试一次，几十秒就能排掉这种低级干扰。

顺手也看一眼本机的 DNS 设置，是不是被装过的某个软件悄悄改成了内网地址，这种事儿并不罕见。

就三步：权威拿一手答案，多地交叉比对，算清楚缓存要等多久。三步走完还没头绪，问题大概率不在解析这边。下次再遇到「我能打开、别人打不开」，按这个顺序过一遍，比在群里连问十个人靠谱。