先弄清边界：TUN 接管流量不等于 DNS 自动防泄漏

在 Clash Verge、Clash Verge Rev 等图形客户端中打开 TUN 后，很多人会以为设备上的所有网络请求都已经进入 Mihomo，DNS 自然也不会绕过代理。实际情况要分开看：TUN 主要负责通过虚拟网卡接管 IP 流量；DNS 则可能由操作系统、浏览器、应用自身的 DoH（DNS over HTTPS），甚至路由器分别发起。只有当查询确实进入 Mihomo 的 DNS 处理链路，并按预期选择上游解析器时，配置才算完整。

例如，系统解析器向 UDP 53 端口发送查询时，TUN 可以捕获这类流量，但还需要配置 DNS 劫持，让 Mihomo 接收并处理查询。浏览器若启用了「安全 DNS」，通常会通过 HTTPS 访问独立解析服务，这看起来像普通网页流量，未必会被 dns-hijack 识别为传统 DNS 查询。另有一些应用会内置解析器，或者缓存之前得到的地址。因此，排查时不能只看 TUN 开关是否开启，也不能只凭某个 DNS 测试网站的一项结果就断定不存在泄漏。

可以把解析过程拆成三段：应用提出域名查询；Mihomo 决定使用 Fake-IP 还是获取真实地址；DNS 上游通过合适的网络路径完成解析。TUN 的职责主要在流量接管，而 dns 配置负责解析行为，两者相互配合但并非同一个开关。下文的配置以 Mihomo 为例，字段支持情况可能随内核版本和客户端界面有所差异，应用前应先核对正在运行的内核版本，并确保订阅合并配置没有覆盖相关选项。

理解 DNS 链路：Fake-IP、上游解析器与规则

常见的 enhanced-mode: fake-ip 会为域名返回一个虚拟地址。应用随后连接该地址，Mihomo 根据缓存的域名映射还原目标域名，再结合域名规则选择策略。这样做通常有利于保留域名信息用于分流，但它不意味着上游 DNS 查询一定走代理：Fake-IP 的本地应答与 Mihomo 向上游发起的真实解析是两个不同环节。

nameserver 是常用的默认上游解析器；fallback 与相关过滤项可用于按配置区分解析结果或备选解析，但不应把「写了多个服务器」误当成泄漏防护。关键在于查询由谁发出、走什么路由，以及不同域名会匹配哪个解析策略。境内可直连的解析器与需要通过代理访问的加密解析器，若在同一配置中没有明确区分，可能出现启动时无法解析代理节点域名、访问目标域名超时，或解析结果受到当前网络干扰等问题。

nameserver-policy 可以为指定域名或域名集合选择解析器，适合把内网域名、常用国内域名与其他域名分开处理。实际匹配规则要依据 Mihomo 当前版本支持的语法，并注意订阅中已有的策略设置。不要把政策规则写得比实际需求更宽：一条覆盖范围过大的通配规则，可能使原本应该走另一组解析器的域名也被提前匹配。

respect-rules: true 的作用是让 DNS 上游连接遵循代理规则，而不是一概直连。它能帮助 DNS 请求与常规出站策略保持一致，但也需要考虑启动依赖：如果代理节点本身使用域名，Mihomo 仍须有办法在建立代理连接前解析节点域名。可通过 proxy-server-nameserver 指定用于解析代理节点主机名的解析器，并选择在当前网络环境中可用的路径。若该解析器也依赖尚未建立的代理，容易形成循环等待。

记忆要点

Fake-IP 负责给客户端一个虚拟地址，nameserver-policy 负责选择解析器，respect-rules 影响解析器连接如何匹配规则。三者各自解决不同问题，配置前先确认目标，再一次只调整一个变量。

一套可检查的 YAML 配置思路

下面是用于说明字段关系的精简示例，不是可以直接套用到所有设备的完整配置。DNS 地址、规则集和节点配置应按当前网络及订阅实际情况调整；若客户端提供覆写或配置合并功能，也要检查最终生成的运行配置，而不只是编辑器里的源文件。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  respect-rules: true
  nameserver:
    - https://dns.example.net/dns-query
  proxy-server-nameserver:
    - 223.5.5.5
  nameserver-policy:
    "geosite:private":
      - 192.168.1.1
    "geosite:cn":
      - 223.5.5.5
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

