Birds – Flying beyond the wall

DNS泄漏是什么？检测、区别与修复方法详解

更新于 2026-10-25 · birds.mom

简答：DNS泄漏指设备访问网站时，网页连接走了预期通道，但 DNS 查询却从本地网络、浏览器或其他应用单独发出。它不等于 IP 泄漏，也不代表一定发生了数据内容泄露；应结合实际网络路径、DNS 设置和多次复测判断。

定义：DNS泄漏是指域名解析请求没有按照用户预期的系统、VPN、代理或加密 DNS 路径发送，而是被其他解析器处理。

先看结论：DNS泄漏到底泄漏了什么

访问一个网站时，设备通常先把域名转换成 IP 地址，再建立网页连接。这个转换过程就是 DNS 查询。DNS 解析器可以是运营商提供的服务器、路由器转发器、系统手动设置的服务器，也可以是浏览器或客户端指定的加密 DNS 服务。DNS 的递归解析和缓存机制可参考 RFC 8499 DNS 术语说明。

在代理或 VPN 场景中，典型的 DNS 泄漏路径是：网页连接进入隧道，但域名查询仍发往本地路由器或运营商 DNS。此时，解析服务可能看到你查询过哪些域名；但这不等于它能直接看到 HTTPS 页面正文、账号密码或完整网页内容。HTTPS 仍负责保护浏览器与网站之间的加密连接。

现象是否等于 DNS 泄漏应如何判断
没有使用代理时，系统使用运营商 DNS通常不属于“泄漏”先确认是否存在需要保护或接管的预期路径
代理已连接，但 DNS 查询仍由本地网络处理可能属于 DNS 泄漏检查客户端 DNS 接管、TUN、浏览器 DoH 和 IPv6
检测到多个 DNS 服务器不一定可能是转发、负载均衡、缓存或不同协议共同产生
DNS 返回了错误 IP更接近 DNS 污染或解析异常对照多个解析器和不同网络重复查询

最快判断：先在关闭客户端和开启客户端两种状态下，分别查询同一个随机域名或新生成的测试域名，再记录检测到的解析服务、出口网络和 IPv4/IPv6 状态。一次结果只能说明当前浏览器、当前网络和当前测试路径，不能证明所有应用都没有泄漏。

DNS泄漏、DNS污染、IP泄漏和WebRTC泄漏有什么区别

问题主要暴露或影响常见判断方法
DNS泄漏域名查询交给了非预期解析器对比客户端开启前后的 DNS 出口、抓包或系统配置
DNS污染收到的域名解析结果可能被篡改或返回异常地址使用多个解析器、不同网络和 A/AAAA 记录交叉对比
IP泄漏网站看到的连接出口仍是本地公网地址或非预期地址检查网页连接出口、IPv4、IPv6 和路由路径
WebRTC泄漏浏览器实时通信接口可能暴露局部网络地址或候选地址仅在支持 WebRTC 的浏览器环境中单独测试
DoH或DoT改变 DNS 查询的传输方式，不自动等于代理隧道确认查询是否通过指定加密解析器，以及应用是否绕过系统设置

DNS over HTTPS（DoH）只是把 DNS 消息放入 HTTPS 连接中，并不会改变 DNS 查询和响应的基本逻辑。微软文档说明，DoH 可降低 DNS 查询在传输途中被观察、修改或篡改的风险，但客户端仍然需要正确配置解析器。可查看 Microsoft 关于 DNS over HTTPS 的说明。

因此，“启用了 DoH”只能说明某一条 DNS 查询路径使用了加密传输，不能自动证明其他浏览器、游戏、终端工具、IPv6 请求或客户端内部 DNS 都经过同一条路径。

怎么检测DNS泄漏：先做三次对照再下结论

  1. 准备记录表。记录日期、网络类型、是否开启客户端、浏览器名称、IPv4/IPv6 状态、检测到的 DNS 服务商和出口地区。日期按本页核对日记录为 2026-10-25。
  2. 关闭代理或 VPN 做基线。在普通网络下打开 DNS 检测页面，或使用系统命令查询一个新生成的随机域名。这个结果只代表普通网络的默认解析路径。
  3. 开启客户端后重新测试。不要只刷新原页面；切换连接状态、清理浏览器 DNS 缓存，再使用新的随机域名测试。
  4. 分别检查 IPv4 和 IPv6。有些客户端只接管 IPv4，系统或浏览器仍可能通过 IPv6 发出 DNS 查询。若测试页面分别展示两种协议，应分别记录。
  5. 至少重复三次。更换一次网络或节点、关闭并重新开启客户端、再测试一次。如果只有一次出现不同解析器，先不要直接认定泄漏，可能是缓存、转发或检测页面自身的观察范围造成。

