贤者云 | xianzhey.shop

Clash Verge Rev DNS 泄漏怎么排查？按 TUN、浏览器与日志定位

更新于 2026-11-09 · xianzhey.shop

简答：先不要批量修改 DNS：关闭 TUN、保留普通代理，记录同一域名在浏览器和系统命令中的结果；再分别开启 TUN、检查浏览器 DoH，并查看 Runtime Config 与日志。检测站显示本地 DNS 只能证明测试页面当时观察到某个解析器，不能单独证明所有应用都发生了 DNS 泄漏。本文适用于 Windows、macOS 和 Linux 上使用 Clash Verge Rev 与 Mihomo 内核的排查，菜单名称和字段以当前版本为准。

定义：Clash Verge Rev DNS 泄漏，是指域名解析请求没有按预期进入 Mihomo 或客户端的 DNS 处理链路，而是由系统、浏览器、IPv6、虚拟网卡或其他网络组件发送给未预期的解析器。

先试这一步：5 分钟 DNS 泄漏判断卡

本文是 xianzhey.shop 的第三方使用指南，不是相关客户端的官方页面。排查前记录操作系统、Clash Verge Rev 版本、Mihomo 内核版本、当前配置、TUN 状态、系统代理状态、浏览器 DoH 状态和准确报错；无法从当前界面确认的版本写“未核实”。

现象先查层级记录什么看到什么算异常下一步与回滚
检测站显示本地或未预期 DNS浏览器 DoH、系统代理、TUN检测时间、浏览器、DoH 模式、TUN 状态关闭浏览器独立 DNS 后结果仍持续出现，且其他应用也复现先比较普通代理与 TUN；不要马上改所有 DNS，回滚为关闭 TUN 或恢复浏览器原设置
TUN 开启后全部断网DNS Hijack、Strict Route、路由和 DNS ModeRuntime Config、日志中的启动或解析错误关闭 TUN 后网络立即恢复关闭 TUN，保存配置，再一次只改一个字段
只有浏览器检测异常浏览器 Secure DNS/DoH、扩展、独立代理浏览器 DNS 设置和其他应用结果其他应用正常，只有一个浏览器变化临时关闭浏览器独立 DNS，重启浏览器后复测
Fake-IP 导致内网或局域网异常dns.enhanced-mode、fake-ip-filterFake-IP 模式、内网域名和地址范围公网访问正常，内网域名或局域网设备异常只为必要域名增加过滤规则，保留原配置备份
节点域名无法解析或无法启动proxy-server-nameserver节点域名、解析错误、启动日志普通网站可解析，但节点域名解析失败检查节点专用解析链路，不要只修改普通 nameserver
  1. 关闭 TUN，只保留普通代理或系统代理，访问一个公开网页。
  2. 在同一网络、同一节点、同一浏览器中进行一次 DNS 检测，记录检测站显示的解析器。
  3. 关闭浏览器独立 DoH 或 Secure DNS，完全退出并重新打开浏览器后重复检测。
  4. 开启 TUN，保持节点、浏览器、测试域名和网络不变，再重复检测。
  5. 查看 Runtime Config 和运行日志；如果日志出现 DNS 超时、无法连接解析服务器或 TUN 启动失败，先停止修改并回滚。

五分钟流程的停止条件是：已经确认异常只发生在一个浏览器、只发生在 TUN、只发生在某个域名，或只发生在检测站。此时不要继续批量替换 DNS，应转到对应层级排查。

先分清 DNS 泄漏、DNS 污染、Fake-IP 和 WebRTC

DNS 泄漏

重点是“查询请求发给了谁”。如果应用或系统把域名查询直接交给路由器、运营商或浏览器自定义 DoH，而不是进入预期的客户端 DNS 链路，才有必要继续判断是否属于泄漏。

DNS 污染或错误解析

重点是“返回了什么结果”。解析超时、返回错误地址或不同网络下结果不一致，不一定说明请求绕过了客户端，也可能是解析策略、缓存、IPv6 或目标 DNS 服务的问题。

Fake-IP

Mihomo 的 dns.enhanced-mode 可使用 fake-ip 或 redir-host。Fake-IP 地址属于 DNS 处理模式的结果，本身不等于 DNS 泄漏；应结合 fake-ip-range、fake-ip-filter 和实际连接日志判断。Mihomo DNS 配置文档

WebRTC 泄漏

