nslookup / dig

前两节的 ping 和 traceroute 都有一个共同前提：你已经知道目标的 IP。可真实上网的第一步是"域名翻译成 IP"——这一步要是坏了，ping 会报"找不到主机"，traceroute 连第一跳都发不出去。上一节埋的这颗雷，本节来拆。nslookup 和 dig 就是两位 DNS 侦探：前者人人可用（Windows 自带、命令简单），后者是工程师的爱将（信息全面、输出精确）——它们能直接审问任何一台 DNS 服务器"这个域名到底指向哪"，还能逼它出示身份、查它的底细、对比不同"证人"的口供。读完本节，"网站打不开"这个最常见的故障，你会多出一条独立的判断线索。

先把这一节的术语翻译成人话

DNS 的名词在第 3 章（§ 3.4）和第 4 章（§ 4.2）见过一轮，这里补上"侦探视角"的新面孔：

三十秒复习：DNS 的两级结构

侦探开工前，把案发地形复习一遍（细节在第 3 章 § 3.4，这里只留骨架）。你输入一个域名，第一步问的是递归服务器——你家路由器自动配的运营商 DNS，或者你手动改的 223.5.5.5、8.8.8.8 这类公共 DNS。它的角色是"跑腿的"：收到问题后，它替你去问一串权威服务器——先问根（谁管 .com？），再问 .com 的管理者（谁管 example.com？），最后问 example.com 自己的权威服务器（www 的 IP 是多少？），拿到答案后转交给你，顺便抄一份在自己的缓存里，下一个用户来问就秒答。

不妨这样想它替你问路的方式：递归服务器是层层打听的跑腿小哥——先问路口交警（根服务器："谁管 .com？"），再问片区的警务室（.com 的权威："谁管 example.com？"），最后问到小区门卫（域名自己的权威："www 的具体门牌是几号？"）。三步问到具体地址，它把答案带回给你，也抄一份贴在自己窗口备用。你要是嫌它跑得慢，它会说：这单跑完，下回同小区的单我张口就答——这就是下一节要讲的缓存。

说白了：递归服务器是外包的查号台，权威服务器是官方档案室。查号台可能数据过期、可能抽风、可能被劫持；档案室才是最终真相。而 nslookup 和 dig 的核心技能，就是能指定"这次问谁"——平时问查号台，存疑时直接杀到档案室对质。这个"换人问"的自由度，正是它们比浏览器（只会傻问默认查号台）强大的地方。

被遗忘的老前辈：hosts 文件

讲 nslookup 之前，先认识一位比所有查号台都老的前辈：hosts 文件。每台电脑里都有一个纯文本小本本（Windows 在 C:\Windows\System32\Drivers\etc\hosts，macOS/Linux 在 /etc/hosts），内容就是一行行"IP + 域名"——系统查域名时，会先翻这个小本本，翻到了就直接用，根本不去问 DNS。

说白了，hosts 就是你随身的通讯录小抄：通讯录里有的，不打 114；通讯录里没有的，才去查号台。在没有 DNS 的上古互联网，全世界的电脑都靠手抄一份 hosts 文件认路（那时还有专人定期邮寄更新版）；后来域名爆炸，手抄本更新不动了，才发明了分布式的 DNS——但 hosts 作为"最高优先级的本地小抄"被保留至今。

它在今天有三个正经用途。其一，本地开发：程序员在自己电脑上写网站，把 127.0.0.1 www.mysite.com 写进 hosts，浏览器敲真域名就访问到本机——相当于给自己发了个"私人门牌"。其二，强制指定 IP：服务器搬家期间，想让某台机器"提前"访问新服务器，写一条 hosts 即可，不受 DNS 缓存影响。其三，排查对照：怀疑 DNS 被劫持时，从权威服务器查到真 IP 手写进 hosts，能绕过查号台直达目的地——病好了，就实锤是查号台说谎。

排错时它也是个嫌疑犯：有人 hosts 里残留着一行几年前的旧记录，于是"全世界都正常、只有这台电脑"访问某网站永远指向老 IP——翻翻 hosts，是"单机异常"类故障的固定动作。好比全班同学都抄到新课程表了，只有你的作业本里还夹着上学期的——怪不得你总走错教室。

nslookup 上手：一问一答

最简单的用法，命令后面直接跟域名：

