144 lines
12 KiB
Markdown
144 lines
12 KiB
Markdown
使用 Clash 时，代理连接正常、出口 IP 符合预期，只能说明部分网络请求已经经过代理。DNS 查询是否沿着预期路径发送，还需要单独确认。
|
||
|
||
这也是 DNS 防泄漏配置的重点：明确哪些查询由客户端处理，哪些交给远端节点解析，以及查询经过什么连接抵达解析服务。
|
||
|
||
本文面向采用 **Mihomo 内核的桌面客户端**，从解析路径出发，介绍一套可检查、可验证的配置方法。使用配置示例前，先确认客户端所用内核支持相应字段。
|
||
|
||
<nav class="guide-toc" aria-label="文章目录"><strong>阅读路线</strong><a href="#dns-1">识别两条不同的路径</a><a href="#dns-2">接管、加密和出口分别负责什么</a><a href="#dns-3">建立可检查的解析路径</a><a href="#dns-4">检查最终生效配置</a><a href="#dns-5">检查浏览器独立 DNS</a><a href="#dns-6">分三层验证</a><a href="#dns-7">补齐 IPv6 与故障验证</a></nav>
|
||
|
||
<h2 id="dns-1">01 识别两条不同的路径</h2>
|
||
|
||
DNS 泄漏通常发生在流量路径分离的地方。 应用访问网站前，可能先通过系统 DNS 查询域名。如果网页连接进入代理，而查询仍发送给本地路由器或运营商，两类请求就走了不同的路径。
|
||
|
||
<figure class="guide-diagram"><div class="diagram-label">图 1 · 网页走代理，查询可能走另一条路</div><div class="guide-flow"><div><b>应用</b><small>发起请求</small></div><span aria-hidden="true">→</span><div><b>Mihomo</b><small>接管网页连接</small></div><span aria-hidden="true">→</span><div><b>代理节点</b><small>连接目标网站</small></div></div><div class="guide-branch">另一路：应用 → 系统 DNS → 路由器 / 运营商</div><figcaption>如果 DNS 查询没有按预期接管，网页出口正常仍可能伴随解析绕行。</figcaption></figure>
|
||
|
||
普通 DNS 查询通常以明文传输，沿途网络可以观察其中的域名。这类查询主要暴露“访问了哪个域名”，通常不包含 HTTPS 网页的完整路径和正文。[Cloudflare：DNS 加密说明](https://developers.cloudflare.com/1.1.1.1/encryption/)
|
||
|
||
是否构成泄漏，还取决于预期策略。例如，明确安排公司内网域名由内部 DNS 解析，是正常的分流设计；要求经过代理的查询意外发送给运营商，才是需要处理的问题。
|
||
|
||
<h2 id="dns-2">02 接管、加密和出口分别负责什么</h2>
|
||
|
||
完整的 DNS 策略需要同时考虑接管、加密和出口。
|
||
|
||
| 配置层面 | 需要解决的问题 |
|
||
|---|---|
|
||
| DNS 接管 | 应用发出的查询是否进入 Mihomo |
|
||
| 查询加密 | Mihomo 与上游 DNS 之间是否使用 DoH 或 DoT |
|
||
| 出口选择 | 上游 DNS 连接通过代理还是直接连接 |
|
||
|
||
只填写 `1.1.1.1` 这样的地址，通常只是更换 DNS 服务商。使用 DoH 或 DoT 才涉及传输加密，而加密连接本身仍有直连和代理两种路径。[Cloudflare：加密 DNS](https://developers.cloudflare.com/1.1.1.1/encryption/)
|
||
|
||
因此，配置时应当明确指定解析服务和出口，并检查应用有没有绕过这套设置。
|
||
|
||
<h2 id="dns-3">03 建立可检查的解析路径</h2>
|
||
|
||
可以先建立一条简单、明确的解析路径，再逐步增加分流。 以下示例使用 TUN 接管流量，将普通 DNS 查询交给 Mihomo，并让本机需要发出的上游查询经过指定代理组。
|
||
|
||
代理节点自身的域名使用独立解析服务处理。这样，在代理尚未建立时，客户端就能取得节点地址，避免解析过程反过来依赖尚未连通的代理。
|
||
|
||
<figure class="guide-diagram"><div class="diagram-label">图 2 · 查询与引导解析分开处理</div><div class="guide-flow"><div><b>应用查询</b><small>系统 DNS / TUN</small></div><span aria-hidden="true">→</span><div><b>Mihomo DNS</b><small>需要真实地址时</small></div><span aria-hidden="true">→</span><div><b>代理组</b><small>必须选中代理</small></div><span aria-hidden="true">→</span><div><b>加密 DNS</b><small>处理本机上游查询</small></div></div><div class="guide-branch">独立引导：节点域名 → 引导 DNS（直连）→ 节点 IP → 建立代理</div><figcaption>图示为本机上游查询路径；部分连接会将域名交由远端节点解析。</figcaption></figure>
|
||
|
||
如果还不清楚 TUN 与系统代理分别接管什么，可以先看[系统代理与 TUN 的区别](/a/system-proxy-vs-tun.html#tun)，再调整下面的配置。
|
||
|
||
实际操作前，先备份当前配置。下面只包含 TUN 与 DNS 部分，需要通过客户端提供的配置编辑或覆写功能整合到现有配置中。
|
||
|
||
<div class="guide-note"><strong>这是合并片段，不是完整配置</strong><p>先备份，确认内核支持字段及代理组名称，再使用客户端的覆写或合并功能。不要覆盖节点和分流规则。</p></div>
|
||
|
||
```yaml
|
||
tun:
|
||
enable: true
|
||
auto-route: true
|
||
auto-detect-interface: true
|
||
|
||
# 需要支持该字段的近期 Mihomo 内核
|
||
dns-mode: native
|
||
|
||
dns-hijack:
|
||
- any:53
|
||
- tcp://any:53
|
||
|
||
strict-route: true
|
||
|
||
dns:
|
||
enable: true
|
||
listen: 127.0.0.1:1053
|
||
enhanced-mode: fake-ip
|
||
|
||
# 解析 DNS 服务自身的域名
|
||
default-nameserver:
|
||
- tls://223.5.5.5
|
||
|
||
# 独立解析代理节点域名
|
||
proxy-server-nameserver:
|
||
- "tls://223.5.5.5#DIRECT"
|
||
|
||
# 替换为配置中真实存在的代理组名称
|
||
nameserver:
|
||
- "https://cloudflare-dns.com/dns-query#节点选择"
|
||
```
|
||
|
||
示例中的 `#节点选择` 指定上游 DNS 连接使用该代理组。应用前，需要将它替换成实际名称，并确认该组最终选中代理节点，也不会在失败时回退到 `DIRECT`。Mihomo 支持在 DNS 地址后指定代理或接口；通过代理查询时，应同时配置独立的节点域名解析服务。[Mihomo DNS 配置](https://wiki.metacubex.one/config/dns/)
|
||
|
||
这里选用阿里 DNS 的 DoT 地址作为引导解析示例，该地址也出现在 Mihomo 的官方配置中。它是否适合当前网络，仍需实际验证。[Mihomo 配置示例](https://wiki.metacubex.one/example/conf/)
|
||
|
||
引导解析直接连接指定服务，意味着该服务可以看到节点域名等引导查询。这是一项明确的信任选择，应当与网站域名的解析路径分别理解。
|
||
|
||
`dns-mode: native` 用于将系统 DNS 指向 TUN；`dns-hijack` 则将匹配的 DNS 连接导入内置解析模块。系统 DNS 仍指向局域网路由器时，单靠劫持配置存在平台限制。如果内核不支持 `dns-mode`，应先核对客户端对应的系统 DNS 接管功能。[Mihomo TUN 配置](https://wiki.metacubex.one/config/inbound/tun/)
|
||
|
||
<h2 id="dns-4">04 检查最终生效配置</h2>
|
||
|
||
配置合并之后，还需要检查最终生效的内容。 订阅原有的 `nameserver-policy`、`fallback` 和 `direct-nameserver` 都可能影响解析路径。新增一个 `nameserver`，并不会自动清除已有策略。
|
||
|
||
初次排查时，保持路径简单更容易定位问题。公司内网、NAS 或自定义局域网域名，则应按需保留专门的解析规则；公共 DNS 通常无法解析这些内部名称。
|
||
|
||
<h2 id="dns-5">05 检查浏览器独立 DNS</h2>
|
||
|
||
浏览器的安全 DNS 会增加一条需要检查的路径。 Chrome 等浏览器可以自行使用 DoH，此时查询可能绕过 Mihomo 的 DNS 模块，但 DoH 连接仍可能经过 TUN 和代理。
|
||
|
||
排查时，可以记录浏览器原设置，临时关闭其独立的安全 DNS，让查询先统一进入系统解析路径。确认接管正常后，再决定是否恢复独立解析，并验证对应连接的出口。
|
||
|
||
Chrome 的自动模式在安全查询失败时可能使用未加密查询；选择自定义提供商时，回退行为有所不同。因此，验证时也应记录浏览器采用了哪一种模式。[Chrome 官方说明](https://support.google.com/chrome/answer/10468685?hl=en&co=GENIE.Platform%3DDesktop)
|
||
|
||
<h2 id="dns-6">06 分三层验证</h2>
|
||
|
||
验证应同时观察解析结果和传输路径。 DNS 检测网站适合发现异常，但无法独自覆盖整台设备的所有流量。
|
||
|
||
<figure class="guide-diagram"><div class="diagram-label">图 3 · 从结果检查到路径证据</div><div class="guide-flow"><div><b>检测网站</b><small>观察解析服务商</small></div><span aria-hidden="true">→</span><div><b>生效配置</b><small>核对上游和出口</small></div><span aria-hidden="true">→</span><div><b>物理网卡</b><small>检查绕行查询</small></div></div><div class="guide-branch">每一层都需要结合预期策略：没有异常记录 ≠ 所有场景都不会泄漏</div><figcaption>测试应记录客户端与内核版本、网络环境以及观察范围。</figcaption></figure>
|
||
|
||
可以先访问 [DNSLeakTest](https://www.dnsleaktest.com/)，执行 Extended test。测试会让浏览器查询一组域名，再观察哪些 DNS 服务器参与解析。同一家服务商可能使用多个服务器，所以结果中的 IP 数量不能直接作为泄漏数量。[DNSLeakTest 测试原理](https://www.dnsleaktest.com/what-is-the-difference.html)
|
||
|
||
阅读结果时，可以参考下面的判断方式：
|
||
|
||
| 检测结果 | 如何理解 |
|
||
|---|---|
|
||
| 出现预期的解析服务商 | 与策略相符，继续确认连接出口 |
|
||
| 出现未预期的本地运营商 | 检查系统 DNS、浏览器设置及接管范围 |
|
||
| DNS 所在国家与节点不同 | 地理位置差异本身不足以判定泄漏 |
|
||
| 出现远端节点使用的解析服务 | 核对是否由节点完成域名解析 |
|
||
|
||
这里需要特别注意 Fake-IP 模式。Mihomo 可以将目标域名交给远端代理，由远端完成解析。因此，即使本机配置了 Cloudflare，检测结果也未必只出现 Cloudflare；本机 `nameserver` 无法统一规定远端节点的解析服务。[Mihomo 解析流程](https://wiki.metacubex.one/config/dns/diagram/)
|
||
|
||
接着检查客户端的生效配置、代理组选择和可用的连接记录。缓存、日志级别及客户端展示方式都会影响观察结果，缺少某条日志只能说明当前没有看到相应记录。
|
||
|
||
如果需要更直接的证据，可以使用 Wireshark 抓取当前联网的 Wi-Fi 或以太网接口，并输入显示过滤器：
|
||
|
||
```text
|
||
udp.port == 53 || tcp.port == 53
|
||
```
|
||
|
||
随后重新运行 DNS 检测，观察是否有测试域名的查询发往路由器或其他非预期服务器。该表达式用于筛选 TCP、UDP 的 53 端口流量。[Wireshark 过滤器说明](https://sharkfest.wireshark.org/retrospective/sfeu/presentations24eu/03.pdf)
|
||
|
||
抓包位置会影响结论。在 TUN 或回环接口中看到应用向 Mihomo 提交 DNS，可能属于正常接管过程；检查查询有没有离开预期路径，应重点观察实际联网的物理接口。
|
||
|
||
同时，53 端口没有查询，也只能说明这次观察中未发现相应流量。DoH 通常使用 443，DoT 通常使用 853，还需要结合目的地址和连接路径判断。[Cloudflare：加密协议与端口](https://developers.cloudflare.com/1.1.1.1/encryption/)
|
||
|
||
<h2 id="dns-7">07 补齐 IPv6 与故障验证</h2>
|
||
|
||
IPv6 和故障状态需要分别检查。 `dns.ipv6: false` 控制 Mihomo DNS 对 AAAA 查询的响应，并没有关闭整台设备的 IPv6。如果当前网络支持 IPv6，应确认这部分流量同样符合接管和出口策略。[Mihomo IPv6 DNS 设置](https://wiki.metacubex.one/config/dns/#ipv6)
|
||
|
||
`strict-route` 不是独立的断线保护开关。它的作用也与平台相关。例如，Windows 下会通过防火墙规则处理多网卡 DNS 泄漏问题。对于客户端退出、内核崩溃、休眠恢复等情况，是否仍能阻止意外直连，需要另行验证断线保护机制。[Mihomo 严格路由说明](https://wiki.metacubex.one/config/inbound/tun/#strict-route)
|
||
|
||
完成配置后，建议保留一份简短记录：客户端和内核版本、测试网络、预期 DNS 路径，以及实际观察结果。更换订阅、更新客户端或切换网络后，按照同样的方法复查，才能持续确认这套策略仍然有效。
|
||
|
||
尚未安装客户端，可先阅读[Windows 入门教程](/a/clash-verge-rev-windows.html)。
|