WebRTC 关注浏览器连接协商时暴露的地址，与 DNS 查询路径不是同一问题。发现 WebRTC 地址异常时，应单独检查浏览器权限、扩展、IPv6 和网络接口，不要只修改 DNS。

日志怎么打开、看什么、如何判断

标题中的“日志定位”不是让你凭关键词猜原因，而是把一次复现和对应日志时间对齐。Clash Verge Rev 的代码提供运行配置、运行日志、日志目录、DNS 覆写校验和诊断信息等接口；具体入口名称可能随版本变化，优先使用当前界面中的“运行日志”“日志目录”“诊断信息”或同义入口。Clash Verge Rev 运行配置与日志接口

  1. 先关闭日志面板中的无关筛选，记录当前时间到分钟。
  2. 只复现一次：访问一个公开域名，或执行一次系统 DNS 查询，不要同时刷新多个网站。
  3. 按 dns、resolve、timeout、hijack、tun、route、connection 和 error 等词筛选；不同版本的具体日志文本可能不同。
  4. 将日志与现象对应：出现解析超时，优先查 DNS 服务器可达性；出现 TUN 启动失败或路由错误，优先查 TUN、权限和路由；出现节点域名解析失败，优先查 proxy-server-nameserver；只有浏览器检测变化而日志无对应 DNS 请求时，优先查浏览器 DoH。
  5. 如果日志显示请求已进入客户端，但检测站仍显示另一个解析器，不要立即断言全局泄漏；还要检查该浏览器是否使用独立 DoH、IPv6 或其他网络组件。

Mihomo API 文档说明，/logs 可读取实时日志，并可按 info、warning、error、debug 级别筛选；/configs 可读取当前运行配置，包含 tun 等字段。若当前客户端提供本地控制面板，可使用其运行日志和运行配置入口，不要把未核实的控制端口直接暴露到局域网。Mihomo API 文档

日志或现象更可能的层级验证动作不要做什么
DNS 查询超时解析服务器、网络或规则对比普通代理、指定 DNS 和客户端日志不要同时更换节点、DNS 和规则
TUN 启动失败权限、路由、虚拟网卡或字段不兼容关闭 TUN，确认普通代理恢复后查看启动日志不要为了验证关闭证书校验
节点域名解析失败proxy-server-nameserver 或节点域名本身单独查询节点域名并检查运行配置不要只改网站解析用的 nameserver
浏览器检测异常但其他应用正常浏览器 DoH、扩展或独立代理关闭浏览器独立 DNS 后完全重启浏览器不要直接重写整个订阅 DNS

订阅、DNS 覆写、扩展配置与 Runtime Config 的实际关系

“排查顺序”不等于“配置优先级”。可以把配置链路理解为：订阅原文先提供基础配置；扩展配置或扩展脚本再按规则覆盖或合并；DNS 覆写在扩展之前处理；设置页保存的应用设置位于链路末端；Runtime Config 是最终运行结果，排查时应以它为准，而不是只看订阅原文。Clash Verge Rev 扩展配置与脚本说明

  • 订阅原文：远程或本地配置的基础来源，更新后可能变化。
  • 扩展配置：用于覆盖或合并配置；列表和普通值通常整体替换，嵌套对象通常按子字段合并。
  • DNS 字段的特殊规则：扩展配置中写出的 dns 字段和顶层 hosts 具有整体替换特征；例如只写新的 nameserver-policy，可能替换此前同名表，而不是逐条追加。
  • DNS 覆写：只有开启且页面填写了对应值时，才会替换订阅中的相应 DNS 字段；如果订阅自带 DNS 策略，应用可能自动关闭该覆写，具体以当前界面提示为准。
  • 设置页：官方扩展说明指出，应用设置优先级高于订阅原文、扩展配置和扩展脚本；TUN 的部分字段以及部分顶层字段由应用接管。
  • Runtime Config：是合并和应用设置之后的最终运行结果。它能回答“现在实际生效了什么”，但不能单独说明每个字段来自哪个文件。

实际排查时按“订阅原文→扩展配置→DNS 覆写→设置页→Runtime Config”逐层记录差异；实际修复时不要同时改五层。每次只修改一个来源，并在 Runtime Config 中确认变化。

TUN 模式：核对 DNS Hijack、Strict Route 和 DNS Mode

