查看域名解析的完整过程，核心做法是先清空本地缓存并确认本机 hosts 与 DNS 设置，再用 dig +trace 从根服务器逐级追踪到权威服务器，最后用指定 DNS 服务器交叉查询验证。这套动作能把递归查询、迭代查询、缓存命中三个层面全部摊开,定位问题几乎不会走偏。
域名解析在后台到底走了哪几步
从输入网址到拿到 IP 的完整链路
浏览器地址栏敲下域名回车后,解析顺序通常是这样：
- 浏览器自身 DNS 缓存（Chrome 可在
chrome://net-internals/#dns查看，Firefox 为about:networking#dns） - 操作系统 DNS 缓存与本地 hosts 文件
- 本机配置的递归 DNS 服务器（
/etc/resolv.conf里的nameserver，或 Windows 网卡属性里的首选 DNS） - 递归服务器未命中时，向 13 组根域名服务器发起查询，拿到顶级域（如
.com）的 NS 地址 - 向顶级域服务器查询，拿到该域名的权威 NS 地址
- 向权威服务器查询，拿到最终的 A 或 AAAA 记录
拿到结果后，递归服务器按记录 TTL 缓存，逐级返回给客户端，链路上任何一环缓存了旧记录，都会表现为"解析改了但还没生效"。
递归查询与迭代查询的差别
这两者经常被混为一谈,但排查问题时必须分清：
- 递归查询：客户端向本地 DNS 说"你帮我查到底"，由本地 DNS 承担全部工作量,日常上网基本都是这种。
- 迭代查询：本地 DNS 逐级去问根、顶级域、权威服务器，每次只拿到下一跳地址。
dig +trace复现的就是这一过程。
业内专家指出，多数解析异常并不出现在权威服务器上，而是卡在本地递归服务器的缓存环节，所以看完整过程，关键是把"缓存"和"权威"两头对齐比较。
用 dig 命令完整还原一次解析过程
dig +trace 逐级追踪的具体操作
Linux 和 macOS 一般自带 dig（Windows 需安装 BIND 工具包或用 WSL）,执行：
dig example.com +trace输出会分三段呈现：先列出根服务器的 NS 列表，再显示顶级域返回的权威 NS，最后是权威服务器给出的 A 记录与 TTL，想看精简版可加 +short，想指定起始服务器可写成 dig example.com +trace @8.8.8.8。
几个配合使用的命令也值得记住：
dig example.com NS：查该域由哪些权威服务器负责dig example.com SOA：查主 NS 与默认 TTL 参数dig @223.5.5.5 example.com：指定阿里 DNS 查询，用于和运营商结果对比dig +dnssec example.com：检查 DNSSEC 签名是否正常dig +norecurse example.com @本地DNS地址：直接观察缓存里有没有现成记录
dig 与 nslookup 查看域名解析有什么区别
这是实操中最常被问到的对比，两者都能查记录,但侧重点不同：
| 工具 | 自带系统 | 是否展示完整链路 | 输出可读性 | 典型用法 |
|---|---|---|---|---|
| dig +trace | Linux、macOS | 是，逐级列出 | 结构清晰，适合分析 | dig example.com +trace |
| nslookup -debug | 全平台，Windows 自带 | 部分，显示查询应答细节 | 偏繁琐 | nslookup -debug example.com |
| host -v | Linux、macOS | 部分 | 简洁 | host -v example.com |
| Resolve-DnsName | Windows PowerShell | 否 | 结构化 | Resolve-DnsName example.com -Type A -Server 8.8.8.8 |
结论很直接：要看清整条链路，用 dig +trace；只想快速确认某条记录的值，Windows 上用 nslookup 域名 8.8.8.8 就够。
本地缓存这一层怎么确认
链路的前两跳在本机,必须单独查：
- Windows 查看缓存：
ipconfig /displaydns；清空缓存：ipconfig /flushdns - macOS 清缓存：
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder - Linux 用 systemd 的系统：
sudo resolvectl flush-caches - 检查 hosts 是否被改：Windows 路径
C:\Windows\System32\drivers\etc\hosts，类 Unix 系统为/etc/hosts
相当一部分"解析不生效"的工单，最后发现是 hosts 里留了一行旧 IP,或浏览器内部缓存没有刷新。
网站打不开时，如何一步步排查域名解析问题
分层定位的三段法
遇到打不开,按从近到远的顺序切分：
- 本机层：
ping 域名看返回的 IP 是否为你预期的地址；若返回的是 127.0.0.1 或陌生 IP，先查 hosts 与本地缓存。 - 递归层：分别用两个不同 DNS 查询同一域名，
dig @119.29.29.29 example.com和dig @8.8.8.8 example.com，结果不一致,说明某一方缓存未过期或存在污染。 - 权威层：
dig example.com NS找到权威服务器，再dig @权威NS地址 example.com直连查询，权威结果与递归结果不一致，就是缓存 TTL 还没走完。
三段结果全部一致但仍打不开，问题多半在 Web 服务、端口或证书，不在 DNS 了。
TTL 决定了你要等多久
修改解析记录后，全球生效时间取决于原记录的 TTL，常见取值是 600 秒、3600 秒、86400 秒，行业共识认为，迁移前把 TTL 提前调小到 300 秒左右，能大幅缩短切换窗口，查当前 TTL 用 dig example.com 输出中的第二列数字即可。
国内域名解析生效慢，问题通常出在哪
国内不同运营商、不同省份的递归服务器刷新节奏差异明显，部分地区的 LocalDNS 会忽略 TTL 强制缓存较长时间，解决办法是换用公共 DNS 做对比查询，223.5.5.5、119.29.29.29、114.114.114.114，逐一验证是否已拿到新记录，若公共 DNS 已更新、运营商 DNS 未更新，属于递归侧缓存，只能等或引导用户切换 DNS。
免费在线域名解析查询工具怎么选
命令行不熟的场景，在线工具更省事,但要看它提供的能力：
- 只显示最终 A 记录的，适合快速核对，不足以排查链路
- 支持选择查询节点和记录类型的，能验证地域差异
- 提供 DNS 历史记录与传播检查的，适合迁移前后对比
- 支持 DNSSEC 验证结果展示的，适合排查签名错误
据 CNNIC 发布的互联网统计报告，国内网站规模长期保持在较高量级，域名解析故障是站点不可达的常见原因之一，选工具时优先看是否支持指定权威服务器直查,这一步决定了你能不能绕开缓存看到真实记录。
各系统查看域名解析的路径对照
| 系统 | 查看 DNS 配置 | 查看缓存 | 清空缓存 |
|---|---|---|---|
| Windows | ipconfig /all |
ipconfig /displaydns |
ipconfig /flushdns |
| macOS | scutil --dns |
dscacheutil -q host -a name 域名 |
sudo killall -HUP mDNSResponder |
| Linux | cat /etc/resolv.conf |
resolvectl statistics |
sudo resolvectl flush-caches |
再补充两个细节：curl -v https://域名 能看到实际连接的 IP，用于确认解析结果是否被真正使用；whois 域名 可确认 NS 是否已指向新的服务商，避免改了记录但 NS 没切。
关于查看域名解析过程的高频问答
查看域名解析完整过程必须用命令行吗
不是必须，但在线工具的追踪能力有限，要看到从根到权威的逐级应答，dig +trace 仍是最直接的方式，Windows 用户可通过 WSL 或安装 BIND 工具获得该命令。
为什么 dig 查到的 IP 和浏览器访问的不一致
优先怀疑浏览器内置 DNS 缓存和 DNS over HTTPS，Chrome 默认可能启用安全 DNS，会绕过系统设置直连指定解析服务商，在 chrome://settings/security 中可查看当前状态并关闭。
域名解析记录类型应该怎么核对
按用途逐条比对：A/AAAA 对应主机地址，CNAME 用于别名指向，MX 管邮件，TXT 常用于域名验证与 SPF，NS 决定权威归属，查询时加 -t 或 -type 参数指定类型，dig example.com MX,逐个类型确认与后台配置一致即可。
把本地缓存、递归服务器、权威服务器三段结果拉到一起比对，域名解析的全过程就无处可藏。 命令不必记全，dig +trace 加一次指定 DNS 的交叉查询,足以覆盖绝大多数排查场景。