输出两段。第一段"服务器"信息显示你当前用的是哪台递归 DNS（很多人第一次看到这段才发现：原来自己天天用的 DNS 是运营商自动配的某台机器）——这段本身就有诊断价值：它报错，说明你和查号台之间的线不通。第二段"回答"给出域名对应的 IP 地址。就这么两段：谁回答的、答案是什么。域名通 IP 通，DNS 这关就过了。

报错的两种典型长相也认识一下：一种是"找不到主机名"——查号台说"查无此名"（域名真不存在，或递归服务器抽风）；另一种是非权威应答配上超时——你和查号台之间失联。两种报错对应两层病灶，先分清是"查号台答不上来"还是"你根本没打通查号台的电话"。

指定服务器查：排除缓存的干扰

nslookup 的进阶姿势：域名后面再跟一个 DNS 服务器地址，意思是"这次别问默认的查号台，问指定的这台"：

这是 DNS 排障的第一板斧：换一台查号台再问。默认服务器答不上来，先别急着判死刑——换 223.5.5.5（阿里公共 DNS）、119.29.29.29（腾讯）、8.8.8.8（谷歌）各问一遍。如果别人都答得上来、只有你的默认 DNS 答不上，病灶锁定：你配的那台递归服务器坏了或被劫持了——解法是把设备的 DNS 改成公共 DNS，问题当场消失。

反过来，如果所有查号台都答不上来，那就不是查号台的问题：要么域名真不存在（打错了、网站真注销了），要么域名的权威档案室出事了——这时该"直接问档案室"了，方法见下文 dig 部分。

公共 DNS 盘点：查号台也分三六九等

既然"换台再问"是排障第一板斧，手里就得常备几台信得过的查号台。国内常用的几家，一张表说清：

怎么选？不妨这样想：公共 DNS 就像小区门口的几家超市——哪家近（延迟低）、哪家货全（解析成功率高）就办哪家的卡。测"近不近"用你上一节刚学会的 ping：对每台 DNS 各 ping 一轮，回包平均延迟最低的，就是网络上离你最近的。测"全不全"就拿几个冷门域名挨家问一圈，谁家都答得上来才算货全。日常配两台就够：一台主力、一台备用——再大的超市也有盘点歇业的日子，设备里"主 DNS + 备 DNS"两栏都填上，查号台抽风时自动切备用，是老练用户的标配。

改在哪？手机和电脑的 WiFi 详情页里都有"DNS"一栏；更省事的做法是在路由器管理后台统一改，全家设备一次到位。改完回终端再跑一次 nslookup——第一段"服务器"显示成了 223.5.5.5，就说明新查号台正式上岗了。这个动作本身就是一次微型体检：往后凡是怀疑"运营商 DNS 搞小动作"，换台立见分晓。

dig 登场：工程师的爱将

nslookup 是问答式的便民工具，dig（domain information groper）则是专业仪器——macOS 和 Linux 自带，Windows 用户可以在 WSL 里用它。同样的查询，dig 的输出像一份正式的检验报告：

$ dig www.baidu.com

;; QUESTION SECTION:      ← 你问了什么
;www.baidu.com.    IN    A

;; ANSWER SECTION:        ← 得到什么答案
www.baidu.com.  1200  IN  CNAME  www.a.shifen.com.
www.a.shifen.com. 1200 IN  A  110.242.68.4
www.a.shifen.com. 1200 IN  A  110.242.68.66

;; SERVER: 223.5.5.5#53   ← 是谁回答的
;; Query time: 8 msec     ← 花了多久
;; ANSWER: 3              ← 拿到几条答案

三个看点。第一，ANSWER SECTION 一次能有多行——一个域名对应多个 IP，这正是大网站的标配（第 5 章讲过的负载均衡，§ 5.5：多个 IP 轮着用，一台挂了还有别的）。第二，每行中间那个数字 1200 是 TTL——这条答案允许被缓存 1200 秒（20 分钟），后面细讲。第三，末尾的 Query time——查这次花了 8 毫秒，如果这个数字常年 100ms 以上，说明你的 DNS 服务器太慢，"每个新域名都要等它跑腿"，网页打开速度会被拖累。

日常工作里最常用的其实是它的极简模式：dig +short www.baidu.com 只输出 IP，一行一个——写脚本、做批量检查时干净利落。+short 是"我只要结论"，完整输出是"我要看证据链"——同一件工具的两种口径。

逼档案室开口：查权威服务器