TUN、Fake-IP 和 DNS Hijack 不是同一个设置：dns.enhanced-mode决定 Mihomo 的 DNS 处理模式；tun.dns-hijack属于 TUN 接管链路；strict-route和 auto-route影响路由接管。Mihomo 文档分别列出了这些字段，不能仅凭“VPN 图标出现”判断所有 DNS 已被接管。Mihomo TUN 配置文档 Mihomo DNS 配置文档

  1. 关闭 TUN，确认普通代理或系统代理能访问目标网页。
  2. 开启 TUN，但暂时不同时启用新的 DNS 覆写、IPv6 或复杂规则。
  3. 在 Runtime Config 中核对 tun.enable、auto-route、strict-route、dns-hijack、dns-mode 和 dns.enable 是否真的生效。
  4. 如果 TUN 一开就断网，立即关闭 TUN，保存启动日志，再检查权限、虚拟网卡、路由和 DNS 启动错误。
  5. 如果只有本地网络或内网域名异常，优先检查 Fake-IP 过滤和本地 DNS 策略，不要把所有域名改成直连。

某些字段是否可用、字段组合是否需要额外条件，取决于当前客户端和内核版本；页面中未显示的字段不要自行添加。

Windows、macOS、Linux 的可执行验证步骤

Windows：nslookup、系统代理与网络接口

打开 PowerShell 或命令提示符。先查询当前系统默认 DNS，再指定一个公开 DNS 做对照：

nslookup example.com

nslookup example.com 1.1.1.1

nslookup -type=AAAA example.com

预期输出是得到查询结果和服务器信息；它只能说明本次命令使用或访问到的解析器，不能证明所有应用都走同一路径。需要查看网络接口和 DNS 状态时，可执行：

ipconfig /all

ipconfig /flushdns

ipconfig /all用于记录各接口 DNS，ipconfig /flushdns会清理系统 DNS 缓存；执行后应重新进行同一测试。系统代理、TUN 和浏览器 DoH 要分别检查，不要把系统代理开启等同于 TUN 已接管。Microsoft Learn：nslookup

macOS：网络设置、scutil 与 dig

图形界面可从“系统设置→网络→当前网络服务→详细信息→DNS”查看或调整 DNS；Apple 的用户指南说明可在网络服务的 DNS 设置中管理 DNS 服务器，具体名称会随 macOS 版本变化。Apple：在 Mac 上更改 DNS 设置

终端中先查看系统解析状态：

scutil --dns

再执行公开域名的对照查询：

dig example.com

dig @1.1.1.1 example.com

dig AAAA example.com

如果关闭 TUN 后 scutil --dns显示的解析服务恢复，而开启 TUN 后网页或应用异常，应把 TUN 接管、系统 DNS 服务和浏览器 DoH 放在同一条复现记录中，不要只修改 DNS 地址。

Linux：resolvectl、NetworkManager 与路由

优先确认系统是否使用 systemd-resolved：

resolvectl status

查询公开域名并指定接口时，可使用：

resolvectl query example.com

如果系统使用 NetworkManager，可查看连接和 DNS：

nmcli device show

nmcli connection show

需要清理 systemd-resolved 缓存时，先确认该服务正在运行，再执行：

sudo resolvectl flush-caches

命令需要管理员权限，且不同发行版可能使用 NetworkManager、systemd-resolved 或其他 DNS 管理服务；如果没有 resolvectl，不要强行套用该命令，应先确认本机 DNS 管理方式。resolvectl 手册

浏览器 Secure DNS、IPv6 和其他网络组件

浏览器可能绕过系统解析器。Chrome、Edge 和 Firefox 的 Secure DNS 或 DoH 设置名称、默认行为和可用模式会随版本变化，因此只把官方帮助页作为设置方向，实际以当前浏览器页面为准。Google Chrome 安全与隐私设置 Microsoft Edge 安全 DNS说明 Firefox DNS over HTTPS说明

  1. 记录浏览器名称和当前 Secure DNS/DoH 模式。
  2. 临时关闭浏览器独立 DNS，完全退出浏览器后重新打开。
  3. 保持节点、网络和测试域名不变，重复检测。
  4. 如果只有浏览器结果变化，优先处理浏览器解析路径。
  5. 检查浏览器扩展、企业代理、其他 VPN、虚拟机网卡、IPv6 和安全软件是否接管网络。

检测站只观察测试页面触发的查询，不能覆盖其他应用、后台服务、IPv6 请求或浏览器独立 DoH 的全部流量。更可靠的判断需要把检测结果、系统命令、Runtime Config、日志和目标应用访问结果放在同一组测试条件下对照。

