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