dig 有个杀手锏：@ 符号直接指定问谁。dig @8.8.8.8 www.example.com 是"问谷歌的查号台"；而真正的绝招是直接问域名自己的权威服务器。怎么找到权威服务器？先查 NS 记录（下面马上讲），或者用 dig 的两连招：dig example.com NS +short 列出这个域名的权威服务器名单，然后 dig @权威服务器地址 www.example.com 直捣黄龙。

为什么要绕过查号台直问档案室？因为递归服务器的答案可能是"缓存"的，权威服务器的答案才是"现行档案"。网站搬家了、IP 换了，权威档案室已经更新，但各级缓存还在发旧答案——这时问权威服务器，拿到的一定是最新真相；问递归服务器，拿到的可能是"过期报纸"。对质式查证，是 DNS 侦探的终极姿势：默认查号台说东，档案室说西，一切以档案室为准——差距本身就说明"缓存还没过期"。

两件顺手小工具：交互模式与反查

nslookup 还有个隐藏形态：不带任何参数直接回车，进入交互模式（提示符变成 >）。之后每敲一个域名就查一次，中途还能用 set type=MX 切换要查的记录类型、用 server 8.8.8.8 切换问谁，最后 exit 退出。会话式的用法在连环排查时省去了反复敲完整命令的麻烦——好比查号台接线员干脆把听筒递给你：想问几个问几个，别一次次重拨了。

另一件是反查：dig -x 110.242.68.4，反着问"这个 IP 有没有登记名字"。它查的是 PTR 记录（指针记录）。先泼盆冷水：不是所有 IP 都有名字——家庭宽带几乎都没有，机房服务器大多有。但一旦查到，信息量往往不小：机房 IP 的 PTR 常常直接暴露归属，写着某运营商、某云厂商或某 CDN 节点的字号——相当于不仅能"名字查号码"，还能拿号码反问出"这是谁家装的电话"。上一节讲两地对比揪劫持时要"查 IP 归属地"，反查就是不用第三方网站的本地做法：拿到一个可疑 IP，先 dig -x 问一句，再决定要不要进一步取证。

记录类型家族：档案室里的不同柜子

档案室里不只有"名字→号码"一个柜子。dig/nslookup 默认查 A 记录，但你可以指定查其他柜子——每个柜子回答一类问题：

用法都是在命令里写上类型：dig qq.com MX、nslookup -type=NS baidu.com。值得一提的是 TXT 记录的妙用：它本质是"挂在域名下的一串公开文字"，谁都能查——于是各家发明了各种玩法：证明"这个域名是我的"（域名证书签发时验证）、声明"哪些邮件服务器有权以我的名义发信"（反垃圾邮件的 SPF/DKIM）。相当于门上贴的公告栏：不涉密，但字字算数。

这套分工乍看头绪繁多，其实像极了医院的挂号分诊：挂号的窗口只管告诉你"下一步去哪"，不替你看病。A 记录答"大楼的门牌在哪"（IP 地址）、MX 答"邮件请投收发室"、NS 答"这个域名的事务归哪位专家（权威服务器）管"、TXT 是"贴在门口的告示"。每个窗口只答自己那一类问题——你去 A 记录的窗口问"我的邮件发哪了"，得到的只会是一句"这个不归我管，请去 MX 窗口排队"。排查时想清楚"我要问的是哪类问题"，就不会拿着检查单在挂号窗口干耗。

CNAME 链条：CDN 的身份证

上一节 traceroute 讲过"CDN 截胡"，这里补上 DNS 侧的证据。你 dig 一个用 CDN 的大网站，ANSWER 段往往长这样：第一行是 CNAME——www.example.com → www.example.com.cdn-provider.net，然后才是真正的 IP。翻译过来："www.example.com"不是名字本名，它是个花名，本名挂在 CDN 服务商的域名下。

这个结构是理解 CDN 的钥匙：网站接入 CDN 时并不需要交出服务器，只要在自己的 DNS 里加一条 CNAME，把花名指向服务商——从此"这个域名解析到哪个 IP"的决定权，就从网站转给了 CDN 的调度系统。CDN 看你的来源地址，把你调到离你最近的边缘节点（第 7 章 § 7.1 的全部故事）。诊断价值：CNAME 链条露出来，你就知道这网站用了哪家 CDN；dig 两次拿到不同 IP，那是调度系统在干活，不是网络在抽风。

TTL 与缓存：为什么"改了解析"半天不生效

