VPN DNS 与浏览器 DoH：泄漏测试查不出的事

泄漏测试页面说你的 DNS 没问题，浏览器徽标显示连接安全，而内部 wiki 依然打不开。三件事可以同时成立，因为解析器的地址并不等于选中它的策略，也不等于查询走过的路径。人们所说的 DNS 泄漏其实只有一个问题：是哪个解析器收到了这个名称，这个选择是否是刻意为之？要把这件事理清需要三步检查，只有最后一步需要改动设置。

误区一：徽标会说出你的解析器

泄漏测试会解析一个探测用域名，并报告作出应答的地址。它不会报告选中该解析器的那条策略；而且当查询被包进 DNS over HTTPS 之后，路径上的中间设备根本看不到这个名称。两台截然不同的机器会给出同一个让人安心的徽标：一台由 VPN 推送了 10.8.0.1，浏览器照此使用；另一台浏览器无视系统列表，把名称经隧道发给了自己的加密服务商。

一旦某个内部名称解析失败，这个区别就立刻要紧。第一种配置里，VPN 解析器负责应答公司域；第二种里浏览器从未问过它，于是短主机名解析不了，故障看起来像 VPN 坏了。这项检查不是又做一次泄漏测试，而是去查一个只有某个解析器才知道的名称。

误区二：浏览器会离开隧道

DNS 负责选择地址，路由负责承载连接，两者是彼此分离的层次。发往公共 DoH 服务商的查询，仍然是通往可路由地址的 TCP 443 端口。如果你的路由表把默认路由送进隧道，这条查询同样走隧道。解析器的品牌并不决定路径。

浏览器 DoH 改变的是名称的接收方。这是一个真实的隐私决策，也是一个真实的策略决策，但它不是绕过路由。如果你的要求是名称必须留在 VPN 运营商手里，那么把加密查询发给别人就违反了这一要求，尽管实际连接仍然走隧道。

误区三：每个 VPN 都能覆盖每个浏览器

浏览器里的安全 DNS 有多种模式，而不是一个开关：关闭、带兜底的默认服务商、自定义模板，或由操作系统或组织强制执行的策略。兜底那种模式正是间歇性报告的来源。当加密端点不可达时，浏览器可能退回系统解析器，于是同一台笔记本周一能正确解析内部名称，周二却不行。

与此同时，多数 VPN 客户端会在连接建立时设置系统解析器，在断开时恢复上一个。持有自定义加密解析器的浏览器完全不会察觉这次恢复。这就是同一份配置在两台笔记本上表现不同、以及 resolv.conf 看着没问题而浏览器仍在问别人的原因。

resolvectl status                 # per-link DNS servers and split-DNS domains
scutil --dns | head -30           # macOS resolver order for each domain
nslookup intranet.corp 10.8.0.1   # ask the VPN resolver directly

在连接状态下运行这些命令，记下每个解析器声明的域，再与浏览器对自己模式的报告对照。Mozilla 的DoH 文档对浏览器的默认与兜底行为应当如何工作给出了合理的说明。

这个决定有三个输入，而不是一个

内部名称、对运营商的信任和可达性共同决定正确的安排。只有 VPN 解析器才知道的名称会强制使用分离 DNS：内部后缀交给推送来的解析器，其余一律按你为公共名称选定的策略处理。对运营商的信任决定公共名称是否也要交给这个解析器，还是交给单独的服务。可达性决定你选定的加密解析器在这个网络上是否可用。

这些行里没有一条是通用建议。由 VPN 运营的解析器会把观测集中在该运营商那里；单独的服务则为被查询的名称多增加一个接收方。除非你读过政策，否则哪种安排都无法证明留存情况。

把决定按配置档案写下来，因为这些设置会漂移。上个月推送了解析器的档案，今天可能什么都不推送，而浏览器会欣然保留一个仍在应答的旧自定义端点。笔记里该记的是解析器地址、它负责的后缀和浏览器模式，而不是服务的品牌。

测试你以为已经配好的策略

按名称测试，而不是按徽标。通过系统解析器解析一个公共名称和一个内部名称，然后在浏览器内用它自己的安全 DNS 设置，以你打算使用的模式重复一遍。如果内部名称只在浏览器里失败，你就找到了接收方不匹配的问题，而完全没碰任何 VPN 设置。

然后重连并检查恢复情况，因为交接的 bug 就藏在那里：断开连接，确认上一解析器回来了；重新连接，确认被推送的那个也回来了。最后，如果你有受管策略的浏览器，也测一下，因为那种模式可能直接拒绝你的改动，然后悄悄保留原来的解析器。

从命名空间这个问题入手，你就能避开其中大部分麻烦。如果这台机器必须访问内部名称，浏览器的加密解析器只是关于公共那一半的决定，内部那一半仍然留给 VPN 推送的解析器。