DNS 泄漏是什么？30 秒在线检测与按设备排查

更新于 2026-10-23 · allzezecloud.xyz

简答：DNS 泄漏是域名查询绕过预期的代理、VPN 或加密 DNS，交给其他解析器处理。先连接当前客户端，打开 dnsleak.dev 运行测试，查看实际响应者；再按 IPv6、浏览器 DoH、系统 DNS 和 TUN 设置逐项复测。

定义：DNS 泄漏指域名解析请求没有按预期经过指定的代理、VPN 或 DNS 通道，而是被系统、路由器、浏览器或其他网络接口送往非预期解析器。

先做 30 秒检测：看实际谁在回答 DNS

先连接你正在使用的代理、VPN 或网络客户端，保持当前网络状态不变，然后打开 dnsleak.dev DNS Leak Test，点击测试按钮。该页面会让浏览器解析测试用主机名，再从另一端记录实际响应的解析器；页面说明可以显示解析器的网络归属和城市，并支持更深度的重复查询。测试结果最多保留十分钟，具体以检测页面说明为准。

1. 连接代理、VPN 或客户端，不要先修改 DNS。
2. 打开 dnsleak.dev，运行基础测试。
3. 查看结果中的解析器名称、网络归属、地址以及 IPv4、IPv6 和 WebRTC 项目。
4. 如果结果会变化，运行页面提供的深度测试，观察是否出现只在部分查询中出现的解析器。
5. 记录结果后，再按设备和客户端设置逐项修改，每次只改一个变量，最后重新测试。

dnsleak.dev、ip.cx 等都属于第三方检测工具，页面功能和结果以实际页面为准。一次测试只能说明当前浏览器、当前网络和当前时间段的结果，不能证明所有应用在所有时间都绝对不会绕行。

DNS 泄漏会暴露什么？先和其他问题分开

DNS 的作用是把域名转换为 IP 地址。发生 DNS 泄漏时，非预期解析器可能看到设备查询过的域名以及查询时间和频率，但这不等于对方能够直接看到网页正文、账号密码或全部页面内容。ipconfig.io 的 DNS 泄漏说明也将“域名查询绕过预期通道”作为判断重点。

DNS 服务器所在国家、城市与出口 IP 不一致，并不自动代表泄漏。更可靠的判断方式是：该解析器是否属于你预期使用的代理、VPN、企业网络、路由器或浏览器 DoH 服务；如果归属完全不认识，再结合 IPv4、IPv6 和客户端日志继续排查。

Clash 或 Mihomo TUN/fake-ip 结果怎么看

如果你使用基于 Mihomo 的客户端，不能只凭系统设置或 nslookup 的一次结果判断是否泄漏。当前 Meta-Docs DNS 配置文档列出 dns.enable、enhanced-mode、fake-ip-range 等字段；enhanced-mode 可选 fake-ip 或 redir-host，不同客户端内置核心和版本的默认行为可能不同，应以所用核心版本文档为准。

Meta-Docs 的 TUN 文档说明，dns-hijack 会把匹配的 DNS 连接转入内部 DNS 模块；TUN 的 DNS 模式、严格路由和系统平台会影响实际接管范围。Windows、macOS、Android 对局域网 DNS 或私人 DNS 的处理并不完全相同，因此应以检测结果和客户端日志共同判断。

可先检查下面这组配置是否确实由当前客户端使用，字段名和可用值以客户端内核版本为准：

dns:
enable: true
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
tun:
enable: true
dns-hijack:
- any:53
auto-route: true

这不是适用于所有客户端的完整配置，也没有写死 stack。不要把示例直接覆盖到现有配置；先备份，再根据客户端文档确认字段是否支持。修改后应重新连接并再次运行在线测试。

Windows、macOS、Linux：配置检查与命令行核对

Windows

打开命令提示符，执行：

ipconfig /all

该命令会显示所有网络适配器的 TCP/IP 配置。根据 Microsoft Learn 的 ipconfig 文档，应逐个查看适配器下的 DNS Servers，特别注意 Wi-Fi、网线、虚拟网卡、TUN 网卡和 IPv6，而不是只看当前认为正在使用的网卡。

可以再执行：

nslookup example.com