每个 DNS 答案都自带一个"保质期"——TTL 秒数。这个数字控制着互联网上大大小小的缓存：递归服务器把答案抄进缓存，TTL 不到期就一直用缓存、不再跑腿去问档案室。于是出现一个所有建过网站的人都经历过的烦恼：服务器搬家，DNS 记录改了，可老用户还在被导向旧服务器——因为各地查号台手里的"旧答案"还没过期。

打个比方，DNS 缓存就像超市的临期食品货架：没过保质期的照常卖，谁也管不着；一到点全部下架，重新进货（重新向权威服务器跑一趟）。TTL 就是印在包装上的那个日期。各地查号台的货架各自独立、进货时间各异——所以"改解析后的生效"从来不是一个时刻，而是一段渐变：有的查号台上午就进了新货，有的捂着旧货直到深夜保质期到点。你 dig 权威服务器看到新 IP、dig 本地查号台看到旧 IP，两说并存完全正常——这不叫故障，这叫"新旧混流期"。

缓存的层级比想象的多，从近到远至少三层：浏览器自己的缓存（同一网站反复访问，连查号台都不问）、操作系统的缓存、递归服务器的缓存。网站搬家要"全球生效"，就得等最远那层缓存全部过期——这就是"DNS 生效需要几分钟到几十小时"的来历。运营老手搬家前会先调小 TTL（比如从 3600 秒改成 300 秒），等旧 TTL 过期后再动手改 IP——让全球缓存最多 5 分钟就刷新。先降保质期、再换货，是搬家不丢客的经典操作。

对排错者的启示：dig 拿到的答案如果和权威服务器不一致，先看 TTL——不是谁坏了，是缓存还在保质期内。给缓存一点时间，或者换个没缓存的公共 DNS 验证。

缓存三重奏：浏览器、系统、查号台各抄一份

上一段说"缓存层级比想象的多"，这里把这条缓存链走细。你访问一个网站时，"查号码"这个动作其实被三层缓存接力截胡，从近到远：

• 浏览器缓存（第一站）：Chrome、Firefox 都自带 DNS 小账本，最近查过的域名直接用，连操作系统都不惊动。Chrome 在地址栏输入 chrome://net-internals/#dns 能亲眼看到这份账本，页面上还有 Clear host cache 按钮一键清空；
• 操作系统缓存（第二站）：Windows 用 ipconfig /displaydns 翻看系统记的账、ipconfig /flushdns 一键清空；macOS 则是 sudo dscacheutil -flushcache 加 sudo killall -HUP mDNSResponder；
• 递归服务器缓存（第三站）：查号台自己的货架，受 TTL 管辖——你无权清理，只能等它自己过期。

这套设计其实就是家里的冰箱逻辑：做饭要个鸡蛋，先看案板边（浏览器缓存），再开冰箱（系统缓存），两处都没有才下楼去超市（查号台）。三层缓存省的是同一件事——别为每个鸡蛋都跑一趟超市。麻烦也出在同一点：超市换了蛋的供应商（DNS 记录改了），你冰箱里还躺着旧的。所以"改完解析要刷新本地缓存"，指的就是清前两站：浏览器按 Ctrl+F5 顺带清、或终端里 ipconfig /flushdns 一把清。第三站你够不着——那得等 TTL 自己走完，急不来。

dig 还能当场演示缓存的存在，这是它输出的隐藏彩蛋：对同一台递归服务器连查两次同一个域名，第二次答案里的 TTL 数字变小了。那个数字显示的是"剩余保质期"——变小，说明你拿到的是货架上的存货；如果隔几分钟再查 TTL 仍然是满值（比如每次都是 1200），说明查号台每回都真跑了趟档案室（缓存恰好过期重进了货）。一条命令看穿查号台有没有偷懒，也是验证"我改的解析到底生效没有"的土办法：盯着 TTL 数字往下走，就知道旧缓存还剩几口气。

查号台用的线路：53 号窗口与快问快答

顺着 dig 输出里的一个细节再挖一层：SERVER 那行写着 223.5.5.5#53——井号后面的 53，是 DNS 服务开在的"窗口号"（端口号，第 3 章 § 3.2 讲过的港口泊位）。DNS 的绝大多数查询走 UDP：一来一回两个小包，快进快出。为什么不用第 3 章隆重介绍过的 TCP？因为 TCP 动手前要先握手三次，查个号码还得先寒暄半天，不划算——查询本身就几十个字节，UDP 一个包扔过去、一个包扔回来，干脆利落。简单说：UDP 是窗口递材料的快问快答，TCP 是先握手寒暄再办事的长流程；查号这件事，天生适合前者。

