VPN 与 DNS 安全：哪些内容受到保护？

手机在加载任何一个页面之前，都得先回答一个简单的问题：这个网站的地址是什么？这个问题以及它的答案，就是域名系统，即 DNS。正因为 DNS 发生在页面加载之前，它很容易被人忘记，也是隐私悄悄外泄的地方之一。人们常说 VPN"加密一切"，那么对 DNS 来说，这到底意味着什么？开着 VPN 时，谁还能看到你的查询？又怎样判断哪里出了问题？

本文跟踪一次 DNS 请求的全过程，先看没有 VPN 的情形，再看有 VPN 的情形。你会看到哪些环节受到保护，哪些没有，泄漏是怎么发生的，以及一套在自己设备上做测试的简短流程。这是一般性科普，不承诺在所有网络或设备上都能提供保护。

一次 DNS 请求包含哪些信息

DNS 把 example.com 这样的名字翻译成数字形式的 IP 地址。Cloudflare 对 DNS 的讲解是很好的通俗概览，最初的概念记录在 RFC 1034 中。我们自己的DNS 如何工作一文更深入地讲解了完整链条。

一次请求通常会暴露：

• 你想访问的域名，比如银行、诊所、新闻网站或论坛。这对隐私最重要，因为它说明了你的兴趣。
• 所请求的记录类型，例如网站的地址或邮件服务器。
• 你的 IP 地址，因为答案要送回给你。
• 时间，因为解析器能看到请求何时到达。

通常，DNS 请求以明文、不加密的形式传输，多半走 UDP 的 53 端口。路径上任何能捕获流量的人都能读到。这就是 DNS 成为好奇的网络所有者和攻击者共同偏爱目标的原因。

没有 VPN 时，一次查询的旅程

想象你在咖啡馆的网络上打开一个新闻网站。

1. 手机问咖啡馆的路由器："新闻网站的地址是什么？"
2. 路由器把问题转发给一个解析器，通常是网络服务商分配的那个，除非你改过。
3. 解析器回答；如果不知道，就去问更多服务器。
4. 手机拿到地址，连接到网站。

好几方都能看到这个问题：咖啡馆网络的所有者、路由器、运营解析器的网络服务商，以及任何在网络里嗅探的人。他们不需要看到页面本身，就知道你想访问哪个网站。此外，控制路由器的攻击者还能用错误的地址回答问题，这就是 DNS 劫持的基础。关于它如何运作，请看 DNS 劫持。

有 VPN 时，一次查询的旅程

现在在开启 VPN 的情况下重演同一场景。

1. 设备想查询新闻网站。VPN 应用已经让操作系统把包括 DNS 在内的流量通过加密隧道发送。
2. 问题被加密后送往 VPN 服务器。咖啡馆的路由器只看到发往同一个地址的加密数据。
3. VPN 服务器把问题交给 DNS 解析器，通常由服务商自己运营或为其运营。
4. 答案经由隧道返回，设备连接网站，连接同样经过隧道。

变了什么？咖啡馆网络的所有者、路由器和网络服务商不再能读取问题或在途中修改答案。没变什么？解析器仍然看到问题，目的网站仍然看到来自 VPN 服务器的连接。你把信任从本地网络转移到了 VPN 服务商。这才是描述 VPN 的正确方式：它转移了可见性，而不是消除可见性。想进一步了解服务商能获知什么，请看 VPN 服务商能看到什么。

哪些受到保护，哪些没有

DNS 的方面	没有 VPN	有正常工作的 VPN
本地网络能读取查询	能	不能，已被加密
网络服务商能读取查询	能，如果它运营解析器或看到明文 DNS	不能，只看到加密隧道
路由器能篡改答案	能	难得多，因为答案在隧道内返回
解析器看到域名	看到（网络服务商的解析器）	看到（VPN 的解析器）
目的网站看到你的真实 IP	看到	看不到，看到的是 VPN 服务器地址
网站是否真实	不检查	不检查
设备设置导致的泄漏	不适用	配置错误时可能发生

这张表给出了主要结论：VPN 保护 DNS 免受你与 VPN 服务器之间那些人的窥视，转而信任 VPN 的解析器。

DNS 泄漏是怎么发生的

DNS 泄漏指的是，即使 VPN 看起来已连接，部分查询仍在隧道之外传输。我们专门的文章 DNS 泄漏解释了症状，这里列出常见机制。

