同时使用 Tor 和 VPN 时 DNS 走向何处

两个隐私工具同时运行，一个页面打不开，而解析器测试显示浏览器之外的某个程序收到了一个名称。在它变成泄漏报告之前，先弄清它来自哪一次交互。Tor 加 VPN 的配置至少包含 三个分属不同归属者的名称查询，按它们实际发生的顺序逐一梳理，是看清哪一个行为异常的最快办法。

在称之为泄漏之前，先为每一次交互命名

第一次交互解析的是 VPN 端点本身，它发生在任何保护存在之前。第二次为 Tor Browser 解析一个目标，浏览器可以把名称交给代理，而不是在本地解析。第三次覆盖机器上其余一切，包括更新检查、邮件客户端以及操作系统自身的服务查询。只有第一次可以在另外两次不参与的情况下发生。

每一次都可能走不同的路径，而浏览器里的一次测试只能观察它自己的请求。把一个结果当成三者的状态，正是大多数混淆的起点。

在改动任何东西之前，先写下哪些名称属于哪一层。私有组织名称、公开目标和隧道端点本身并不具有相同的要求，把它们当作同一类别的策略一定会弄坏某些东西。

引导阶段的查询发生在隧道之前

以主机名配置的客户端必须解析该名称才能打开隧道，而在那一刻并不存在可以承载查询的隧道。当前网络上操作系统提供的任何解析器都会应答，它可能是强制门户、酒店解析器或公共解析器。这不是隧道内的泄漏，因为此时还没有隧道。

修改浏览器的安全 DNS 设置也不会触及这次查询，因为它属于在浏览器之外运行、并在任何页面打开之前就启动的服务。如果端点名称无法解析，隧道内的任何策略都无济于事，因为故障发生在配置所描述的一切之前的一个环节。

这是唯一一处：为端点使用字面地址（如果提供商支持）会移除一项依赖，而不是增加一项。它同时也失去了跟随轮换地址的提供商的能力，所以这个取舍是真实的，应当被决定，而不是被发现。

浏览器与机器其余部分不同

Tor 的 SOCKS 接口支持把目标主机名传给代理，这意味着由远端执行解析，本地机器从不过问。支持代理的通用应用可能先在本地解析名称，再连接得到的地址，这就为用户以为已经走代理的目标产生了本地查询。因此，两个应用可能共享同一项代理设置，却在不同位置泄漏。共享的代理地址本身并不能告诉你是哪一种行为在起作用。

启用安全 DNS 时，浏览器又多了一层，因为浏览器可以选择自己的提供商，并完全绕过系统解析器。与此同时，隧道客户端可能把解析器推送进隧道，供整台机器使用。这两项设置可以同时正确，却仍然描述着不同程序的不同行为。

检查发出请求的程序，而不是从一张测试页面外推。隧道内承载的查询与从未到达 Tor 的查询之间的区别，正是一个解析器地址无法显示的区别。

逐个检查程序，然后与意图对照

把观察分开做：系统会用什么、浏览器被配置成用什么，以及 SOCKS 连接携带的是名称还是地址。最后一点正是远程解析与本地解析的差别，而 SOCKS 扩展规范 说明了主机名是如何被传递而不是先被解析的。

resolvectl status | grep -E "Current DNS Server|DNS Servers"
ss -tnp '( dport = :9050 )'
dig +short dev.internal.example
getent hosts vpn-endpoint.example.net

然后把观察到的与原本意图作比较。由你选择的解析器经隧道解析的公开名称，与回退期间交给公共解析器的私有名称，并不是同一个发现，通常也只有后者需要处理。前者是按设计工作的配置，即使它在报告里显得陌生。

把你接受的例外记录下来，包括无法被保护的引导查询。写下来的例外是一项设计决定，而同样的例外若在事后被发现，看起来就像缺陷。发现它的人会把它当作缺陷，而你将花整场会议解释为什么它不是。