为什么 nslookup 能通过 VPN 解析而浏览器不能

nslookup 把查询发给您指定的服务器并打印答案，所以它能在每个浏览器标签页都失败时成功。浏览器请操作系统解析，操作系统会权衡每个接口的解析器、名称解析策略规则以及适配器的网络位置。随后浏览器还可能叠加自己的加密 DNS。三条不同的路径、同一个症状，而隧道通常不是坏掉的那一段。

下面的检查沿这些路径从系统向外推进。在弄清哪条路径回答了、哪条失败了之前，不要修改 VPN 配置文件。

三个策略决定答案

每个接口都有自己的解析器列表和搜索后缀。VPN 适配器会添加服务器，而物理适配器保留自己的，系统可能采用最先回答的那个，因此一次查询可能在没有谁选择的情况下由隧道外提供服务。名称解析策略表的规则可以把选定域发给选定服务器，Windows 上的拆分 DNS 通常就是这样表达的。而 VPN 客户端或网关可能下发一个只存在于私网内部的解析器地址。

这三者在浏览器看来会以看似随意的方式相互作用。被下发到私网地址、却没有穿过拆分隧道的路由的解析器，会让每次查询先卡住再失败。覆盖内部后缀并指向已停机服务器的策略规则，产生的可见错误与缺少路由相同。VPN 适配器上缺失的搜索后缀会把短名称变成针对错误域的公共查询。每一种都需要不同的修复。

为什么浏览器问的是另一个问题

nslookup 向自己选定的服务器发出自己的查询，既不遵守命名空间策略，也不遵守浏览器的加密 DNS 设置。这就是为什么手动查询公共解析器有答案，而浏览器却报告站点不存在。您比较的是两个程序，而不是同一个程序的两种状态。

地址族偏好解释的是延迟而不是失败。在只承载 IPv4 的隧道上先请求 IPv6 记录的浏览器，会等到超时之后才回退。Firefox 正是为此保留了这个偏好，关掉它是诊断步骤，不是修复。

读取解析器列表和规则

在 Windows 上，先把系统持有的内容打印出来再推断。Get-DnsClientServerAddress 显示每个接口的服务器，Get-DnsClientNrptRule 列出命名空间规则，Resolve-DnsName 则通过系统路径回答确切名称。把该答案与按地址直接查询 VPN 服务器的结果相比较。当 Resolve-DnsName 失败而直接查询成功时，嫌疑就是解析器列表或某条命名空间规则。

也要检查名称本身。内部短名称可能需要只有 VPN 适配器才提供的私有后缀，而完全限定名称解析正常。解析成功之后出现的证书警告属于另一个问题。

无法到达的下发解析器

网关或客户端可以下发解析器地址，而该地址必须能通过隧道访问。在拆分隧道中，承载解析器的私网范围可能不在包含的路由里，于是查询永远得不到答案。确认路由存在，然后专门通过隧道查询该地址。这就是浏览器报域错误、而公共解析器仍有答案背后的失败。

如果解析器无法到达，修复方法是添加路由或包含子网，而不是换一个 DNS 服务器。

加密 DNS 绕过整条路径

启用 DNS-over-HTTPS 的浏览器会通过到所选提供商的 HTTPS 连接自行解析名称。开启之后，这些查询完全绕过系统解析器和拆分 DNS 规则，于是内部名称在浏览器里失败，而操作系统能正确解析它们。反过来也会发生：内部名称通过一个本不该看到它们的提供商在浏览器里成功，这属于策略问题而不是连通性问题。

有意识地决定受管设备上是否允许加密 DNS，然后通过浏览器的管理界面进行配置，让这个选择可见。把它留给个人偏好，会得到一个每台笔记本上同一个 VPN 行为都不同的机群。

与失败相匹配的修复

如果 VPN 下发了自己的解析器，就让隧道承载到它的流量，并让同一设置对参与解析的适配器可见。如果连接后本地站点不再解析，就添加显式的命名空间例外或条件转发器，而不是整体替换解析器。如果浏览器的加密 DNS 绕过了策略，那才是要改的设置。绝不要为了修内部名称而添加公共解析器：它会泄漏私密查询，而且解析不了该名称。

然后把解析与连接分开。一个解析到正确地址却拒绝连接的名称，是服务、防火墙或证书问题，改 DNS 解决不了。

记录哪条路径回答了、哪条失败了、您改了什么。这样下一次同样的症状报告只需一条命令，而不是一个下午。