手机上的 Private DNS 为什么会破坏 VPN 域名解析

隧道保持连接，其他所有指标也都正常，应用却无法解析域名。在手机上，常见原因是解析器由设备而非 VPN 配置选择。两项设置都可能声称对同一次查询拥有决定权。弄清哪一项胜出，以及它究竟能否回答这个问题，比改动隧道更快。

两项设置决定同一个域名

手机的 Private DNS 设置会为设备选择解析器，模式从自动选择一直到指定的主机名。VPN 配置也可能同时推送自己的解析器，而两者由不同的界面、不同的管理者分别配置。两者未必对每个应用都能压过对方。因此可用的隧道和失败的查询可以并存而不矛盾。

浏览器还能再加一层，因为浏览器内置的安全 DNS 可能自行选择服务商。只有报出错误的应用，才能可靠地指出三者中究竟是哪一个作了回答。解析器本身也必须能够回答。仅在公司内部存在的域名不在公共解析器的数据中，所以查询失败是内容问题，而不是连接问题。

按你需要的域名选择模式

如果设备必须解析内部域名，解析器就必须持有这些区域，通常意味着隧道提供的解析器，或组织有文档说明的分域 DNS 方案。如果只关心公共域名，严格的加密解析器是可辩护的选择，它还能去掉明文查询。决定来自域名本身，而不是对加密的偏好。

失败时的表现也随模式不同。严格选择却无法连到自己的解析器，会让每个域名都失败；而允许回退的模式可以让公共域名照常、内部域名失灵。这一差别让你在打开设置界面之前就知道自己处在哪种模式。在受管设备上，获批的策略说了算，用户无法安全地绕过。在个人环境里，做一次有记录的对比就足以定位冲突，事后应恢复原本的隐私设置，而不是让它一直处于关闭状态。

确认是哪个应用在发问

在报错的那个应用里复现失败，并记录错误属于域名错误还是连接错误。一个应用报域名错误、另一个应用页面正常，这是两个解析器的特征，而不是隧道坏了。

adb shell settings get global private_dns_mode
adb shell settings get global private_dns_specifier
adb shell dumpsys connectivity | grep -i -m 5 dns

这些命令读取设备当前配置，而厂商定制可能重命名或限制底层取值，因此把输出当作线索而非规范。Android 关于 Private DNS 的文档说明了各种模式以及设备期望的主机名形式。

把这个答案与 VPN 配置推送的解析器作对比。如果两者不一致，你就找到了冲突，剩下的问题就是组织希望哪一个胜出。

做过一次对比后恢复原本的设置

改动一项设置，重新测试两个域名，然后把设置改回去。被留在宽松模式下的设备会解析内部域名，并悄悄把每次公共查询发给最先应答的一方，这是没人记录过的隐私变化。

把结论写成规则：内部域名走这个解析器，公共域名走那个，浏览器跟随或不跟随设备。点名了解析器的规则可以检验，而写着「VPN 已修好」的备注不能。然后检查设备上是否还有其他东西依赖你改过的解析器。更新检查、强制门户探测和邮件客户端都会发出自己的请求，它们失败时，用户往往报告为不相关的问题。