例外是答案太大装不下的时候：比如开了 DNSSEC 签名的域名，答案膨胀得厉害，UDP 一个包裹塞不下，双方会自动改用 TCP 传大件——快递小件走电驴、大件换货车的道理。而第 10 章 § 10.4 要讲的 DoH/DoT，是把整条查询线路整个搬进加密通道：明文 UDP 53 像明信片，经手人都能瞄一眼；加密 DNS 像装进信封的挂号信。这里先留个坐标，到时候回来对照。

企业内网的两副面孔：同域名不同答案

有一类"怪案"专挑上班族下手：在公司访问 oa.company.com 一切正常，晚上回家连上 VPN 再访问，死活打不开；或者反过来，在家能打开，到了公司反而白屏。nslookup 一查真相大白——两边拿到的答案根本不是同一个：公司里给 10.x 开头的内网地址，家里给公网地址。网站坏了？没有。DNS 坏了？也没有。

这是企业网络的标准操作，叫分裂解析（split DNS）：同一个域名，内网的 DNS 服务器答"内网地址"（员工设备直连内网，快），公网 DNS 答"公网地址"（外面的人从大门进）。本质上就是一栋大楼的两套进出方案：楼内员工刷卡走电梯直达工位（内网 IP），访客在前台登记走正门绕一圈（公网 IP）——两个入口，同一批工位。公司要的就是这个效果：内部流量不绕公网，既快又安全（第 8 章 § 8.6 的零信任之前，内网本身就是第一道信任边界）。

排查这类问题的钥匙是：先看你的设备此刻"用的是哪台 DNS"。连着公司网时，路由器分发的往往是内网 DNS（答案自然是 10.x）；而 VPN 若是"分流模式"（只有访问公司网段才走隧道），DNS 查询可能仍被发到家里的默认查号台——拿到的公网地址，从你家的网络未必连得通。想象一下：人在家，手里却攥着"员工电梯"的路线图——当然到不了工位。解法通常是让 VPN 客户端接管 DNS（勾选"使用远程网关/DNS"，或由公司 IT 在连接时下发内网 DNS）。判断口诀就一句：答案对不对，先看你问的是谁；内网的服务，就得问内网的查号台。

顺带解开一个日常悬案：同一个网站"公司里秒开、家里转圈"。先别急着骂家里网慢——nslookup 对比两边的答案，很可能公司里你拿到的是直连内网的近路，家里走的是绕公网的远门。查号台不只会告诉你号码，还悄悄决定了你走哪条路、进哪个门。看清这一点，"网速玄学"就少了一大块。

DNS 故障排查流：四步夹逼

把前面的知识串成一条标准流程。场景：某网站打不开，ping 报"找不到主机"——DNS 嫌疑最大：

• 第一步：nslookup 该域名（问默认查号台）——答出来了？那 DNS 没坏，问题在别处，回 ping 章节；
• 第二步：答不出来，指定换台查——nslookup 域名 223.5.5.5。换台能答：你的默认 DNS 坏了/被劫持了，改设备 DNS 为公共 DNS 即愈；
• 第三步：换台也答不出——查域名是否存在（换一个确定存在的域名对照，比如 baidu.com 全挂说明网络断，只有目标域名挂说明它自身有问题）；
• 第四步：目标域名确实存在但到处查不到——直问权威服务器（dig NS 找档案室，再 @ 它查），权威答不出：它的 DNS 服务真故障了，等它修；
• 加分项：对比两地的查询结果（下一小节）。

看这个流程的形状：又是"由近及远、逐段替换"——先测自己的默认配置，再换公共服务器对照，再验域名本身，最后直捣权威。和 ping 的分段排查一个模子：工具在变，方法论从不换样。

两地对比：揪出劫持与污染

DNS 侦探还有一类高阶案情：查号台说谎。两种典型骗术。一是劫持：运营商或公共 WiFi 的 DNS 把你的查询偷偷篡改——要么导向自己的广告页（输错网址弹一堆导航站，就是它），要么导向假冒的钓鱼站（第 8 章 § 8.2 讲过的证书能帮你识别后者）。二是污染：查询结果在半路被塞入假答案，让你连不上某个网站。想象一下你寄快递：包裹还在分拣中心传送带上，就被人调了包——收件单上的名字没变，里面的货早已不是原来那件。DNS 污染干的就是这个：你的查询包还在路上，假答案抢先一步塞到你手里，真答案到的时候你已经拿着假的走了。