Windows 自带的 nslookup 可显示默认 DNS 服务器，也可指定某个 DNS 服务器进行查询。微软文档列出了默认服务器、指定服务器、A/AAAA 记录和超时等用法，参见 Microsoft nslookup 命令文档。

nslookup example.com nslookup -type=A example.com nslookup -type=AAAA example.com nslookup example.com 1.1.1.1

命令输出中的“Server”或“Address”只能说明这一次查询使用了哪个解析器，不能单独证明网页浏览、其他应用或客户端内部 DNS 的全部路径。若需要更深入确认，可使用抓包工具观察传统 DNS 的 53 端口流量；Wireshark 文档提供了 dns 显示过滤器和 port 53 捕获过滤器说明，见 Wireshark DNS 文档。

为什么在线检测结果不能直接等于“有泄漏”

在线检测页面通常只能观察当前浏览器发起的测试请求。浏览器可能使用自己的安全 DNS，客户端可能接管系统 DNS，路由器可能继续转发请求，应用也可能内置独立解析器。因此，浏览器显示的结果不一定代表所有应用的结果。

  • 缓存影响：域名已经解析过时，浏览器、系统或路由器可能直接使用缓存，不会马上发出新查询。
  • DoH影响：Firefox 的 DoH 设置可以让浏览器通过 HTTPS 向指定解析器发送查询，也可能因网络策略、企业管理、VPN 或连接失败而回退到系统解析器。具体保护级别可查看 Firefox DNS over HTTPS 配置说明。
  • 转发影响：检测页面看到的可能是最终递归解析器，也可能是运营商、路由器或本地服务的转发结果。
  • 多解析器影响：负载均衡、备用解析器、IPv4/IPv6 双栈和不同应用的并行查询，都可能让结果看起来不止一个。
  • 测试范围影响：一次浏览器测试无法覆盖游戏、办公软件、命令行工具、手机应用以及客户端自己的 DNS 模块。

所以，看到多个 DNS 地址不应直接当作泄漏；更可靠的判断是：你是否明确要求某个客户端或隧道接管 DNS，而测试结果是否持续显示查询仍从预期之外的网络发出。

按设备修复DNS泄漏：最短操作路径

Windows 10/11

  1. 确认系统 DNS。打开命令提示符运行 nslookup，记录默认 Server 和 Address；再用 ipconfig /all 查看当前网卡的 DNS 服务器。
  2. 检查客户端接管方式。如果使用客户端的 TUN 或全局接管模式，确认 DNS 接管开关已启用，并避免浏览器 DoH、IPv6 或其他应用绕过客户端。
  3. 验证。清理 DNS 缓存后关闭并重新开启客户端，再运行 nslookup 和在线检测。若修改 Windows 的 DNS over HTTPS，可参考微软关于 Windows 11 DNS 加密的说明，不要把服务器端 DoH 配置误当成普通客户端设置。

Windows 的 DNS 客户端支持 DoH 和 DoT，但具体可用选项会受系统版本、策略和网络环境影响。不要只更换一个公共 DNS 就认为泄漏已经修复。

macOS

  1. 打开“系统设置”→“网络”→选择当前 Wi-Fi 或有线网络→“详细信息”。
  2. 检查 DNS 服务器、代理、IPv6 和客户端网络扩展是否与预期一致；如果客户端提供 DNS 接管或 TUN，确认其状态为已启用。
  3. 切换网络或关闭再开启客户端后复测，分别记录浏览器与系统命令的结果。

macOS 的图形界面名称可能随版本变化。修改前建议记录原 DNS 和代理参数，避免排障后无法恢复。

Android

  1. 打开“设置”→“网络和互联网”→“私人 DNS”；部分厂商会把它放在连接或更多连接设置中。
  2. 在“自动”和“私人 DNS 提供商主机名”之间选择与当前客户端方案不冲突的设置。Google 的说明提醒，私人 DNS 只保护 DNS 问答，不会保护其他网络流量，见 Google Android 私人 DNS 设置说明。
  3. 开启客户端后，重新打开浏览器或应用，再分别测试 IPv4、IPv6 和 DNS 出口。若客户端使用 TUN，确认私人 DNS 没有绕开客户端。

iPhone

  1. 打开“设置”→“无线局域网”，点击当前网络右侧的信息按钮。
  2. 检查 DNS、HTTP 代理和“限制 IP 地址跟踪”等选项。Apple 的 Wi-Fi 设置文档说明，连接到网络后可以在该页面配置 DNS 和 HTTP 代理，见 Apple iPhone Wi-Fi 设置说明。
  3. 重新连接网络，关闭并开启客户端，再用新测试域名复测。若启用了 iCloud Private Relay，也要把它作为独立的网络路径记录，不要与普通 DNS 接管混为一谈。

客户端和浏览器场景：重点检查谁在发DNS请求