示例中的 dns.example.net 是占位地址，不能原样当作真实解析服务使用。请替换为自己能够访问、并且 Mihomo 当前版本支持的 DoH 或其他解析器地址。listen 也需结合客户端运行方式判断：有的图形客户端管理 DNS 监听端口，手动指定端口前先确认不会与本机服务冲突。geosite:private、geosite:cn 是否可用，取决于配置中的规则数据与内核支持；如果没有对应数据，应使用当前配置已支持的域名规则写法。

proxy-server-nameserver 示例使用了一个可直连解析器，仅用于说明代理节点域名解析的独立性。若你的网络会干扰该解析器，或节点域名必须经特定链路解析，应选用经实际验证可用的设置。某些环境下把所有解析器都强制走代理，看似更统一，却可能让 Mihomo 在启动代理前无法解析节点地址；相反，默认全部直连也可能不符合隐私或网络策略要求。应针对「解析代理服务器」和「解析访问目标」分别做决定。

dns-hijack 示例针对传统 DNS 的 53 端口查询。它并不等同于接管浏览器的 DoH，也不保证所有使用自定义协议或独立网络栈的程序都会交给 Mihomo 解析。若系统或客户端界面另有 DNS 劫持设置，避免在多个层面重复启用未经确认的规则。修改后先保存并检查 YAML 能否通过内核校验，再观察 Mihomo 的 DNS 日志；不要在配置语法报错时继续用旧配置的运行结果判断新设置。

动手操作：按顺序启用并验证 DNS 路径

建议在网络状态稳定、方便回滚的时段操作。每次只改一个关键部分，并保留当前可用配置的副本。不同客户端的按钮名称可能不同，但「检查配置、重启内核、确认日志、清理缓存、复测」这一顺序适用于大多数 Mihomo 图形前端。

确认内核与配置来源。在客户端查看 Mihomo 版本，确认实际启用的配置文件或覆写项。记录当前 TUN、DNS、Fake-IP 和规则设置；若订阅会自动更新，避免在生成文件中修改后又被刷新覆盖。
先启用 DNS，再检查配置。确认 dns.enable 已启用，选择一种增强模式，并按需要填写上游解析器。随后使用客户端的配置检查或内核启动日志确认语法通过。若报错，优先检查缩进、字段拼写、列表层级和当前版本是否支持对应字段。
再启用 TUN 与 DNS 劫持。打开 TUN 后确认客户端显示运行正常，并核对路由自动配置、接口探测和 DNS 劫持选项。不同操作系统需要的权限、虚拟网卡支持及路由行为不同；如果客户端提示权限不足，应先处理权限，而不是反复调整解析器地址。
检查规则与启动解析。观察日志中代理节点域名是否能够解析、DNS 查询是否进入 Mihomo，以及目标域名最终匹配了什么策略。若出现循环解析、节点无法启动或上游超时，临时检查 respect-rules 与 proxy-server-nameserver 的组合，再恢复到最小可用配置逐项加入。
清理缓存后做对照测试。清除系统 DNS 缓存或重启相关应用，避免旧记录影响判断。先测试一个普通域名，再测试一个明确应走代理的域名和一个局域网域名；比较客户端日志、解析结果与实际连接策略。测试浏览器时，还应确认其安全 DNS 设置，避免浏览器与系统走两套解析链路。

出现问题时，可按现象缩小范围：如果 Mihomo 日志完全看不到查询，检查应用是否使用内置 DoH、是否存在另一张虚拟网卡，或 TUN 路由是否覆盖该流量；如果日志看到了查询但返回超时，检查上游连通性、解析策略和路由；如果解析正常但连接失败，再核对 Fake-IP 映射、规则命中和代理节点状态。日志中 DNS 事件的名称和详细程度会随内核版本变化，重点是确认查询是否被处理、匹配了什么策略、上游是否返回结果，而不是依赖某一条固定日志文本。

IPv6、浏览器 DoH 与泄漏来源定位

IPv6 是常被遗漏的一环。即使 IPv4 流量已经由 TUN 接管，如果操作系统获得了可用的 IPv6 地址和默认路由，而客户端或当前 TUN 配置没有覆盖 IPv6，部分应用仍可能通过原网络直接连接。不要仅因为 DNS 查询走了加密上游，就认定 IPv6 连接也经过代理；DNS 解析和后续 IP 流量是两个需要分别验证的路径。

