专用 DNS 与 VPN：每一层究竟覆盖了什么

你的手机把专用 DNS 设置为某家提供商的域名，同时还有一个 VPN 应用在运行。很自然会认为其中一个接管了名称查询。按这句话的意思，两个都没有，而看清原因的最快办法，是从你点开链接的那一刻起，追踪一个请求。

这两个功能处在同一段旅程的不同环节。专用 DNS 加密的是你向解析器提出的问题。VPN 改变的则是答案所对应连接的走向。

所以，在一台两者都已启用的设备上按顺序走一遍，并留意每一层还能看到什么。

第一步：查询离开应用

你点开一个链接。在任何连接建立之前，应用需要这个域名对应的地址。在 Android 上，相关页面是“设置、网络和互联网、专用 DNS”。选择提供商域名会让设备进入严格模式：它通过 853 端口向该域名发起基于 TLS 的 DNS 查询；如果加密交换失败，查询就会失败，而不会悄悄退回 53 端口的明文。

这与“自动”有实质区别：自动模式采用机会式加密，当网络干扰时会乐于使用未加密的解析器。如果你的目标是查询绝不走明文，那么使用提供商域名的严格模式才是与之匹配的设置。

这就是这次走查揭示的第一件事：查询在本地网络这一段受到保护，但解析器仍然知道了这个名字。加密覆盖的是这一跳。那家解析器的运营者看得到查询，因为回答查询正是它的工作。

第二步：连接走另一条路

解析器返回一个地址，应用连接到该地址。这一步不受查询如何加密的影响。没有隧道时，连接从你通常的公网地址出去；无论 DNS 是否加密，目标 IP 和 TLS 握手通常仍会让网络看到域名。

打开 VPN 后，变化的正是这一步。符合客户端路由策略的流量走隧道，本地网络看到的是通向 VPN 端点的连接，站点通常看到的是出口地址。名称解析也可能在隧道内进行，取决于客户端下发了什么。

这种分工就是整个比较的一句话版本。DNS 加密回答的是“谁能读到问题”。VPN 回答的是“对话走向哪里”。

第三步：进入隧道后，DNS 变成策略问题

现在两个功能开始相互作用，而浏览器是常见的意外来源。自带安全 DNS 设置的浏览器，可能通过 HTTPS 把查询发给它选定的解析器，而不是去问操作系统。Android 的专用 DNS 设置管不到这个决定。

在 Firefox 中，开关位于“设置、隐私与安全、启用安全 DNS”。在 Chrome 中，位于“设置、隐私和安全、使用安全 DNS”。两者都可以指定某家提供商，也可以保持关闭；一旦开启，隧道下发的 DNS 配置对这些查询就会被绕过，尽管页面流量仍然走隧道。

如果 VPN 下发自己的解析器，而浏览器坚持用自己的，就会出现割裂：名字能解析、页面能加载，但本该走隧道的查询却直接出去了。解析器地址与 VPN 端点不同，本身并不等于泄漏，但一条与你声明的意图相矛盾的查询路径值得修。

第四步：内网名称才是出问题的地方

连接公司 VPN，打开一个内网主机。如果浏览器的安全 DNS 开着并指向公共解析器，那么对浏览器来说这个名字根本不存在。隧道是通的，其他一切正常，只有一个域名报错，看起来像是站点挂了。

同样的故障在 Android 上会反向出现。使用公共提供商的严格专用 DNS 不会解析只有内网解析器才知道的名字，而严格模式没有回退。把手机的 DNS 在公共加密解析器和企业解析器之间拆开，不是一个设置问题，而是路由策略问题，必须由运营 VPN 的人来回答。

在怪罪隧道之前先检查这一点：先查询内网名称，再在关闭浏览器安全 DNS 的情况下查询同一个名称。如果能解析，问题就在解析器的选择上，而不是连接。

这次走查告诉你该改什么

几乎全部内容都落在四个页面上。按这个顺序看，并写下每一项说什么，因为答案通常就在组合里：

1. Android 设置、网络和互联网、专用 DNS：自动，或某个提供商域名，以及是哪一个域名。
2. 浏览器的安全 DNS 设置：关闭，或固定到某个解析器。
3. VPN 客户端的 DNS 策略：是否下发解析器，分流隧道是否排除了仍然需要名称的东西？
4. 在隧道开启时对内网域名做一次测试，跑两遍：一遍开着浏览器 DNS，一遍关掉。

然后让改动去匹配需求，而不是反过来。如果需求是查询加密出去、并到达你选定的解析器，就设置严格专用 DNS，并让浏览器与之一致。如果需求是流量从别处出去，就配置隧道，别再指望某个 DNS 设置能挪动你的地址。

同时别忘了边界。这两个功能都不能让恶意目标变安全，也都不能抹掉你登录时使用的身份。加密改变的是谁能读到问题；隧道改变的是连接走向哪里；这两者都不会让账号匿名。