example.com 是示例域名，请替换为要检查的域名。查看输出中的 Server 和 Address，它们表示本次 nslookup 使用的 DNS 服务器。需要注意，nslookup 不是 Windows DNS Client 全部实际解析路径的等价观察器；在 TUN、fake-ip、浏览器 DoH 或应用自带 DNS 场景下，结果可能不能代表所有流量。改完 DNS 后可按需执行：

ipconfig /flushdns

判定标准是：命令显示的配置与客户端预期一致，但最终仍应以连接状态下的在线检测结果为准。Windows DNS 客户端排查可参考 Microsoft Learn：DNS 客户端排查。

macOS

打开“终端”，执行：

scutil --dns | grep nameserver

这条写法不会把 [0] 当作正则字符组，能够匹配类似 nameserver[0] : x.x.x.x 的输出。也可以直接执行：

scutil --dns

图形界面可进入“系统设置→网络→当前网络→详细信息→DNS”。Apple 的操作路径见 Apple 支持：在 Mac 上更改 DNS 设置。这里显示的是系统报告的解析器配置，不一定等于浏览器、应用或 TUN 内部实际使用的上游，因此仍需在线复测。

Linux

优先执行：

resolvectl status

若只想查看 DNS Servers，可执行：

resolvectl status | grep -A2 'DNS Servers'

如果系统没有 resolvectl，再查看：

cat /etc/resolv.conf

在使用 systemd-resolved 的系统中，/etc/resolv.conf 常见的是 127.0.0.53 本地存根地址，它不是最终上游 DNS。看到这个地址不能直接判定泄漏，也不能说明上游解析器是谁；应继续查看 resolvectl status，并用在线检测或实际查询复核。

浏览器、Android、iPhone：检查独立 DNS 路径

Chrome 与 Edge

Chrome 的路径通常是“设置→隐私和安全→安全→使用安全 DNS”。Google 说明，Chrome 可以使用当前服务提供商或自定义服务提供商；自动模式遇到问题时可能回退到未加密解析，具体以浏览器当前设置为准。参考 Google Chrome 帮助：管理安全性。

Edge 的路径是“设置→隐私、搜索和服务→安全→使用安全 DNS”。微软说明该功能用于加密 DNS 查询，设置路径见 Microsoft Support：在 Edge 中安全浏览 Web。如果你希望由 TUN 客户端统一接管 DNS，应先确认浏览器没有单独指定一个绕过客户端的服务商；如果浏览器必须使用 DoH，则应把该服务商视为预期解析器的一部分。

Firefox

Firefox 的 DNS over HTTPS 设置位于“设置→隐私与安全→DNS over HTTPS”。Mozilla 的说明见 Firefox 中配置基于 HTTPS 的 DNS 保护级别。修改后关闭并重新打开浏览器，再运行检测，避免旧连接或缓存影响判断。

Android

在 Android 手机上进入“设置→网络和互联网→私人 DNS”；部分系统可以直接在设置中搜索“私人 DNS”。Google 的 Pixel 文档列出“关闭、自动、私人 DNS 提供商主机名”三种选项，并明确说明私人 DNS 只保护 DNS 问答，不会保护其他流量。参考 Google Pixel 帮助：私人 DNS。

如果同时使用 Android 客户端或 TUN，请记录私人 DNS 当前状态，再分别测试“客户端开启”和“客户端关闭”的结果。若 Android 私人 DNS 与客户端 DNS 接管同时存在，结果可能与预期不同；不要仅凭设置页面推断实际上游。

iPhone

连接 Wi-Fi 后进入“设置→无线局域网→当前网络右侧的信息按钮→配置 DNS”，可以查看或修改该 Wi-Fi 的 DNS。Apple 的官方路径见 Apple 支持：在 iPhone 上管理无线局域网设置。如果设备安装了 DNS、VPN 或网络管理描述文件，还要检查对应配置；移动数据网络下的 DNS 路径可能与 Wi-Fi 不同，应分别测试。

发现疑似泄漏后的修复顺序