安全回滚与最小复现记录

每次修改前导出或备份当前配置，记录修改来源、字段、时间和回滚动作。出现断网时按以下顺序恢复：

  1. 关闭 TUN。
  2. 恢复系统代理原状态。
  3. 撤销最近一次 DNS 覆写或扩展配置修改。
  4. 清理对应系统或客户端 DNS 缓存。
  5. 重启客户端内核后重新读取 Runtime Config。

复现记录至少包括操作系统、客户端和内核版本、配置名称、普通代理与 TUN 状态、浏览器 DoH 状态、IPv6 状态、网络接口、测试域名、准确报错、发生时间和脱敏日志。订阅链接、令牌、私钥、用户名、内部域名和办公网络地址不要公开，也不要把企业内网域名提交到公共 DNS 检测站。不要为了验证 DNS 泄漏而关闭 TLS 证书校验。

如果只在一个检测站出现异常，换一个公开测试域名并重复同一组对照；如果普通代理正常、TUN 异常，则优先排查 TUN 接管；如果只有浏览器异常，则优先排查浏览器 DoH；如果节点域名异常，则优先排查节点专用解析链路。

常见问题

DNS 检测站显示本地 DNS，就一定是 Clash Verge Rev 泄漏吗？

不一定。检测站只能说明测试页面当时观察到某个解析器，可能受浏览器 Secure DNS、系统解析器、IPv6、TUN 接管范围或其他网络组件影响。应在同一网络和节点下关闭浏览器独立 DNS，并分别比较普通代理与 TUN，再结合 Runtime Config 和日志判断。

Fake-IP 地址是不是 DNS 泄漏？

不是。Fake-IP 是 Mihomo 的 DNS 增强模式之一，应用看到 Fake-IP 网段地址可能是该模式的正常结果。应查看 <code>dns.enhanced-mode</code>、<code>fake-ip-range</code> 和 <code>fake-ip-filter</code>，不能仅凭返回地址判断泄漏。

Clash Verge Rev 的日志应该看哪些关键词？

先按复现时间查看 <code>dns</code>、<code>resolve</code>、<code>timeout</code>、<code>hijack</code>、<code>tun</code>、<code>route</code>、<code>connection</code> 和 <code>error</code>。解析超时优先查 DNS 可达性，TUN 启动失败优先查权限和路由，节点域名失败优先查 <code>proxy-server-nameserver</code>。不同版本的具体日志文本可能不同。

TUN 开启后断网，应该先改哪个 DNS？

先不要批量修改 DNS。关闭 TUN确认普通代理能否恢复，再检查 Runtime Config 中的 <code>dns-hijack</code>、<code>strict-route</code>、<code>dns-mode</code>、<code>dns.enable</code> 和系统 DNS 状态；每次只改一个变量，并保留回滚方式。

订阅里的 DNS 和 DNS 覆写哪个优先？

不能只看订阅原文。当前官方扩展说明显示，订阅原文是基础来源，扩展配置会按规则覆盖或合并，DNS 覆写在扩展之前处理，设置页保存的应用设置优先级更高，Runtime Config 才是最终运行结果。具体字段还可能受当前版本和订阅策略影响。

macOS 和 Linux 怎样确认系统实际使用的 DNS？

macOS 可在“系统设置→网络→当前网络服务→详细信息→DNS”查看，并用 <code>scutil --dns</code>和 <code>dig</code>做命令行对照。Linux 可先运行 <code>resolvectl status</code>，再用 <code>resolvectl query example.com</code>；若系统不使用 systemd-resolved，应先确认本机的 DNS 管理服务。

需要把完整订阅或配置发给别人分析吗？

不需要。提供脱敏后的字段、错误信息、时间、系统、客户端状态和少量日志即可。订阅链接、令牌、私钥、内部域名和办公网络地址不要公开。

相关阅读

参考资料

  1. Clash Verge Rev 扩展配置与脚本说明
  2. Clash Verge Rev 运行配置、日志与 DNS 覆写接口
  3. Mihomo DNS 配置文档
  4. Mihomo API 文档：日志与运行配置
  5. Microsoft Learn：nslookup 命令
  6. Google Chrome 安全与隐私设置
  7. Microsoft Edge 安全 DNS说明
  8. Firefox DNS over HTTPS说明