诊断手法就是两地对比：用 dig 分别向多个公共 DNS 查同一个域名（最好混用境内外、不同家的），对比答案。口径如下：所有服务器答案一致——正常；只有本地的默认 DNS 答案与众不同（尤其导向奇怪的 IP）——本地劫持实锤；多家答案指向完全不同的机房——先看是不是 CDN 调度的正常现象（CNAME 链条可以作证），不同城市的 IP 不同是常态，但指向"和该网站毫无关系的网络"就要警惕。可以拿 IP 去查归属地（whois 类服务），一目了然。

顺便说防：对付劫持，公共 DNS + 加密 DNS 是平民的护身符——把设备 DNS 改成 223.5.5.5 这类大厂公共 DNS，能挡掉运营商本地的小动作；进阶的 DoH（DNS over HTTPS）把查询装进加密隧道，半路连"看"都看不了——这是第 10 章的正式话题（详见 § 10.4），此处留个钩子。

dig +trace：亲眼看完一次完整递归

最后一个进阶玩法，值得每个学过第 3 章的读者跑一次：dig +trace www.baidu.com。它模拟一台"没有任何缓存的递归服务器"，把完整的逐级查询过程打印出来——先问 13 台根服务器之一（"谁管 .cn？"），再问 .cn 的权威（"谁管 baidu.com？"），再问 baidu.com 的权威（"www 的 IP？"）。一路下来，第 3 章讲过的"全球分布式树状 DNS"不再是插图，而是你屏幕上滚动的、活生生的一问一答。

+trace 的实用价值：它能定位"递归卡在哪一级"。普通查询失败你只知道"失败"，+trace 能看到是根没回、还是 .cn 没回、还是域名的权威没回——哪一级开始断，病灶就在哪一级之后。把一次黑箱查询拆成三级透明的问路，这是 dig 比 nslookup 强大的又一个维度：不但要答案，还要看清楚答案是怎么一步步走来的。

动手清单：一次规范的 DNS 体检

• nslookup 目标域名 —— 看默认查号台答不答、答的 IP 是多少；
• 答不出 → nslookup 域名 223.5.5.5，换台对照；
• dig +short 目标域名 —— 拿干净的 IP 清单（多个 IP 是负载均衡，正常）；
• dig 目标域名 —— 看完整输出：CNAME 链、TTL、查询耗时；
• 连查两次看 TTL 是否递减 —— 现场验证缓存的存在；
• 怀疑搬家未生效 → dig NS 找权威，@ 权威服务器对质最新档案；本地先 ipconfig /flushdns 清掉自家冰箱；
• 怀疑劫持 → 多家公共 DNS 对比答案，dig -x 反查可疑 IP 的归属；
• 内网系统打不开 → 先看 nslookup 首段"用的是哪台 DNS"，内网域名要对内网查号台问；
• 想看完整递归 → dig +trace 一次，亲眼看 13 根到权威的全过程。

常见误区

• 误区一："nslookup 查到的 IP 就是网站唯一的 IP"大网站普遍一域多 IP（负载均衡）+ CDN 调度（不同地区拿到不同 IP）。你查到的是"你这一次、你这条线"被分配的答案，换个网络再查，答案不同很正常。
• 误区二："dig 显示的 IP 和权威服务器不一致，肯定有人作弊"先看 TTL——递归服务器在保质期内发缓存答案，属于正常机制不是攻击。对质要看"缓存过期后是否收敛到权威答案"。
• 误区三："DNS 查询很快，不用关心"每个"新域名"都要一次完整递归（可能几十到几百毫秒）。浏览器替你隐藏了这段等待，但 DNS 服务器太慢时，"打开网页前的空白时间"会明显变长。
• 误区四："nslookup 报错说明这网站挂了"报错只说明"你问的这一台查号台答不上"。换台再问、对照其他域名，先分清是查号台的病还是网站的病，再下结论。
• 误区五："改了 DNS 记录应该立刻全球生效"生效时间被各级缓存的 TTL 决定，从几十秒到几十小时都正常。专业做法是提前调小 TTL 再改。
• 误区六："在家连了 VPN 还打不开公司系统，肯定是公司网挂了"先 nslookup 看答案：拿到公网地址说明查询没走内网 DNS——VPN 分流模式下 DNS 仍发给了家里的查号台。让 VPN 接管 DNS（远程网关/DNS 选项），多半立愈。病根在"问错了人"，不在路。