• 操作系统行为。 有些系统会同时向多个解析器发送 DNS，并接受最快的回复。如果其中一个解析器在隧道之外，你的请求副本就泄漏了。
• 浏览器设置。 浏览器可能使用自带的加密 DNS 服务，而不是系统的，所以查询绕过了 VPN 的解析器。这不一定是问题，但你应该知道解析器是谁。参见 VPN 与浏览器 DNS。
• IPv6。 如果隧道只处理 IPv4，IPv6 的查询和流量可能绕过隧道。请看什么是 IP 泄漏。
• 分流（Split tunneling）。 你排除在隧道外的应用，按设计会使用常规解析器。这是预期行为，但要清楚是哪些应用。
• 重连间隙。 VPN 断开后的片刻，系统可能在隧道恢复前就恢复了常规 DNS。
• 手动设置的 DNS。 在设备或路由器上固定的 DNS 服务器，可能覆盖 VPN 提供的设置。

一个例子：咖啡馆，三种结果

以娜塔为例，她在咖啡馆里读工作邮件和几个新闻网站。我们看同一个小时的三种配置。

没有 VPN。 咖啡馆 Wi-Fi 把她的查询发给网络服务商的解析器。店主的路由器可能记录每个域名。一个强制登录页先出现了，这很正常，她在页面里输入了邮箱地址，没注意到这个网络并不熟悉。

开着 VPN 但在泄漏。 她连上 VPN，应用显示绿色。泄漏测试显示的却是咖啡馆网络服务商的解析器。浏览器里的某个设置，或手动固定的 DNS 地址，覆盖了 VPN。网页内容是加密的，但域名清单可以被看到。

开着 VPN 且没有泄漏。 同样的测试显示的是 VPN 服务的解析器。咖啡馆网络只能看到加密隧道。域名被 VPN 的解析器知晓，这是她主动选择的信任对象。

第二种和第三种配置之间唯一的差别，是一个配置细节。这就是为什么测试比假设更重要。

五分钟测试你自己的设置

1. 断开 VPN，打开一个 DNS 泄漏测试页面。记下解析器名称和所属机构，这是你的常态基线。
2. 连接 VPN，等几秒再重新加载测试。解析器列表应变成与 VPN 服务相关的，而不是你的网络服务商。
3. 在你日常使用的浏览器里重复一遍。 如果它有自带的安全 DNS 选项，看看结果是否不同。
4. 分别在移动数据和 Wi-Fi 上测试。 有些泄漏只在其中一种网络上出现。
5. 检查 IPv6。 如果测试显示了属于你服务商的 IPv6 地址，说明隧道没有覆盖 IPv6。
6. 做一次重连检查。 关闭再打开 Wi-Fi，然后立刻再次运行测试。
7. 记下发现的结果。 如果泄漏持续存在，我们的帮助指南检查 VPN 是否在工作介绍了进一步的做法。

如果结果发生了变化，说明你设置中的 DNS 部分在正常履职。

DNS over HTTPS、DNS over TLS 与 VPN

DNS over HTTPS（RFC 8484）和 DNS over TLS（RFC 7858）等加密 DNS 协议，不需要 VPN 就能向本地网络隐藏查询。它们只解决 DNS 的可见性问题，并把信任转移给加密 DNS 的服务商。它们不会隐藏你随后连接的网站地址。VPN 则覆盖整个连接。如果你想要详细对比，DNS over HTTPS 与 VPN一文说明了什么时候单用其中一种就够，什么时候两者并用才合理。

需要记住的局限

• VPN 不会判断网站是否真实。一个逼真的假店铺，解析起来和其他网站没有区别。
• VPN 的解析器仍能看到你的查询，所以服务商是否诚实很重要。
• 如果设备已有恶意软件，DNS 设置可能被它修改。
• VPN 不会消除你登录的网站对你的追踪。
• 公共 Wi-Fi 的登录页有时需要先用常规 DNS，VPN 才能连接，因此短暂的无 VPN 状态是正常的。登录之后，请连接并重新测试。
• 公司和学校网络可能要求使用自己的 DNS，并可能不允许 VPN 覆盖它。

值得保存的简短清单

• 在共用网络上打开邮箱或网银之前，先连接 VPN。
• 安装后、系统大版本更新后、更换浏览器后，都做一次泄漏测试。
• 除非清楚原因，否则不要在设备上手动设置 DNS 地址。
• 测试时别忘了 IPv6。
• 使用 HTTPS 网站并查看地址栏。DNS 保护不能取代这一点。
• 定期更新 VPN 应用和系统。

XPASS 用户使用免费的 VPNclient 应用，凭 My Pass 页面上的用户名和密码登录。下载页面列出了各类应用，应用的默认设置是合理的起点。

总结

DNS 是设备在每次访问之前提出的问题，通常是公开地问。正常工作的 VPN 会把这个问题放进隧道，本地网络和你的网络服务商既读不到也改不了，而 VPN 自己的解析器能看到。泄漏发生在某个设置让查询绕过隧道时，五分钟的测试就能告诉你自己的设置是否如此。请保持符合现实的预期：DNS 保护降低的是暴露程度，并不决定哪些网站值得信任。

如果简单的预付方式适合用来补上这层保护，可以随时看看价格页面。