--- title: DNS 泄漏是什么、怎么检测、怎么防 date: 2026-05-10 categories: - DNS 专题 tags: - DNS泄漏 - 隐私 - TUN - Fake-IP - 安全 excerpt: DNS 泄漏意味着你的 ISP 仍然知道你在访问哪些网站。解释泄漏原理、检测方法和预防措施。 index_img: /images/posts/dns-leak.png --- > **摘要**: DNS 泄漏是指你以为所有流量都走了代理，但 DNS 查询实际上仍然发往了本地 ISP 的 DNS 服务器。这意味着你的 ISP（以及 GFW）仍然知道你在访问哪些网站。本文解释 DNS 泄漏的原理、检测方法和预防措施。 --- ## 什么是 DNS 泄漏 DNS 泄漏（DNS Leak）的定义很简单：**你以为自己完全走了代理，但你的 DNS 查询绕过了代理，直接发送到了本地网络上的 DNS 服务器（通常是 ISP 自动分配的）。** 这意味着什么？你的代理可能做得很好——数据传输全程加密，ISP 看不到你访问的网页内容。但 DNS 查询暴露了你的意图。ISP 的 DNS 日志里会清清楚楚地记录：这个用户在某个时间点查询了 `google.com`、`twitter.com`、`youtube.com` 的 IP 地址。 问题的严重性分几个层面： **第一，隐私暴露。** ISP 知道你在访问哪些网站。在中国大陆的网络环境下，这个信息本身就是敏感的。你不需要被看到访问的内容——"你在试图访问 Google"这一条信息就已经足够引起关注。 **第二，GFW 可见。** GFW 对 DNS 流量的监控是全面的。当你的 DNS 查询以明文形式发往 ISP 的 DNS 服务器时，GFW 可以轻松看到你在查询什么域名。即使你的实际数据流量通过加密代理传输，DNS 查询已经出卖了你。 **第三，DNS 污染可能破坏代理。** 这是很多人忽略的问题。如果你的 DNS 查询走漏到了本地网络，GFW 可以对这些查询进行 DNS 污染——返回一个伪造的 IP 地址。某些代理客户端在配置不当的情况下，会使用这个被污染的 IP 去建立连接，结果连接失败或者被劫持到错误的目标。 **第四，即使代理节点很安全，DNS 泄漏也会降低整体安全性。** 安全是木桶效应——最短的那块板决定水位。你花了大价钱买了高质量代理节点、用了最新的协议、选了最隐蔽的端口，但 DNS 泄漏一笔勾销了这些努力。 一句话总结：DNS 泄漏就像你换了一身伪装出门，但身份证掉在了门口。 --- ## DNS 泄漏是怎么发生的 DNS 泄漏不是一个单一的问题，它有多种触发场景。理解每种场景的发生机制，才能有针对性地预防。 ### 场景一：系统代理模式（最常见） 这是 DNS 泄漏最常见、最容易被忽视的原因。 系统代理（System Proxy）的工作方式是：在操作系统层面设置一个 HTTP/SOCKS 代理地址。当应用程序发起 HTTP 或 HTTPS 请求时，这些请求会被转发到代理客户端处理。 问题在于：**DNS 查询不是 HTTP/HTTPS 请求。** DNS 查询使用 UDP 协议的 53 端口。系统代理只接管了 HTTP/HTTPS 流量（TCP 80/443），对 UDP 53 端口的 DNS 查询完全不管。当你的浏览器想访问 `google.com` 时，操作系统首先要做 DNS 解析——这个 DNS 查询直接走本地网络，发送到 ISP 的 DNS 服务器。ISP 收到你的查询，知道你在找 `google.com` 的 IP。然后浏览器拿到 IP，通过系统代理发送 HTTP 请求——这部分确实走了代理，但 DNS 早就泄漏了。 这种泄漏的特点是**完全无感**。你看到浏览器设置了代理，网页也能正常打开，一切看起来都很正常。但你的每一次 DNS 查询都在本地网络上裸奔。 这就是为什么我们反复强调：**系统代理模式下，DNS 泄漏几乎不可避免。** 如果你在意隐私，请使用 TUN 模式。 > 关于系统代理和 TUN 模式的详细对比，参见 [TUN 模式 vs 系统代理](../software/tun-vs-system-proxy.md)。 ### 场景二：代理客户端 DNS 配置错误 即使你使用了 TUN 模式，DNS 配置错误仍然可能导致泄漏。 最典型的错误是在 `nameserver` 中直接使用国际 DNS 的明文地址： ```yaml # ❌ 错误配置 dns: nameserver: - 8.8.8.8 # Google DNS，明文 UDP - 1.1.1.1 # Cloudflare DNS，明文 UDP ``` 这个配置的问题是：DNS 查询使用明文 UDP 协议发送到 `8.8.8.8`。这些查询包会经过你的 ISP 网络——ISP 可以看到查询内容，GFW 也可以看到。更糟糕的是，GFW 会主动劫持发往 `8.8.8.8:53` 的 DNS 查询，返回被污染的结果。 结果就是：你以为自己在用 Google DNS，实际上你得到的是 GFW 伪造的响应。被污染的域名拿到错误的 IP，代理客户端再基于这个错误 IP 做路由决策——整个链路都被带偏了。 另一种常见的错误配置是在 Fake-IP 模式下配置了 `fallback`，并且 fallback 指向海外 DNS。虽然在 Fake-IP 模式下 nameserver 只会收到直连域名的查询，但 fallback 的存在会导致额外的 DNS 查询被发送到海外，这些查询走的是明文或加密通道取决于你的配置，但无论如何，它们增加了不必要的暴露面。 > 关于 Fake-IP 模式下为什么不需要 fallback，参见 [Fake-IP vs Redir-Host](./fake-ip-vs-redir-host.md)。 ### 场景三：应用绕过代理 某些应用程序不走操作系统的 DNS 解析流程，而是自己直接发送 DNS 查询。这种行为叫做"硬编码 DNS"。 典型例子： - **Chrome 浏览器**：在某些配置下，Chrome 会使用自己内置的 DNS 解析逻辑，绕过系统 DNS 设置。尤其是当 Chrome 的"安全 DNS"功能开启并配置了特定的 DNS 服务器时，这些查询不会经过代理客户端的 DNS 拦截。 - **Android 应用**：Android 上的部分应用会硬编码 DNS 服务器地址（如 `8.8.8.8`），直接通过 UDP 53 端口发送查询，完全绕过系统 DNS 和代理客户端。 - **某些即时通讯软件**：部分 IM 应用为了加速连接，会使用 HTTPDNS（通过 HTTP 接口查询 DNS，而非传统的 UDP 53 端口），这些查询可能不被代理客户端拦截。 在系统代理模式下，这些硬编码 DNS 查询会直接走本地网络，造成泄漏。即使在 TUN 模式下，如果 TUN 的 DNS 劫持配置不完善，某些应用的非标准 DNS 查询也可能漏网。 ### 场景四：IPv6 DNS 泄漏 这是一个越来越常见但经常被忽略的泄漏场景。 很多家庭网络环境同时具备 IPv4 和 IPv6 连接。代理客户端通常默认只处理 IPv4 流量。当你的系统有 IPv6 地址时，操作系统可能会通过 IPv6 网络发送 DNS 查询——这些查询完全绕过了你的代理客户端。 具体表现： - 你的代理客户端通过 TUN 模式接管了 IPv4 网络栈 - 但 IPv6 网络栈没有被接管 - 操作系统发起 DNS 查询时，可能优先使用 IPv6 - IPv6 的 DNS 查询直接走 ISP 的 IPv6 DNS 服务器 → 泄漏 这种泄漏特别隐蔽，因为大多数用户不知道自己的网络有 IPv6。你可以访问 `test-ipv6.com` 检查你的网络是否有 IPv6 连接。 更复杂的情况是：即使代理客户端在 TUN 模式下同时接管了 IPv4 和 IPv6，如果 DNS 配置中没有正确处理 AAAA 记录（IPv6 DNS 记录），客户端可能会在处理 IPv6 DNS 响应时出错，导致某些查询从旁路走掉。 ### 场景五：WebRTC 泄漏（关联问题） WebRTC（Web Real-Time Communication）是浏览器内置的实时通信功能，主要用于视频通话、语音聊天等场景。虽然 WebRTC 泄漏严格来说不属于 DNS 泄漏，但它经常和 DNS 泄漏一起被讨论，因为它导致的后果类似——暴露你的真实网络信息。 WebRTC 的问题在于：**它可以直接获取你的本地 IP 地址和公网 IP 地址，完全绕过代理。** WebRTC 使用 STUN 协议来发现你的公网 IP 和 NAT 类型。这个过程不走 HTTP 代理通道，也不走 SOCKS 代理。即使你已经通过代理上网，一个恶意网页只需要几行 JavaScript 代码，就能通过 WebRTC 获取到你的真实 IP 地址。 Chrome 和 Firefox 默认都启用了 WebRTC。这意味着除非你主动关闭它，否则你的真实 IP 随时可能被网页获取。 --- ## 如何检测 DNS 泄漏 知道了 DNS 泄漏的原理，接下来要做的是：确认你自己有没有泄漏。以下是三种检测方法，从简单到深入。 ### 方法一：在线检测工具 这是最简单、最直观的检测方式，适合所有用户。 **步骤：** 1. 确保你的代理已经连接，并且你正在使用代理上网（可以先访问 `google.com` 确认代理正常工作） 2. 打开浏览器，访问 [dnsleaktest.com](https://dnsleaktest.com/) 3. 页面加载后，点击 **Extended test**（扩展测试）——Standard test 只检测一次，Extended test 会进行多轮查询，结果更准确 4. 等待测试完成（通常需要 30 秒左右） 5. 查看结果 **如何解读结果：** - **没有泄漏**：结果中只显示你代理节点所在地的 DNS 服务器。比如你用的是香港节点，结果应该显示香港或海外的 DNS 服务器（如 Cloudflare、Google DNS 等）。 - **有泄漏**：结果中出现了中国大陆的 DNS 服务器 IP，或者出现了你 ISP 的 DNS 地址。这意味着至少有一部分 DNS 查询没有走代理，直接到达了你本地的 ISP DNS。 - **部分泄漏**：结果中同时出现海外和国内的 DNS 服务器。这说明你的 DNS 查询一部分走了代理，一部分走了本地——这也是泄漏。 除了 `dnsleaktest.com`，还有以下替代工具可以交叉验证： | 工具 | 地址 | 特点 | |------|------|------| | DNS Leak Test | `dnsleaktest.com` | 最经典的 DNS 泄漏检测工具 | | BrowserLeaks DNS | `browserleaks.com/dns` | 同时检测 DNS 和其他浏览器信息泄漏 | | IPLeak | `ipleak.net` | 综合检测 IP、DNS、WebRTC 泄漏 | | Mullvad DNS Check | `mullvad.net/check` | Mullvad VPN 提供的检测工具，界面简洁 | 建议至少用两个工具交叉验证。单一工具的结果有时可能因为网络波动不够准确。 ![DNS 泄漏检测结果示例](/images/inline/dns-leak-test.png) *图片来源：[Reddit](https://www.reddit.com/)* ### 方法二：代理客户端日志 如果你使用 Clash Verge、mihomo 等代理客户端，可以通过日志直接观察 DNS 查询的去向。 **以 Clash Verge 为例：** 1. 打开 Clash Verge，进入设置 2. 将日志级别设置为 `debug` 3. 打开日志面板（或查看日志文件） 4. 正常浏览网页，观察日志中的 DNS 相关条目 你需要关注的信息： - 每一条 DNS 查询的目标域名 - 该查询被发送到了哪个 DNS 服务器 - 查询是通过什么方式发起的（UDP、DoH、Fake-IP 映射等） 如果你看到 `google.com`、`youtube.com` 等应该走代理的域名出现在本地 DNS 查询日志中，说明存在泄漏。在 Fake-IP 模式下，这些域名不应该触发任何真实的 DNS 查询——它们应该直接被分配假 IP，然后在远端解析。 ### 方法三：Wireshark 抓包分析 Wireshark 是网络协议分析工具，可以捕获你网卡上的所有网络数据包。这是最精确的检测方法，适合需要深入分析的用户。 **步骤：** 1. 下载并安装 [Wireshark](https://www.wireshark.org/) 2. 打开 Wireshark，选择你正在使用的网络接口（Wi-Fi 或有线网卡） 3. 在过滤器中输入 `udp.port == 53`，只显示 DNS 流量 4. 开始捕获 5. 正常使用浏览器，访问几个不同的网站 6. 观察捕获到的 DNS 数据包 **如何解读：** - **没有泄漏**：在代理开启的状态下，过滤器 `udp.port == 53` 应该几乎捕获不到任何数据包。因为在 TUN + Fake-IP 模式下，DNS 查询要么在本地被 Fake-IP 拦截返回假 IP（不产生真实 UDP DNS 查询），要么通过 DoH（走 HTTPS，不走 UDP 53）发送。网卡上不应该出现明文 DNS 流量。 - **有泄漏**：你看到了发往 ISP DNS 服务器（如 `192.168.1.1` 或 ISP 分配的 DNS 地址）的 DNS 查询。数据包的详细信息里能看到查询的域名——如果这些域名包含 `google.com`、`youtube.com` 等需要代理的网站，确认泄漏。 - **DoH 查询**：如果你看到发往 `223.5.5.5`（阿里 DNS）或 `1.12.12.12`（腾讯 DNS）的 HTTPS 流量（TCP 443），但没有 UDP 53 流量，这说明你的代理客户端在使用 DoH 发送 DNS 查询。只要这些查询的目标是国内域名，这不算泄漏——这是正常行为。 Wireshark 抓包的另一个用途是检测 IPv6 DNS 泄漏。将过滤器改为 `udp.port == 53 && ipv6`，如果在代理开启时仍然捕获到 IPv6 DNS 查询，说明你的 IPv6 DNS 正在泄漏。 --- ## 如何防止 DNS 泄漏 检测完毕，如果发现泄漏，接下来就是修复。以下五个方案按推荐程度排序。 ### 方案一：使用 TUN 模式（最有效） TUN 模式是防止 DNS 泄漏最根本的方案。 TUN（网络隧道）模式在操作系统层面创建一个虚拟网卡，所有网络流量——包括 TCP、UDP、ICMP 等所有协议——都会经过这个虚拟网卡，被代理客户端接管。 与系统代理的区别在于： - **系统代理**：只接管遵循系统代理设置的 HTTP/HTTPS 流量，DNS（UDP 53）不在接管范围内 - **TUN 模式**：在网络栈的最底层接管所有流量，包括 DNS 查询。任何应用程序的任何网络请求，无论使用什么协议、什么端口，都逃不过 TUN 的拦截 在 TUN 模式下，即使应用程序硬编码了 DNS 服务器（如 `8.8.8.8`），这些 DNS 查询也会被代理客户端拦截并处理。应用无法绕过 TUN 的 DNS 劫持——因为所有流量都要经过虚拟网卡。 开启方法（以 [Clash Verge Rev](https://github.com/clash-verge-rev/clash-verge-rev) 为例）： 1. 打开 Clash Verge 2. 进入设置，找到 TUN 模式开关 3. 开启 TUN 模式 4. 首次开启可能需要管理员权限（安装虚拟网卡驱动） 注意事项： - TUN 模式需要管理员权限，因为它要在系统层面创建虚拟网卡 - 某些企业网络环境可能限制 TUN 模式的使用 - TUN 模式与其他 VPN 软件可能冲突——同一时间只能有一个 TUN 设备接管网络 > 关于 TUN 模式的详细原理和配置，参见 [TUN 模式 vs 系统代理](../software/tun-vs-system-proxy.md)。 ### 方案二：使用 Fake-IP 模式 Fake-IP 是从 DNS 解析层面杜绝泄漏的方案。 在 Fake-IP 模式下，代理客户端不会为需要走代理的域名发起任何真实的 DNS 查询。当浏览器请求 `google.com` 的 DNS 解析时，客户端直接返回一个假 IP（如 `198.18.0.1`），然后在数据连接阶段将域名传递给远端代理节点，由节点在海外完成真正的 DNS 解析。 从头到尾，`google.com` 的真实 DNS 查询从未在你的本地网络上发生过。ISP 和 GFW 看不到任何关于 `google.com` 的 DNS 请求——因为确实没有这样的请求存在。 对于直连域名（如 `baidu.com`），Fake-IP 模式会使用 `nameserver` 中配置的国内 DNS 进行真实解析。这些查询到达国内 DNS 服务器，但内容只是国内域名——这不构成泄漏，因为你访问 `baidu.com` 本来就是正常行为。 **Fake-IP + TUN 的组合是目前防止 DNS 泄漏的最佳方案。** TUN 确保所有流量都被接管，Fake-IP 确保代理域名从不在本地解析。两者结合，DNS 泄漏的可能性降到接近零。 ```yaml # ✅ 推荐配置 dns: enable: true enhanced-mode: fake-ip fake-ip-range: 198.18.0.1/16 nameserver: - https://doh.pub/dns-query - https://dns.alidns.com/dns-query ``` > 关于 Fake-IP 的详细原理，参见 [Fake-IP vs Redir-Host](./fake-ip-vs-redir-host.md)。 ### 方案三：正确配置 DNS 加密 即使你无法使用 TUN 模式（某些企业环境的限制），正确配置 DNS 加密也能大幅降低泄漏的风险。 传统 DNS 查询使用 UDP 53 端口明文传输。ISP 和 GFW 可以轻松读取查询内容并进行篡改。DoH（DNS over HTTPS）和 DoT（DNS over TLS）将 DNS 查询封装在加密通道中——即使查询被截获，第三方也无法读取查询的域名。 ```yaml dns: enable: true enhanced-mode: fake-ip nameserver: - https://doh.pub/dns-query # 腾讯 DoH — 加密传输 - https://dns.alidns.com/dns-query # 阿里 DoH — 加密传输 # 不要使用： # - 8.8.8.8 ← 明文 UDP，会被劫持 # - 114.114.114.114 ← 明文 UDP，可被运营商篡改 ``` DoH 的保护范围： - **防窃听**：ISP 无法看到你查询了什么域名 - **防篡改**：GFW 无法对 DoH 查询进行 DNS 污染（但可以封锁 DoH 服务器的 IP） - **防运营商劫持**：某些运营商会劫持明文 DNS 查询，插入广告或重定向。DoH 完全避免了这个问题 需要注意：DoH 不能替代 TUN 模式。DoH 只加密了 DNS 查询的传输过程，但如果你使用的是系统代理模式，DNS 查询本身仍然不经过代理客户端——操作系统会直接发送 DoH 请求到配置的 DNS 服务器。虽然内容加密了，但 ISP 仍然能看到你在连接某个 DoH 服务器（通过 IP 地址）。 ### 方案四：禁用 IPv6 如果你不需要 IPv6，关闭它是消除 IPv6 DNS 泄漏的最简单方法。 在代理客户端的 DNS 配置中禁用 IPv6： ```yaml dns: ipv6: false ``` 这个配置告诉代理客户端：不处理 AAAA 记录（IPv6 DNS 记录），所有 DNS 查询只返回 A 记录（IPv4）。 你也可以在操作系统层面禁用 IPv6： **Windows：** 1. 打开"网络和 Internet 设置" 2. 点击当前连接的网络适配器 3. 找到"Internet 协议版本 6 (TCP/IPv6)" 4. 取消勾选 **macOS：** 打开终端，执行 `sudo networksetup -setv6off Wi-Fi` 禁用 IPv6 不会影响正常上网——2026 年的绝大多数网站和服务仍然完全支持 IPv4 访问。除非你有明确的 IPv6 需求（比如 BT 下载需要 IPv6 来改善 NAT 穿透，或者你的 ISP 要求使用 IPv6），否则关闭 IPv6 是一个无副作用的安全措施。 ### 方案五：关闭 WebRTC WebRTC 泄漏虽然不是严格意义上的 DNS 泄漏，但它能暴露你的真实 IP，效果同样致命。 **Chrome 浏览器：** 方式一：安装浏览器扩展。搜索并安装 "WebRTC Leak Prevent" 或 "WebRTC Control" 扩展。这些扩展可以控制 WebRTC 的行为，阻止它泄漏你的真实 IP。 方式二：通过 Chrome flags 设置。在地址栏输入 `chrome://flags`，搜索 "WebRTC"，根据可用选项调整设置。不同 Chrome 版本的可用 flags 可能不同。 **Firefox 浏览器：** Firefox 提供了更直接的控制方式： 1. 在地址栏输入 `about:config` 2. 搜索 `media.peerconnection.enabled` 3. 将其值设置为 `false` 这会完全禁用 WebRTC 功能。副作用是：基于 WebRTC 的网页视频通话和语音聊天将无法使用（如部分网页版视频会议工具）。如果你需要这些功能，建议在需要时临时开启，用完后关闭。 **最佳方案：TUN 模式处理 WebRTC。** 如果你已经开启了 TUN 模式，WebRTC 的 STUN 请求也会被代理客户端接管。STUN 服务器看到的是你代理节点的 IP 而非你的真实 IP。在这种情况下，WebRTC 不会造成泄漏，你也不需要手动禁用它。 --- ## 泄漏检测清单 在完成防泄漏配置后，用以下清单逐项检查，确保没有遗漏。 - [ ] **代理模式**：是 TUN 还是系统代理？TUN 更安全。系统代理模式下 DNS 泄漏几乎不可避免。 - [ ] **DNS 增强模式**：是 Fake-IP 还是 Redir-Host？Fake-IP 更安全。Fake-IP 从根本上避免了代理域名的本地 DNS 查询。 - [ ] **DNS 加密**：nameserver 使用 DoH/DoT 还是明文 UDP？DoH/DoT 更安全。明文 DNS 查询可被 ISP 和 GFW 读取和篡改。 - [ ] **IPv6**：是否需要 IPv6？不需要就关闭。IPv6 DNS 查询是容易被忽略的泄漏渠道。 - [ ] **在线检测**：`dnsleaktest.com` 的 Extended test 是否通过？结果中应该只有海外 DNS 服务器。 - [ ] **WebRTC**：WebRTC 是否已关闭或由 TUN 模式处理？可在 `browserleaks.com/webrtc` 检测。 如果以上所有项目都满足安全要求，你的 DNS 泄漏风险已经降到了接近零的水平。 --- ## 常见问题 **Q：DNS 泄漏有什么实际危险？** 你的 ISP——以及通过 ISP 的 GFW——能看到你查询的所有域名。虽然他们看不到你访问的具体内容（因为有 TLS 加密），但"你在查询 google.com / twitter.com"这个信息本身在特定环境下就是敏感的。DNS 查询日志可以完整地还原你的浏览历史：你什么时候访问了什么网站，频率是多少，持续了多长时间。这些元数据的价值有时候比内容本身更高。在极端情况下，持续的敏感域名查询记录可能引起不必要的关注。 **Q：用了 Fake-IP 就不会泄漏了吗？** Fake-IP 大幅降低了泄漏风险，但不能说百分之百消除。如果你使用的是系统代理模式而非 TUN 模式，某些应用程序仍然可能绕过代理客户端的 DNS 拦截，直接向系统 DNS 或硬编码的 DNS 服务器发送查询。**Fake-IP + TUN 才是最安全的组合。** TUN 确保所有流量被代理客户端接管，Fake-IP 确保代理域名从不触发本地真实 DNS 查询。两者缺一不可。 **Q：检测显示有泄漏怎么办？** 按以下优先级排查： 第一步，确认你的代理模式。如果是系统代理，切换到 TUN 模式。这一步解决了绝大多数 DNS 泄漏问题。 第二步，如果已经是 TUN 模式，检查 DNS 配置。确认 `enhanced-mode` 设置为 `fake-ip`，`nameserver` 中只有国内 DoH 服务器（如腾讯 DoH、阿里 DoH），没有明文 DNS，没有海外 DNS。 第三步，检查 IPv6。如果你的网络有 IPv6，确认代理客户端的 DNS 配置中 `ipv6: false`，或者 TUN 模式同时接管了 IPv6。 第四步，检查是否有其他 VPN 或代理软件冲突。同时运行两个 VPN/代理客户端可能导致 DNS 路由混乱。确保只有一个代理客户端在运行。 第五步，检查操作系统的 DNS 设置。某些系统更新可能会重置 DNS 设置，将其改回 ISP 的默认 DNS。确认你的系统 DNS 指向代理客户端的本地监听地址（通常是 `127.0.0.1` 或代理客户端自动设置的地址）。 **Q：手机上也会 DNS 泄漏吗？** iOS 和 Android 上的代理客户端（如 Shadowrocket、Quantumult X、Clash for Android、sing-box）通常通过系统的 VPN 接口工作——这个接口的工作方式类似于桌面端的 TUN 模式，在系统层面接管所有网络流量，包括 DNS 查询。因此，手机上的 DNS 泄漏风险通常比桌面端低。 但也有例外。如果你在手机上使用的是简单的 HTTP 代理模式（而非 VPN 模式），DNS 查询仍然会走本地网络，存在泄漏风险。另外，Android 系统从 9.0 开始引入了"私人 DNS"功能（实际上是 DNS over TLS），如果这个功能配置了和代理客户端冲突的 DNS 服务器，可能导致 DNS 查询走了意料之外的路径。 建议：在手机上确认代理客户端使用的是 VPN 模式（状态栏应该出现 VPN 图标），而不是简单的 HTTP 代理模式。 **Q：DoH 和 Fake-IP 有什么区别？它们解决的是同一个问题吗？** 不是。它们解决的是 DNS 安全的不同层面。 **DoH** 解决的是 DNS 查询的**传输安全**问题。它将 DNS 查询加密，防止中间人（ISP、GFW）读取或篡改查询内容。但 DoH 不改变 DNS 查询发生的位置——查询仍然在本地发起，只是传输过程变成了加密的。 **Fake-IP** 解决的是 DNS 查询的**发生位置**问题。它让需要代理的域名根本不在本地进行真实 DNS 查询——本地只分配一个假 IP 占位，真正的 DNS 查询在远端代理节点完成。 两者互补而非互斥。推荐的配置是：Fake-IP 模式 + DoH 格式的 nameserver。Fake-IP 确保代理域名不在本地解析；DoH 确保直连域名的 DNS 查询（发往国内 DNS）也是加密的，不被运营商劫持或篡改。 **Q：Wireshark 抓包看到有 DNS 查询，但目标地址是 127.0.0.1，这算泄漏吗？** 不算。发往 `127.0.0.1`（本地回环地址）的 DNS 查询是应用程序向代理客户端的本地 DNS 监听端口发送的查询请求。这些查询不会离开你的设备，也不会经过任何外部网络。它们会被代理客户端接收并处理——走 Fake-IP 映射或通过配置的 DNS 服务器进行加密查询。 真正的泄漏是 DNS 查询发往了外部 IP 地址（如你 ISP 的 DNS 服务器地址），而不是本地回环地址。