分流隧道排除的是浏览器，而不是它的 DNS 查询

直连的数据路径不会移动名称解析。先查清哪个解析器收到查询、这是否是预期，再把它叫作泄漏。

浏览器已排除在隧道之外，公网 IP 页面也确认它的流量从家庭宽带出去，可内部 wiki 依然打不开。名称解析走了另一条路，而那条路通常是 VPN 配置的解析器。在多数分流隧道设计里，数据路径和解析路径是两个独立决定。在判定排除配置损坏之前，先查清浏览器实际用了哪一个。

数据路径与解析路径分开

排除只是把应用的报文从隧道里拿出来，这是数据路径上的路由和防火墙决定。名称解析是另一种查询：进程去问系统的解析器，由那个解析器决定哪台服务器收到问题。

两者可以都是有意为之，而且互不相同。办公部署可能把内部命名空间留在企业解析器上，同时把选定的公网浏览送出隧道，正因为内部名称在别处根本解析不了。令人困惑的是相反情形：公网站点打不开，是因为浏览器从未询问部署所预期的那个解析器。把路由和解析器分开记录，一半争论就会消失。

找出是哪个进程在提问

浏览器可以使用系统解析器、自带的加密 DNS 服务，或操作系统按网络分配的解析器。第一种遵循平台策略，第二种完全绕开该策略，第三种则取决于查询被路由到哪条链路。

resolvectl status
resolvectl query intranet.example.net
dig +short +time=2 intranet.example.net @10.52.0.2
scutil --dns | head -n 40

测试前先读生效配置：哪些链路承载 DNS 服务器、它们声明了哪些命名空间，以及按名称的策略是否覆盖默认值。Linux 上分流 DNS 用路由域；Windows 上名称解析策略表对命名空间起同样作用。两者都无法从泄漏测试页面看到。

决定哪个解析器看哪个名称

动手前先把预期映射写下来：内部名称交给企业解析器，公网名称交给策略允许的服务，例外要指定负责人。没有这份清单，泄漏测试的每个标签都会变成没人能裁决的策略争论。

然后检查浏览器自身的设置，因为浏览器里的加密 DNS 会在操作系统收到查询之前生效。用户为绕过强制门户而开启它，就等于悄悄覆盖了部署选定的解析器。这是配置决定而不是泄漏，值得一次决定而不是一份黑名单。

不要为了一个测试标签变绿就重写每个 DNS 字段。标签描述的只是某一时刻、某个进程发出的一次查询。

分别验证查询与连接

把两条路径分开测。连接测试显示数据路由，解析器测试显示谁收到了名称。

curl -sS --max-time 8 https://api.ipify.org
resolvectl query example.net
dig +short example.net

也要显式询问解析器，这样才能把失败归因于服务器而不是路径。然后重启浏览器再试，因为应用会缓存否定应答，过期的失败看起来像一直存在。

批准变更后，把数据路由和 解析器接收方写成两行 并记上日期。如果下次重连时行为又回来，要修的是提供该行为的配置文件，而不是浏览器。

相关文章