1. 先确认检测不是误读。记录解析器名称、网络归属和测试时间；位置不同不等于泄漏，先确认是否属于预期服务。
2. 检查客户端是否真正接管 DNS。在 Mihomo 类客户端中核对 dns.enable、enhanced-mode、TUN 是否启用，以及 dns-hijack、路由和严格路由设置。字段支持和默认值以当前核心文档为准。
3. 检查浏览器 DoH。如果 Chrome、Edge 或 Firefox 单独使用安全 DNS，它可能与系统或客户端显示不同的解析器。按实际需求关闭独立 DoH，或把它明确纳入预期路径。
4. 单独验证 IPv6。在检测结果中查看 IPv6 项目。若客户端只接管 IPv4，IPv6 可能从物理网卡走出；可暂时关闭 IPv6 做一次单变量对比，确认结果是否变化。
5. 检查路由器、多网卡和虚拟网卡。分别测试 Wi-Fi、网线、移动热点、虚拟机和公司网络。路由器强制 DNS、容器、虚拟网卡和安全软件都可能改变解析路径。
6. 最后启用客户端的阻断功能。如果客户端提供 DNS 泄漏阻断或 Kill Switch，按该客户端文档开启。断开客户端后确认网络是否按预期停止，而不是静默回落到本地 DNS。
7. 修改后重新测试。断开并重新连接客户端，清理必要的本地缓存，再运行基础测试和深度测试。只有在结果与预期解析器归属一致时，才能说明当前测试路径未发现明显 DNS 绕行。

如果问题只在 macOS、Android、IPv6 或某个浏览器出现，不要一次替换整份配置。保留原配置，逐项改变一个变量，记录每次测试结果，才能定位真正的绕行来源。

继续排查客户端连接问题

如果你是在客户端连接后发现 DNS 结果异常，可以继续查看本站已整理的连接排查与日志页面。本站与 ZeZe 项目及其开发者无隶属关系，页面仅提供通用使用指南。

• 连接问题排查：先区分 DNS、代理、路由和客户端配置问题。
• Windows 上的 Clash 代理与 TUN 设置：核对 Windows 下的系统代理和接管路径。
• Clash 报错日志排查：适合已经出现启动、规则或连接错误的情况。

常见问题

DNS 服务器显示在其他国家，是不是一定泄漏？

不一定。国家或城市只能作为辅助信息，关键是解析器是否属于你预期使用的代理、VPN、企业网络、路由器或 DoH 服务。应结合名称、网络归属、IPv4/IPv6 结果和客户端设置判断。

IP 已经切换了，为什么还要检测 DNS？

IP 泄漏和 DNS 泄漏是两条不同路径。网站看到的出口 IP 已改变，只能说明 IP 层可能正常；域名查询仍可能由本地运营商、路由器或浏览器独立发出，所以需要单独运行 DNS 检测。

Mihomo fake-ip 下 nslookup 返回 198.18.x.x，是不是故障？

通常不应单独判定为故障。Meta-Docs 将 198.18.0.1/16 列为 fake-ip 地址范围示例；在 fake-ip 模式下出现该范围可能是正常映射。还要查看实际检测页中的解析器归属和客户端日志。

检测结果里有多个 DNS 服务器怎么办？

先不要直接判定为泄漏。多个结果可能来自 IPv4 与 IPv6、多网卡、重复查询、间歇性绕行或浏览器独立 DoH。重复测试，并一次只关闭 IPv6、浏览器 DoH 或虚拟网卡中的一个变量。

Linux 的 /etc/resolv.conf 显示 127.0.0.53，说明 DNS 泄漏了吗？

不能这样判断。systemd-resolved 系统常用 127.0.0.53 作为本地存根，真正的上游解析器应通过 resolvectl status 查看；最终仍要结合在线检测结果判断。

开启 Android 私人 DNS 后，还需要检测吗？

需要。私人 DNS 只说明系统设置了一个 DNS 保护路径，不代表所有应用、客户端 TUN、IPv6 或浏览器 DoH 都会使用同一路径。连接客户端后仍应运行在线测试并对比结果。

相关阅读

• 连接问题排查
• Windows 上的 Clash 代理与 TUN 设置
• Clash 报错日志排查

参考资料

1. DNS Leak：识别实际响应 DNS 查询的解析器（dnsleak.dev）
2. What is a DNS leak, and how do you check for one?（docs.ipconfig.io）
3. Meta-Docs：DNS 配置字段与 enhanced-mode 说明
4. Meta-Docs：TUN、dns-hijack 与严格路由说明
5. Microsoft Learn：ipconfig 命令
6. Microsoft Learn：DNS 客户端排查
7. Apple 支持：在 iPhone 上管理无线局域网设置
8. Google Chrome 帮助：管理 Chrome 的安全性与安全 DNS
9. Microsoft Support：在 Edge 中安全浏览 Web
10. Google Pixel 帮助：控制私人 DNS 和其他网络设置