排查客户端时，不要只看“已连接”或网页能否打开。应分别确认三个状态：导入或配置是否成功、DNS 接管是否开启、测试请求是否确实经过预期路径。

  • 系统代理模式：通常只影响遵守系统代理的应用，命令行工具、游戏、部分浏览器和后台服务可能不使用它。
  • TUN模式：通常可以接管更多系统流量，但仍需检查 IPv6、应用自带 DNS 和排除规则。
  • 浏览器 DoH：浏览器可能绕过系统 DNS，Firefox 允许用户调整 DoH 保护级别；开启或关闭后应重新测试，而不是沿用旧结果。
  • 客户端日志：优先查看 DNS、TUN、路由、连接和错误日志，关注“query”“resolver”“fallback”“timeout”“IPv6”等字段。日志只能说明客户端自身观察到的状态，仍需结合外部复测。

如果使用 Clash 或 Mihomo 一类客户端，重点核对 DNS 是否接管、是否启用 fake-ip 或 redir-host、是否存在 fallback、直连规则和 IPv6 例外。具体字段和菜单会因版本、内核及配置文件不同而变化；未看到对应选项时，不要照抄其他版本的配置。

复测模板：

日期：2026-10-25 网络：Wi-Fi / 移动数据 / 有线 客户端：关闭 / 开启 模式：系统代理 / TUN / 其他 浏览器： IPv4： IPv6： DNS检测结果： nslookup默认Server： 是否清理缓存： 是否更换网络后复测： 结论：未发现持续异常 / 需要继续排查

修复后如何判断是否真的改善

  1. 先恢复一个可控的基线：关闭客户端，在同一网络下测试一次。
  2. 开启客户端并保持同一浏览器、同一设备，再测试一次。
  3. 切换一次网络，例如从 Wi-Fi 换到移动数据，排除路由器转发造成的干扰。
  4. 换一个浏览器或命令行工具，判断是否只有单一应用绕过了系统设置。
  5. 分别检查 A 和 AAAA 查询，避免只验证 IPv4 而遗漏 IPv6。
  6. 如果仍有异常，查看客户端日志和抓包；仅凭某个在线页面显示多个解析器，不足以下结论。

合格的排查结论应写清楚范围，例如“在 2026-10-25、某 Wi-Fi、某浏览器和某客户端配置下，连续三次测试未观察到预期之外的 DNS 出口”。不要把一次测试扩大成“所有设备、所有应用都没有泄漏”的保证。

涉及跨境办公或多设备连接时，应同时遵守所在地法律与服务条款。多网络、多设备对照后仅目标服务异常时，可考虑已公开主体信息的服务。

常见问题

没有使用代理时看到运营商DNS，算DNS泄漏吗？

通常不能直接这样判断。DNS泄漏的前提是存在一条预期路径，例如客户端、VPN或企业网络要求 DNS 通过指定通道处理。普通网络默认使用运营商或路由器 DNS，本身不自动等于泄漏。

检测到多个DNS服务器是不是一定有问题？

不一定。多个结果可能来自转发、备用解析器、负载均衡、IPv4与IPv6双栈、浏览器DoH或不同应用并行查询。应比较开启前后、不同网络和多次复测结果。

DNS泄漏会让别人看到我访问的完整网页吗？

DNS查询通常暴露的是域名解析请求，不等于完整网页内容。HTTPS会继续保护浏览器与网站之间的加密传输，但域名层面的信息仍可能被查询路径上的解析服务观察到。

把DNS改成公共DNS就能修复泄漏吗？

不能保证。手动更换 DNS 只改变解析器地址，未必改变请求是否绕过客户端、是否通过 IPv6 发出，浏览器或应用也可能使用自己的 DoH或内置解析器。

为什么浏览器检测正常，但某个应用仍然连接异常？

浏览器和应用可能使用不同的 DNS 路径。应用可能不遵守系统代理、使用内置解析器、只走 IPv4或IPv6，或者被客户端规则设置为直连。应查看应用和客户端日志，并分别测试。

开启DoH后是不是就不会发生DNS泄漏？

DoH能加密某条 DNS 传输路径，但不自动接管所有应用，也不等于网页流量经过同一条隧道。还要确认浏览器、系统、客户端、IPv4和IPv6是否使用一致的预期路径。

清理DNS缓存后还需要重新测试吗？

需要。缓存可能让设备暂时不发起新的查询。修改设置后建议清理浏览器和系统缓存，关闭并重新开启客户端，再用新的随机域名至少复测三次。

相关阅读

参考资料

  1. RFC 8499：DNS术语
  2. Microsoft：DNS over HTTPS 加密说明
  3. Microsoft：nslookup 命令文档
  4. Wireshark：DNS过滤与抓包说明
  5. Mozilla：Firefox DNS over HTTPS 说明
  6. Google：Android 私人 DNS 设置说明
  7. Apple：iPhone Wi-Fi、DNS和代理设置说明