先确认设备是否正在使用 IPv6，以及 Mihomo 和图形客户端当前如何处理 IPv6。若网络、节点和规则都不需要 IPv6，可以在明确了解系统影响后，暂时禁用设备侧 IPv6做对照测试；若需要保留 IPv6，则应确保路由接管、出站能力与规则均已正确配置。测试时比较开启与关闭 IPv6 后的连接行为，并查看目标连接的地址族和匹配策略。单独关闭 DNS 返回 AAAA 记录，并不能替代对实际 IPv6 路由的检查。

浏览器安全 DNS 是另一条常见旁路。它可能向自选 DoH 服务发送 HTTPS 请求，因此传统的 UDP/TCP 53 劫持通常无法直接识别其内容。排错时可暂时关闭浏览器的安全 DNS，让浏览器使用系统解析，再观察 Mihomo 日志是否出现对应查询。若问题随之消失，说明需要进一步统一浏览器与系统的解析策略，而不是简单增加更多 DNS 上游。

DNS 泄漏检测网站可以作为辅助线索，但结果受浏览器缓存、测试站点自身解析方式、网络出口及检测时机影响。更可靠的做法是结合多种证据：查看系统当前 DNS 设置与路由；检查 Mihomo 的 DNS 和连接日志；对比 TUN 开启前后的行为；暂时关闭浏览器 DoH 或其他 VPN、加速器、虚拟网卡做单变量测试。若仅使用网页检测结果，很难区分是系统查询绕行、浏览器独立解析，还是测试服务记录了代理出口的解析器。

排错时避免「全关再全开」

同时切换 Fake-IP、IPv6、上游解析器和规则模式，会让结果无法归因。先保存配置，再只改变一个选项；每次变更后重启或重载内核、清理缓存，并记录测试域名与结果。确认原因后再恢复其他设置。

常见问题

开启 TUN 后，为什么 DNS 测试仍显示运营商解析器？

可能是系统 DNS 查询没有被劫持、浏览器使用了独立 DoH、缓存尚未更新，或测试站点展示的是其观察到的递归解析器而不是你的设备配置。先检查 Mihomo 是否记录了测试域名查询，再临时关闭浏览器安全 DNS、清理缓存并复测。如果日志没有查询记录，应检查 TUN 路由、53 端口劫持及是否存在其他 VPN 或虚拟网卡。

启用 `respect-rules` 后，为什么节点无法启动？

常见原因是代理节点主机名也依赖代理才能解析，形成启动前置依赖。检查节点域名解析是否有独立的可用路径，并按当前 Mihomo 版本配置 proxy-server-nameserver。先用可直连且能正常工作的解析方式验证节点启动，再逐步调整上游和规则，不要把所有解析都绑定到尚未启动的代理链路。

Fake-IP 下局域网设备或内网域名无法访问怎么办？

确认内网域名是否应使用真实解析，并检查是否有适合当前配置的 Fake-IP 排除规则或私有域名解析策略。再核对局域网网段与 fake-ip-range 是否冲突，以及内网流量是否被规则错误地送进代理。修改后清理 DNS 缓存，并分别测试内网域名与内网 IP，判断问题出在解析还是路由。

关闭 IPv6 就能彻底防止 DNS 泄漏吗？

不能。关闭 IPv6只能作为定位 IPv6 路径问题的对照手段，无法修复浏览器 DoH、系统 IPv4 DNS 绕行或其他应用的自定义解析。应先找到实际绕行链路，再决定是调整 TUN 路由、DNS 劫持、浏览器设置，还是按网络需求处理 IPv6。

只靠系统代理或单一加速器时，常见限制是部分应用不遵循系统代理、DNS 设置分散在多个位置，出了问题也难以看清请求走向。Clash 配合 Mihomo 可以把规则分流、TUN 流量接管和 DNS 策略集中管理，并通过日志逐步定位解析链路；但稳定效果仍取决于内核版本与配置是否匹配。如果你希望在图形界面中管理配置并按本文步骤验证，不妨先了解适合自己设备的 Clash 客户端，再根据实际网络逐项启用。前往下载

Clash TUN模式与DNS防泄漏进阶配置实战指南