为什么 Windows 把 VPN 里的名字发给一个你从未设置过的 DNS 服务器

你在 VPN 适配器上设好了 DNS 服务器，重新连接，可内部名字依然来自这台笔记本上没人配置过的办公网解析器。这个结果看起来像设置被忽略了，某种意义上的确如此，因为适配器列表只是一组候选，而不是一个决定。Windows 通过命名空间策略解析名字，该策略可以为某个后缀指定另一台服务器，而且它在适配器设置被考虑之前就已生效。只要知道该读哪张表，找出获胜的那条规则只需五分钟。

你改的是什么，真正起决定作用的又是什么

适配器上的 DNS 地址告诉客户端，该接口可以把查询发往哪里。名称解析策略表告诉客户端，对某个命名空间必须把查询发往哪里，而且它是按名字而不是按适配器来评估的。当某条规则匹配你输入的后缀时，就会使用该规则的服务器，适配器列表对那次查询不再有任何意义。

这就是同一台笔记本上的两个名字能在同一时刻走不同路径的原因。公司后缀下的主机会遵循自己的规则；公共名字走默认路径，通常意味着谁先应答就用谁。

表是如何匹配名字的

规则以命名空间为键，最具体的那条获胜。针对 corp.example 的规则适用于 vpn.corp.example，不适用于 example.net。命名空间为 . 的规则覆盖其他规则都不覆盖的一切，这使它成为列表中最危险的一条，也是当某个无关站点经隧道解析时值得检查的那一条。

规则还可以带有注释、一条禁用该条目的策略，以及与 DNS 地址毫无关系的安全设置。被禁用的规则在配置里依然可见却不起作用，所以纸面上看起来正确的一条，在配置变更之后仍可能形同虚设。

读生效中的表，而不是愿望清单

已配置的规则和生效的规则是两个不同的问题。Get-DnsClientNrptRule 列出机器上存在什么。Get-DnsClientNrptPolicy -Effective 显示客户端实际会应用什么，其中的值由策略和本地设置合并而来。

把输出中的后缀和你正在测试的名字逐字符比较。针对 corp.example 的规则抓不住以 corp.example.com 结尾的名字，而一处末尾带点、另一处不带，就足以改变匹配结果。

没有规则时，Windows 会问不止一个适配器

当表里没有任何条目认领这个名字时，客户端可以把查询从多个接口发出去，并采用最先到达的应答。结果取决于时机：同一个名字周一可能由有线适配器解析，周二则由隧道解析，而两个适配器的配置里都没有任何东西能解释这种差别。

有两条出路。为这个命名空间加一条规则，让决定不再是赛跑；或者通过 DNS 客户端策略关掉并行行为，接受更慢但确定的解析。前者通常更适合拆分隧道 VPN，因为它记录的是意图，而不是依赖顺序。

完全绕过解析器的路径

启用了安全 DNS 的浏览器自己解析，只把地址交给 Windows，因此规则表永远看不到那个名字。构建在自带解析器运行时之上的客户端也可能如此。当同一个名字在一个程序里能解析、在同一台机器的另一个程序里却失败时，先比较这两条解析路径，再去动策略。

还要检查程序是否连的是上一次会话缓存下来的地址。先执行 Clear-DnsClientCache，再做同样的查询，会比从旧结果里推断更干净。

用失败的那个名字来测

解析报告里的确切主机名，不要用公共测速域名，并记下是哪台服务器应答的。然后只改一处：规则、适配器列表或策略分配，并在重连之后重复同一次查询，让已应用的状态重新建立。

如果名字能解析而服务仍然拒绝，就不要再改 DNS 了。下一个有用的步骤是地址和通往它的路由，因为名称解析已经完成了它的工作。