如何在 macOS 上检查 DNS 泄漏

你打开 VPN，图标显示已连接，查询 IP 的网站也给出了新的地址，一切看起来都对。可是你的 Mac 仍有可能向错误的对象询问网站在哪里，而“已连接”的图标并不会告诉你这一点。本文介绍如何用机器上自带的工具，加上一次在线测试，检查 mac vpn dns leak（Mac 上的 DNS 泄漏），并教你解读看到的结果。

如果想先了解理论，什么是 DNS 泄漏讲解了概念，DNS 如何工作说明了查询链条。这里默认你已具备基础，想要一套能在 macOS 上反复执行的流程。

Mac 上的 DNS 泄漏是什么意思

每次打开网站，Mac 都会请 DNS 解析器把域名翻译成 IP 地址。VPN 正常工作时，这个询问应当在隧道内传到 VPN 选定的解析器。发生泄漏时，询问则经由普通连接发给路由器、网络运营商或咖啡馆网络的解析器。页面照常加载，VPN 图标仍然是绿色，唯一的变化是运营那个解析器的人能看到你查询过的网站名单。

这份名单并不是无关紧要的小事，它显示你使用了哪些服务以及何时使用。泄漏不会暴露页面内容，因为那部分在隧道里是加密的，但它削弱了许多人开启 VPN 的理由之一。

Mac 上还有一个特别之处：macOS 并不只保存一个全局 DNS 服务器，而是保存一组解析器，每个与某个网络接口绑定，有时还与特定域名绑定，由系统针对每次查询决定使用哪一个。这种灵活性使泄漏可能藏在其他系统没有的地方，这也是终端视图有用的原因。

macOS 如何选择 DNS 服务器

一个简短的思维模型能让后面的内容更容易理解。

• 每个网络服务（Wi-Fi、以太网、VPN）都可以提供 DNS 服务器，可能是从网络自动获得的，也可能是你手动填写的。
• 系统解析服务 mDNSResponder 为几乎所有应用回答查询，它根据接口顺序、特定域名规则以及解析器是否可达来决定询问哪一个。
• 工作正常的 VPN 会添加一个与隧道接口绑定的解析器，并安排它在一般查询中优先。
• 有些应用完全绕开系统。带有自身安全 DNS 设置的浏览器，会把查询直接发给它选择的服务商，不管系统怎么设置。

所以有两个问题：系统认为自己在做什么，以及各个应用实际上在做什么。完整的检查要两方面都看。

第一步：连接前先记录 DNS

你需要一个基线。先断开 VPN，然后这样做。

1. 打开系统设置，进入网络，选择当前使用的连接（Wi-Fi 或以太网），点击详细信息，再打开 DNS 标签页。不同 macOS 版本的名称略有差异。记下列出的服务器。如果列表是灰色的自动状态，说明由路由器提供。
2. 在终端输入 scutil --dns。输出很长，请看第一个名为 resolver #1 的区块，记下其中的 nameserver 行和 if_index 项，后者说明接口名称（例如 en0）。
3. 也可以输入 networksetup -getdnsservers Wi-Fi。它会列出你手动设置的服务器，或显示 “There aren’t any DNS Servers set”，表示 Mac 使用的是网络分配的服务器。如果你的连接名称不同，可用 networksetup -listallnetworkservices 查看名称列表。

把解析器地址记下来。典型结果是像 192.168.1.1 这样的私有地址（你的路由器，属于 RFC 1918 规定的私有范围），或你以前选过的某个公共解析器的地址。

第二步：连接后对比

连接 VPN，等几秒钟，然后再次运行 scutil --dns 并对比。

健康的结果通常是这样：

• 出现一个与 utun 接口绑定的解析器，并且排在靠前的位置。
• 一般查询的默认解析器不再是你在第一步记下的路由器地址。
• 仍然指向 en0 的解析器，只与特定域名（例如某个本地网络名称）绑定，而不是对所有查询生效。

需要警惕的迹象：

• Resolver #1 与基线一致，仍然指向 en0 和路由器地址。
• 完全没有 utun 的解析器。
• 出现多个解析器，且 en0 上的排在隧道那个之前。

只凭这些不要下太多结论。输出显示的是配置，而不是某次具体查询走过的路径。把它当作早期指标，再用测试来确认。

第三步：运行在线 DNS 泄漏测试

在浏览器中打开一个 DNS 泄漏测试页面。如果提供扩展或完整测试，请选它，因为它会发出许多唯一的查询并收集回答。页面随后会列出真正替你发问的解析器，通常还会标明运营方。

结果可以这样读。

你看到的	可能意味着
只有 VPN 一侧的解析器，或与你的基线不同	在这个浏览器里没有发现泄漏
你家路由器或网络运营商的解析器	发生泄漏：查询离开了隧道
你没有设置过的大型公共解析器	可能是浏览器的安全 DNS、某个描述文件或你忘记的设置，需要排查
与连接前相同的解析器列表	VPN 可能根本没有改变 DNS
两类混合出现	部分泄漏，常见于 IPv6 或特定域名规则

还有几点需要注意。测试显示的是测试网站看到的解析器，而大型 DNS 服务商会从许多地址回答，所以同一运营方可能出现多行。解析器旁显示的国家只是根据地址的推测。另外，在线页面只能反映你所用的那个浏览器，所以某个浏览器里结果干净，并不能说明其他应用的情况。

如果想做更宽泛的检查，EFF 的 Cover Your Tracks 网站也会测试浏览器泄露的信息，不过它侧重于浏览器指纹，而不只是 DNS。

第四步：用终端检查系统解析器

在线测试跑在浏览器里。想知道系统本身做了什么，就直接问它。

• dscacheutil -q host -a name example.com 使用与大多数 Mac 应用相同的路径解析域名。它会打印地址，但不会说明是哪台服务器回答的，所以只能确认解析是通的。
• nslookup example.com 会打印一行 Server:。要知道 nslookup 读取的是它自己那份解析器设置，可能与 mDNSResponder 为应用使用的不同。如果 Server: 显示路由器，而 scutil --dns 显示隧道解析器，并不能证明发生了泄漏。
• dig example.com 会打印答案和一行 SERVER:，注意事项相同。如果你的 Mac 上没有 dig，用 nslookup 也行。

用 dig @地址 example.com 可以强制向指定解析器发起查询，用来确认某个解析器是否可达，但请记住，这样做绕过了系统自己的选择，并不能证明是否泄漏。

坦率地说：终端工具告诉你 Mac 被配置成怎么做，在线测试告诉你究竟是什么到达了互联网上的 DNS 服务器。好的诊断两者都用。

Mac 上特有的泄漏原因

如果泄漏确实存在，几乎总是下面的某一个原因。

1. 手动填写的 DNS 服务器。 如果你曾在网络面板里手动设置过 DNS，有些 VPN 应用无法覆盖它，手填的服务器会继续回答。删除它，恢复为自动。
2. DNS 描述文件或加密 DNS 配置。 在系统范围设置加密 DNS 的配置描述文件，其优先级可能高于 VPN 的解析器。到系统设置的描述文件部分（通用，然后是设备管理或描述文件）看看有没有不认识的条目。
3. iCloud 专用代理（Private Relay）。 它改变 Safari 及部分流量离开 Mac 的方式，让结果难以解读。关闭后再对比，并记住隐私中继与完整 VPN 是两种不同的工具。
4. 浏览器的安全 DNS。 Chrome、Firefox 等浏览器可以通过 HTTPS 把查询发给它们选择的服务商，RFC 8484 描述了这一机制。如果该设置开启，浏览器可能有意忽略 VPN 的解析器。
5. IPv6。 如果你的网络提供 IPv6，而 VPN 只覆盖 IPv4，查询或流量可能在隧道外通过 IPv6 发出。
6. 服务顺序。 同时有 Wi-Fi 和以太网，或接了 USB 网卡时，网络服务的顺序会影响先尝试哪个解析器。
7. 其他网络工具。 第二个 VPN、内容过滤器、安全软件套件，或开发用的本地 DNS 缓存，都可能拦截查询。
8. 强制门户与不稳定的重连。 刚从睡眠中唤醒或刚连上酒店 Wi-Fi 时，在隧道重建之前，Mac 可能会暂时使用网络提供的解析器。

修复泄漏：按难度由易到难

从最容易的改动开始，每改一步就测试一次。

1. 断开并重新连接 VPN，再重新测试。许多泄漏只是暂时的。
2. 清除缓存：sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder。缓存的答案可能掩盖真实情况。
3. 把 DNS 恢复为自动：如果你手动填过服务器，到网络、详细信息、DNS 中改回。
4. 测试时关闭浏览器的安全 DNS，同时关闭专用代理。如果泄漏消失，说明找到了原因，你可以决定哪个设置对自己更重要。
5. 删除不认识的描述文件，前提是确认它们不是雇主或学校安装的。
6. 检查 IPv6。 如果 VPN 没有覆盖它，可在网络、详细信息、TCP/IP 中为测试的连接关闭它，看是否就是来源。
7. 重启 Mac 以清除解析器状态，然后在打开任何其他应用之前重新连接。
8. 联系支持。 如果什么都没变，请带上基线和测试结果。Mac 故障排查指南列出了需要准备的内容。

不要把论坛帖子里随手找到的终端命令直接粘贴到你依赖的 Mac 上。上面的命令只读取设置或清除缓存，日常检查做到这一步就够了。

一个完整的例子

Sofia 在咖啡馆用 MacBook 办公。在家时，scutil --dns 显示 resolver #1 是 en0 上的 192.168.1.1。到了咖啡馆，她连接 VPN 并再次运行命令。Resolver #1 现在指向 utun4 上的一个地址，路由器地址被挪到列表下方，并且绑定在一个本地域名上。她运行了扩展版在线测试：列出的解析器不是咖啡馆的服务商。她在第二个浏览器里重复测试，结果相同。

接着她在常用浏览器里打开安全 DNS，想看看会有什么变化，测试里出现了一个她一年前选定的大型公共解析器。VPN 没问题，只是浏览器设置在按自己的方式工作。她决定在公共网络上把它关掉，并写进一份简短的清单。现在她的流程只要三分钟：记录基线、连接、对比、在两个浏览器里测试。

何时重复检查，以及干净的结果意味着什么

在 macOS 更新后、安装其他网络工具或描述文件后、换了新路由器之后，以及在新 Mac 上设置 VPN 时，都要重新执行这套流程。保存好基线，对比起来更快。

干净的结果表示：在被测试的条件下，你的查询没有到达平时的解析器。这并不证明 VPN 完美无缺，也不说明 VPN 服务商自己的解析器能看到什么，因为 VPN 的意义在于转移信任，而不是消除信任。它也不涉及其他类型的泄漏。如果想要完整流程，VPN 测试一文涵盖 IP、WebRTC 和 kill switch 检查，而检查 VPN 是否在工作是快速版。

总结

要检查 Mac 上的 DNS 泄漏，先在连接前记录解析器，连接后用 scutil --dns 对比，再用扩展版在线测试在不止一个浏览器里确认。如果发现泄漏，常见的嫌疑对象是手填的 DNS 服务器、描述文件、专用代理、浏览器安全 DNS、IPv6、服务顺序或其他网络工具。一次修一项，每次改动后都重新测试。Mac 准备好之后，可以下载 VPNclient 应用，并在价格页面查看通行证。