DNS 泄露原理及解决方案详解

源文档链接和作者: linux.do—yeahow

本文总结目标: 深入浅出地解释 DNS 泄露的原理、检测方法和各种解决方案，并提供实操指导，最终帮助读者理解并解决 DNS 泄露问题。

前言

你是否在使用代理软件“科学上网”时，担心自己的上网行为被泄露？“DNS 泄露” 就是一种常见的隐私泄露途径。本文将从最底层的原理开始，用最易懂的方式，结合生动的例子和图片，帮你彻底搞懂 DNS 泄露，并学会如何防范。即使你是网络小白，也能轻松看懂！

1. 前置知识 - 理解基础概念

为了更好地理解 DNS 泄露，我们先来了解一些计算机网络的基础知识。

1.1 计算机网络五层结构

互联网世界就像一个复杂的交通系统，为了让数据准确高效地传输，计算机网络被划分为五个层次，每一层负责不同的任务，就像工厂的流水线一样。这五层结构由下到上分别是：

物理层: 负责物理信号的传输，比如网线、光纤，就像道路。
数据链路层: 在物理层之上，负责在相邻节点之间可靠地传输数据，比如网卡、交换机，就像道路上的交通规则。
网络层: 负责在不同网络之间寻址和路由，最核心的协议是 IP 协议 (Internet Protocol)，就像地图和导航系统。
传输层: 为应用层提供可靠的、面向连接的 TCP 协议 (Transmission Control Protocol) 或者无连接的 UDP 协议 (User Datagram Protocol)，就像运输方式 (货车、火车、飞机)。
应用层: 直接与应用程序交互，提供各种网络服务，比如 HTTP 协议 (Hypertext Transfer Protocol - 网页浏览)、DNS 协议 (Domain Name System - 域名解析)，就像最终的商品和服务。

简单来说，当你在浏览器输入网址访问网页时，你的请求会从应用层开始，一层层向下封装，经过物理层传输到互联网，再一层层向上解封装，最终到达目标服务器。

为了更形象地理解，请看下图：

1.2 系统代理

系统代理 可以理解为操作系统提供的一个“开关”，开启后，部分应用程序 (主要是浏览器) 会“听话地”将网络请求交给指定的 代理软件 (例如 Clash)。

注意： 系统代理只是一种“约定”，不是强制性的。很多软件 (例如某些App) 可能不遵守系统代理设置，会直接连接网络，不经过代理。

工作流程:

开启系统代理后，当浏览器访问 google.com 时，浏览器会将访问请求交给 Clash。
Clash 根据你预设的 分流规则 判断是否需要代理。如果访问 google.com，通常会匹配到需要代理的规则。
Clash 对数据进行加密和封装 (应用层)，加上 TCP 头部 (传输层)、IP 头部 (网络层) 等信息。
数据包经过你的路由器，最终发送到 代理服务器 (也就是你购买的“梯子”节点)。
代理服务器作为中转站，帮你访问 google.com，并将网页内容返回，数据传输路径也是原路返回。

通过系统代理，你可以借助代理服务器访问被限制的网站。

系统代理的工作流程可以用下图表示：

1.3 TUN 模式

TUN 模式 是一种更强大的代理方式，可以解决系统代理“管不住”所有软件的问题。

原理: 代理软件 (Clash) 会创建一个 虚拟网卡，就像电脑里多了一块“假的”网卡。开启 TUN 模式后，所有经过你电脑的网络流量，都会被强制经过这张虚拟网卡。代理软件可以从虚拟网卡中读取所有网络请求，并进行处理。

TUN 模式工作在网络层，这意味着它可以接管所有网络流量，包括那些不遵守系统代理的软件。 软路由的原理和 TUN 模式类似，都是在网络层接管流量。

工作流程:

开启 TUN 模式后，当浏览器访问 google.com 时，请求会像往常一样进行协议栈封装 (应用层、传输层、网络层头部)。
关键步骤： 由于 Clash 虚拟网卡接管了 网络层 的所有流量，所以流量会被“劫持”到 Clash。
之后，Clash 同样会根据分流规则判断是否需要代理，进行加密等处理。
处理后的流量再从 Clash 虚拟网卡流出，通过 物理网卡 发送到互联网，后续过程和正常上网一样。

TUN 模式就像一个“交通枢纽”，所有网络流量都必须经过它，代理软件可以完全控制流量的走向。

TUN 模式的工作流程如下图所示：

1.4 DNS 的过程 - 域名解析

DNS (域名系统) 的作用是将人类容易记忆的域名 (例如 baidu.com) 转换为计算机网络中真正的地址 IP 地址 (例如 180.101.49.12)。就像查字典一样，通过域名找到对应的 IP 地址，才能访问网站。

DNS 解析流程:

当你在浏览器输入 baidu.com 时，电脑首先会查找 浏览器 DNS 缓存 和 操作系统 DNS 缓存 (Windows 系统的 hosts 文件)。如果找到 baidu.com 对应的 IP 地址，就直接使用，解析结束。
如果缓存中没有，电脑会向 本地 DNS 服务器 发送 DNS 查询请求 (通常是你的 路由器，路由器会配置运营商的 DNS)。
本地 DNS 服务器收到请求后，如果自己有 baidu.com 的缓存，就返回结果；如果没有，它会向上级 运营商 DNS 服务器 (例如中国电信的 DNS) 发送请求。
运营商 DNS 服务器再向上级 DNS 服务器递归查询，直到找到 baidu.com 的权威 DNS 服务器 (专门负责解析 baidu.com 域名的服务器)。
权威 DNS 服务器查询到 baidu.com 对应的 IP 地址，并将结果 原路返回 给你的电脑。
沿途经过的 DNS 服务器都会缓存 baidu.com 的解析结果，下次查询时就不用跑那么远了。

DNS 解析就像一个“寻址”过程，帮助你的电脑找到网站服务器的真正位置。

DNS 解析的过程可以用下图来理解：

更详细的 DNS 解析过程示意图如下：

2. DNS 泄露 - 隐私泄露的风险

2.1 什么是 DNS 泄露？

DNS 泄露 指的是，在使用代理的情况下，本应该通过代理服务器进行 DNS 查询，但实际上 DNS 查询请求却 直接使用了本地 DNS 服务器，导致你的 真实 DNS 服务器 (通常是运营商 DNS) 记录了你访问的域名。

场景分析 (系统代理下):

假设你开启了系统代理，并访问 google.com。

正常情况 (理想情况): Clash 接收到你的 google.com 访问请求后，根据分流规则，判断 google.com 需要走代理。所有与 google.com 相关的网络操作 (包括 DNS 查询)，都应该通过 代理服务器 完成。这样，你的 DNS 查询请求会发送到代理服务器，再由代理服务器进行解析，你的运营商 DNS 服务器不会知道你访问了 google.com。
DNS 泄露情况: 如果你的 Clash 分流规则配置不当，例如没有针对 google.com 的具体规则，而是只有类似 GEOIP,CN,DIRECT (中国 IP 直连) 和 MATCH,代理节点 (默认走代理) 这样的规则。
1. 当 Clash 匹配到 GEOIP,CN,DIRECT 规则时，它需要 解析域名 google.com， 获取其 IP 地址，才能判断这个 IP 是否是中国 IP。
2. 问题就出在这里： 为了获取 google.com 的 IP 地址，Clash 可能会 使用你的本地 DNS 服务器 进行 DNS 查询。
3. 结果： 你的 DNS 查询请求 (目标域名是 google.com) 直接发送给了你的运营商 DNS 服务器，运营商 DNS 服务器记录了你访问 google.com 的记录，即使最终访问 google.com 的流量走了代理，但 DNS 查询过程已经泄露了你的意图。

总结： DNS 泄露的本质是，本应通过代理的 DNS 查询请求，却意外地使用了本地 DNS，导致隐私泄露。

2.2 `ipleak.net` 等检测 DNS 泄露网站的原理

ipleak.net 这样的网站可以帮助你检测是否存在 DNS 泄露。

检测原理:

当你访问 ipleak.net 时，网站会在后台 随机生成大量唯一的域名 (例如 random12345.ipleak.net, unique-domain.ipleak.net 等)。
网站会 针对这些随机域名发起 DNS 查询请求。由于域名是随机生成的，保证了：
- 唯一性: 每个域名只会被查询一次。
- 无缓存: 这些域名不会存在于任何中间 DNS 服务器的缓存中。
- 直达权威: DNS 查询请求会最终到达 ipleak.net 的 权威 DNS 服务器 (负责解析 ipleak.net 域名的服务器)。
ipleak.net 的权威 DNS 服务器会 记录下发起 DNS 查询请求的 DNS 服务器的 IP 地址 (也就是你的 上游 DNS 服务器，通常是运营商 DNS)。
ipleak.net 网站会将这些 上游 DNS 服务器的 IP 地址 显示出来。

判断是否 DNS 泄露:

没有 DNS 泄露: 所有 DNS 查询都经过代理服务器，ipleak.net 显示的 DNS 服务器 IP 地址应该是 代理服务器的 IP 地址 (或者与代理服务器地理位置相近的 IP)。
存在 DNS 泄露: ipleak.net 显示的 DNS 服务器 IP 地址中，包含 你的本地 DNS 服务器的 IP 地址 (通常是 中国境内的 IP 地址，例如运营商 DNS)，这就说明你的 DNS 查询请求泄露给了本地 DNS 服务器。

ipleak.net 就像一个“侦探”，通过追踪 DNS 查询的路径，来判断你的 DNS 请求是否安全地通过了代理。

2.3 Netflix 等网站的检测

Netflix 等对地区限制严格的网站，也会使用类似 DNS 泄露检测的原理来判断你是否使用了代理。

检测原理:

Netflix 网站在后台会 偷偷发起 DNS 查询请求。
如果存在 DNS 泄露，负责与 Netflix 权威 DNS 服务器对话的 DNS 服务器 IP 地址 (泄露的本地 DNS 服务器) 的 地理位置，会与你访问 Netflix 网站时使用的 代理节点 IP 地址的地理位置 不一致。
Netflix 就会判定你使用了代理工具，可能导致无法观看视频，甚至账号被封禁。

Netflix 的检测就像一个“地理位置比对器”，如果 DNS 服务器的地理位置和代理节点的地理位置不一致，就认为你可能使用了代理。

Netflix 的检测原理可以用下图表示：

3. 试图解决 DNS 泄露 (系统代理下)

3.1 方案一：配置好分流规则

思路: 最直接的解决方案是 完善 Clash 的分流规则，确保所有你想走代理的域名，都有明确的规则指示走代理，避免匹配到 GEOIP,CN,DIRECT 规则时使用本地 DNS 查询。

例如: 添加规则 DOMAIN-SUFFIX, google.com, 节点1，这样访问 google.com 就会直接匹配到这条规则，所有与 google.com 相关的操作 (包括 DNS 查询) 都会通过 节点1 代理服务器进行，不会使用本地 DNS。

优点: 简单直接，针对性强。

缺点:

不完美: 你不可能预知所有未来要访问的国外网站，总会有规则没有覆盖到的情况。
维护成本高: 每次访问新网站，可能都需要手动添加规则。
适合场景: 主要访问国内网站，偶尔访问国外固定网站的用户。

这种方案就像“定制化路线”，为常去的国外网站规划好代理路线，但如果去了“新地方”，可能会迷路 (DNS 泄露)。

3.2 方案二：`no-resolve` 关键字

思路: 在 GEOIP,CN,DIRECT 规则后面加上 no-resolve 关键字，变成 GEOIP,CN,DIRECT,no-resolve。

no-resolve 的作用: 当 Clash 匹配规则时，如果需要进行 DNS 解析 来检查域名的 目标 IP 是否符合规则 (例如 GEOIP,CN,DIRECT 需要判断 IP 是否是中国 IP)，加上 no-resolve 后，就会 跳过 DNS 解析 这一步。

工作原理:

当访问 google.com 时，遇到 GEOIP,CN,DIRECT,no-resolve 规则，由于有 no-resolve， Clash 不会进行 DNS 解析， 不会获取 google.com 的 IP 地址，因此 不会使用本地 DNS 服务器，也就 不会发生 DNS 泄露。
由于 GEOIP,CN,DIRECT,no-resolve 规则没有匹配成功 (因为没有进行 DNS 解析，无法判断是否是中国 IP)，请求会继续向下匹配，最终匹配到 MATCH,代理节点1 规则，访问 google.com 的流量仍然会走代理。

优点: 可以有效避免 DNS 泄露。

缺点:

国内网站可能误走代理: 例如访问 baidu.com，遇到 GEOIP,CN,DIRECT,no-resolve 规则时，由于跳过了 DNS 解析，无法判断 baidu.com 是否是中国网站，规则没有匹配成功，最终可能匹配到 MATCH,代理节点1 规则，导致 baidu.com 的流量也走了代理，影响访问速度和浪费流量。
需要手动添加国内网站直连规则: 为了避免国内网站误走代理，你需要手动添加国内常用网站的直连规则，例如 DOMAIN-SUFFIX, baidu.com, DIRECT。
适合场景: 主要访问国外网站，对 DNS 泄露零容忍的用户。

no-resolve 就像一个“绕行卡”，绕过了 DNS 解析这个“检查站”，避免了泄露，但也可能走错路 (国内网站误走代理)。

改进方案: 结合订阅转换工具，自动生成包含 no-resolve 的 IP 规则，并手动添加常用国内网站的直连规则，可以兼顾防泄露和国内网站访问体验。但对于不常见的国内小众网站，仍然可能走代理。

4. 透明代理下的 DNS 泄露 (TUN 模式)

4.1 透明代理的概念

透明代理 的“透明”指的是，对于应用程序 (例如浏览器) 来说，它们 感知不到代理客户端的存在。

系统代理: 浏览器会 “主动” 按照系统代理设置，将请求交给代理软件。浏览器是 “知道” 自己在使用代理的。
TUN 模式: 浏览器像往常一样发送网络请求，只是流量被虚拟网卡 “劫持” 了，浏览器 “不知道” 流量被代理软件处理了。对于浏览器来说，代理是 “透明的”。

TUN 模式下，代理软件工作在更底层，对应用程序来说是无感的，更彻底、更强大。

4.2 前置知识 - TUN 模式下的 DNS 处理

在 TUN 模式下，应用程序发起 TCP 连接时，会先进行 DNS 查询获取目标服务器 IP 地址。在拿到 IP 地址之前，连接无法建立。

TUN 模式下的 DNS 处理方式与系统代理不同：

系统代理: DNS 解析通常由 本地 DNS 服务器 完成。
TUN 模式: 代理软件 (Clash) 会 劫持所有 53 端口 (DNS 协议默认端口) 的请求， DNS 解析由代理软件自身完成。也就是说，最终返回给应用程序的 IP 地址是由代理软件提供的。

代理软件提供 IP 地址的方式有两种:

redir-host 模式 (真实 IP 模式): 代理软件进行 真实的 DNS 查询，获取目标域名对应的 真实 IP 地址，然后返回给应用程序。
fake-ip 模式 (虚假 IP 模式): 代理软件 不进行真实 DNS 查询，而是 随机生成一个虚假的 IP 地址 (通常是私有 IP 地址段)，先返回给应用程序建立连接。真正的域名解析和连接处理在后续步骤中完成。

TUN 模式下的 DNS 处理流程可以用下图概括：

4.3 `redir-host` 模式及其问题

工作流程 (redir-host 模式):

浏览器访问 google.com，发起 DNS 查询请求。
DNS 请求被 Clash 虚拟网卡截获。
Clash 进行真实的 DNS 查询: Clash 会同时向配置文件中指定的 上游 DNS 服务器 (nameserver，例如 114.114.114.114, 223.5.5.5) 发起 DNS 请求， 谁先返回结果就用谁的。
可能获取到污染的 IP 地址: 例如，国内 DNS 服务器可能返回被污染的 google.com 的 IP 地址 5.5.5.5。
Clash 维护域名-IP 映射表: Clash 会将域名 google.com 和 IP 地址 5.5.5.5 存储在映射表中。
Clash 将 DNS 查询结果 (污染的 IP 5.5.5.5) 返回给浏览器。
浏览器拿到 IP 地址后，向 5.5.5.5 发起连接请求。
请求到达 Clash 后，Clash 根据目标 IP 5.5.5.5 查询映射表，找到对应的域名 google.com。
Clash 根据分流规则处理 google.com 的请求，例如匹配到 DOMAIN,google.com, 代理节点1 规则，后续流量交给 节点1 代理。
代理节点 1 会重新进行 DNS 查询，获取未被污染的 google.com 的真实 IP 地址。

redir-host 模式的工作流程可以用下图表示：

redir-host 模式的问题:

必然发生 DNS 泄露: 为了获取真实 IP 地址，redir-host 模式 必须进行一次真实的 DNS 查询 (步骤 3)，这次 DNS 查询仍然可能使用你的本地 DNS 服务器 (nameserver 中配置的国内 DNS)，导致 DNS 泄露。
域名混淆问题: 如果多个域名 (例如 google.com, youtube.com) 被解析到 同一个被污染的 IP 地址 (例如 5.5.5.5)， Clash 查映射表时， 无法区分 浏览器到底要访问哪个域名 (步骤 😎 。虽然 HTTP 请求头中包含域名信息，但 Clash 可能无法获取到 (取决于具体实现)。

域名混淆问题可以用下图说明：

4.4 改进后的 `redir-host` 模式 (fallback 机制)

为了解决 redir-host 模式的问题，可以进行改进：

不再查询映射表: 改进后的 redir-host 模式 不再需要查询域名-IP 映射表 (避免域名混淆问题)。
DNS 查询结果直接给代理节点: Clash 在本地 DNS 查询后，将获取的 IP 地址 (即使是被污染的) 直接传输给代理节点，后续连接和数据处理都由代理节点负责。

新的问题： 如果使用国内 DNS 服务器 (nameserver) 进行 DNS 查询，可能获取到 被污染的 IP 地址 (例如 5.5.5.5)，代理节点拿到这个污染的 IP 后， 无法访问到真正的 google.com 服务器。

解决方案：引入 fallback 机制

DNS 配置改进:

dns:
  enable: true
  enhanced-mode: redir-host
  nameserver:
    - 114.114.114.114  # 国内 DNS
    - 223.5.5.5    # 国内 DNS
  fallback:
    - https://1.1.1.1/dns-query  # 国外加密 DNS (Cloudflare DoH)

fallback 的作用: fallback 中配置的是 境外的、不会被污染的 DNS 服务器 (例如 1.1.1.1, 8.8.8.8)。
并发查询: 当 Clash 发起 DNS 查询时，会 同时向 nameserver 和 fallback 中的所有 DNS 服务器并发请求。
结果选择:
- 如果 nameserver 返回的 IP 地址 归属地不是中国 (CN)，则 使用 fallback 的 DNS 查询结果 (通常是未被污染的 IP)。
- 如果 nameserver 返回的 IP 地址 归属地是中国 (CN)，则 使用 nameserver 的 DNS 查询结果 (可能是国内 CDN 服务器 IP)。

通过 fallback 机制，可以尽量获取到未被污染的国外网站 IP 地址，同时国内网站仍然使用国内 DNS 服务器解析，提高访问速度。

改进后的 redir-host 模式工作流程如下：

但即使使用了 fallback， redir-host 模式仍然存在 DNS 泄露的风险。 因为 nameserver 和 fallback 是 并发请求 的，即使最终使用了 fallback 的结果，但 nameserver 中的国内 DNS 服务器仍然会收到你的 DNS 查询请求，仍然可能记录你的访问域名。

更进一步的优化：fallback-filter 和 geosite
- fallback-filter:可以根据地理位置 (geoip)和域名列表 (geosite)进一步过滤fallback的使用条件。
  - geoip: true, geoip-code: CN: 默认启用，表示除了中国 IP，其他 IP 结果都被视为污染，会采用 fallback 结果。
  - domain: 可以手动添加域名列表，例如 domain: - '+.google.com' - '+.youtube.com'，这些域名即使解析到中国 IP，也会使用 fallback 结果。
  - ipcidr: 可以手动添加 IP 段，例如 ipcidr: - 240.0.0.0/4，这些 IP 段的结果会被视为污染，使用 fallback 结果。
- geosite: 可以指定域名列表，例如 geosite: - gfw， 匹配到 gfw 列表中的域名，只会使用 fallback 解析，不会使用 nameserver，从而 彻底避免向国内 DNS 服务器发起 DNS 请求，进一步降低 DNS 泄露风险。

配置示例:

dns:
  enable: true
  enhanced-mode: redir-host
  nameserver:
    - 114.114.114.114
    - 223.5.5.5
  fallback:
    - https://1.1.1.1/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
    geosite:
      - gfw
    ipcidr:
      - 240.0.0.0/4
    domain:
      - '+.google.com'
      - '+.youtube.com'

展开

nameserver-policy 替代 geosite (更强大的 DNS 分流)

Clash Verge Rev 提示建议使用 nameserver-policy 替代 geosite， nameserver-policy 功能更强大，可以实现更灵活的 DNS 分流策略。

nameserver-policy 的优势:

指定域名解析服务器: 可以直接为特定域名或域名列表指定使用的 DNS 服务器。
更精细的控制: 可以根据域名、地理位置等条件，实现更个性化的 DNS 分流。

配置示例:

dns:
  nameserver:
    - tls://8.8.4.4  # 国外 DNS (DoT)
    - tls://1.1.1.1  # 国外 DNS (DoT)
  nameserver-policy:
    '+.notion.com': tls://dns.jerryw.cn  # notion.com 使用 jerryw.cn 的 DNS
    'geosite:cn':
      - 223.5.5.5   # 国内域名使用阿里云 DNS
      - 114.114.114.114 # 国内域名使用 114 DNS

总结：改进后的 redir-host 模式通过 fallback、fallback-filter、geosite、nameserver-policy 等机制，可以缓解 IP 污染和 DNS 泄露问题，但 redir-host 模式本身固有的 DNS 泄露风险仍然存在。

4.5 `redir-host` 模式的局限性

CDN 优选问题: redir-host 模式下，DNS 查询是在国内发起的 (即使使用了国外 DNS 服务器)，获取到的 IP 地址通常是 离你地理位置较近的 CDN 服务器 IP。但你实际访问网站是通过 代理节点 出国，代理节点的地理位置可能很远。 导致 CDN 节点不是最优的，可能影响访问速度。

CDN 优选问题示意图如下：

速度和延迟问题: 国内直接访问国外 DNS 服务器速度较慢，加密 DNS (DoH/DoT) 会增加延迟。

由于 redir-host 模式存在较多问题，官方已弃用，现在 **主流推荐使用 fake-ip 模式**。 大部分订阅配置文件的 enhanced-mode 默认都是 fake-ip。

4.6 `fake-ip` 模式 - 更优的解决方案

fake-ip 模式的核心思想：先用假的 IP 地址建立连接，再进行真实的域名解析和连接处理。

工作流程 (fake-ip 模式):

浏览器访问 google.com，发起 DNS 查询请求。
DNS 请求被 Clash 虚拟网卡截获。
Clash 返回一个虚假的 IP 地址: Clash 不进行真实 DNS 查询，而是 随机生成一个虚假的 IP 地址 (例如 198.18.x.x 私有 IP 段内的地址)，并 建立域名-IP 映射表 (记录 google.com 对应这个虚假 IP)。
Clash 将虚假 IP 地址返回给浏览器。
浏览器拿到虚假 IP 地址后， 向这个虚假 IP 地址发起连接请求。
请求到达 Clash 后，Clash 根据 目标 IP (虚假 IP) 查询映射表，找到对应的 域名 google.com。
Clash 根据分流规则处理 google.com 的请求，例如匹配到 DOMAIN,google.com, 代理节点1 规则，后续流量交给 节点1 代理。
代理节点 1 会进行真实的 DNS 查询，获取 google.com 的真实 IP 地址，并与 google.com 服务器建立连接，完成后续数据传输。

fake-ip 模式的工作流程可以用下图表示：

fake-ip 模式的优势:

避免 DNS 泄露: 本地 DNS 服务器 不会收到真实的 DNS 查询请求， DNS 查询由代理节点完成， 彻底避免 DNS 泄露。
解决 CDN 优选问题: 真实的 DNS 查询在 代理节点 进行，获取到的 IP 地址是 更适合代理节点地理位置的 CDN 服务器 IP，实现 CDN 优选，提高访问速度。
速度更快: 本地 DNS 查询速度非常快 (直接返回虚假 IP)，无需等待真实 DNS 查询完成，连接建立速度更快。

4.7 `fake-ip` 模式的一些小问题

虚假 IP 缓存问题: 如果访问国内网站时缓存了虚假 IP，之后 Clash 意外退出，虚假 IP 可能仍然存在于电脑缓存中，虚假 IP 可能仍然存在于电脑缓存中，再次访问国内网站可能会出错。 Clash 尝试将 DNS 响应中的 TTL (Time-To-Live，生存时间) 值设置为 1 秒，以尽量减少缓存时间，但应用程序不一定严格遵守 TTL 值。
DNS 重绑保护: 某些程序 (特别是安全敏感的程序) 可能会开启 DNS 重绑保护 (DNS Rebinding Protection)。当程序识别到 DNS 查询返回的是 私有 IP 地址 (fake-ip 模式通常使用私有 IP 段)，可能会认为发生了 非法的 DNS 劫持，从而 丢弃 DNS 响应 或拒绝连接。这可能导致某些应用无法正常工作，例如 Windows 系统可能显示无网络连接。

解决方案： fake-ip-filter 参数

Clash 提供了 fake-ip-filter 参数，可以配置 虚假 IP 过滤器，用于解决 fake-ip 模式的副作用。

配置示例:

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - dns.msftncsi.com
    - www.msftncsi.com
    - www.msftconnecttest.com

fake-ip-filter 的作用: 配置在 fake-ip-filter 列表中的域名， 不会使用 fake-ip 模式，而是会 Fallback 到真实的 DNS 解析。
解决 Windows 无网络问题: 将微软的网络连接测试域名 (例如 dns.msftncsi.com) 加入 fake-ip-filter，可以避免 Windows 系统误判为无网络连接。

总结： fake-ip 模式是目前 TUN 模式下更推荐的 DNS 处理方式，可以有效避免 DNS 泄露和优化 CDN 节点选择。通过 fake-ip-filter 参数，可以解决一些潜在的兼容性问题。

5. 实操解决 DNS 泄露

讲解了这么多原理，终于到了实操解决问题的阶段。我们的目标是： 既要保证正常上网体验 (国内网站速度不受太大影响)，又要防止 DNS 泄露。

以下方案基于 fake-ip 模式，请确保你的 Clash 配置 enhanced-mode: fake-ip。

5.1 方案一：黑名单 + 自主配置 DNS

核心思路: 利用 fake-ip 模式的特性，结合 域名黑名单 和 自主配置 DNS 服务器，实现 DNS 防泄露和国内网站快速访问。

原理分析:

fake-ip 模式 + DOMAIN 规则: 在 fake-ip 模式下，如果请求匹配了 DOMAIN 规则 (例如 DOMAIN,google.com, 节点1)， Clash 会 直接走代理节点 处理请求， 本地设置的 DNS 完全不会参与。这与系统代理下的行为类似。
域名黑名单: 配置一个 尽可能覆盖国外域名的黑名单 (例如使用 RULE-SET,proxy,节点1 规则， proxy rule-set 通常包含大量国外域名)。确保你想走代理的国外域名都包含在黑名单中。
自主配置 DNS 服务器: 在 Clash 配置文件中，自主配置 nameserver 和 nameserver-policy，用于处理 没有被域名黑名单覆盖到的域名 和 国内域名。

DNS 配置示例:

dns:
  enable: true
  ipv6: false
  listen: 0.0.0.0:53
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - tls://8.8.4.4    # 国外加密 DNS (Google DoT)
    - tls://1.1.1.1    # 国外加密 DNS (Cloudflare DoT)
    prefer-h3: true   # 尝试使用 HTTP/3 (QUIC) 加速 DNS 查询
  nameserver-policy:
    'geosite:cn':      # 国内域名使用以下 DNS 服务器
      - system         # 系统 DNS (通常是运营商 DNS)
      - 223.5.5.5      # 阿里云 DNS
      - 114.114.114.114  # 114 DNS
      - 180.184.1.1    # 字节跳动 DNS
      - 119.29.29.29   # 腾讯 DNS
      - 180.76.76.76   # 百度 DNS
  proxy-server-nameserver: # 解析代理节点 IP 的 DNS 服务器
    - tls://8.8.4.4
  fallback: []          # 禁用 fallback
  fake-ip-filter:       # fake-ip 过滤器
    - dns.msftncsi.com
    - www.msftncsi.com
    - www.msftconnecttest.com

展开

规则配置思路:

域名黑名单规则 (走代理): 使用 RULE-SET,proxy,节点1 或类似的规则，确保常用国外域名走代理。
国内域名直连规则 (可选): 可以使用 RULE-SET,direct,DIRECT 或 GEOIP,CN,DIRECT 等规则，让国内常用域名走直连 (提高速度，节省流量)。但如果主要访问国外网站，国内域名直连规则可以省略，让国内域名也走代理 (速度稍慢，但更安全)。
默认规则 (走代理): 最后添加 MATCH,节点1 规则，作为默认规则，确保所有没有匹配到前面规则的流量都走代理。

方案优点:

DNS 防泄露: 对于被域名黑名单覆盖的国外域名， DNS 查询通过代理节点完成，不会泄露给本地 DNS 服务器。对于没有被黑名单覆盖的国外域名，使用国外加密 DNS 服务器解析，也能避免泄露给国内 DNS 服务器。
国内网站访问速度较快: 国内域名使用国内 DNS 服务器解析 (nameserver-policy 中 geosite:cn 配置)，保证国内网站访问速度。

方案缺点:

域名黑名单可能不完善: 可能存在黑名单没有覆盖到的国外域名，仍然可能使用本地 DNS 服务器解析 (虽然使用了国外加密 DNS，但仍然不如完全走代理安全)。
可能无法通过 Netflix 检测: 如果 Netflix 域名没有被域名黑名单覆盖，可能会使用 nameserver 中配置的国外 DNS 服务器 (例如 8.8.4.4) 解析， Netflix 可能会检测到 DNS 服务器地理位置与代理节点不符，判定使用了代理。

适合人群: 主要访问国内网站，兼顾国外网站访问，对 DNS 泄露有一定要求，但不需要极致安全的用户。

DNS Leak Test 结果示例 (方案一):

可以看到， DNS 服务器 IP 地址都是香港 IP (代理节点所在地)，没有境内 IP，说明 DNS 没有泄露。

5.2 方案二：`no-resolve` + 配置国内域名直连

核心思路: 利用 no-resolve 关键字，结合 国内域名直连规则，实现极致的 DNS 防泄露。

原理分析:

no-resolve 关键字: 将所有 IP 相关规则 (包括 GEOIP, RULE-SET 中包含 IP 规则的) 都加上 no-resolve 关键字。这样，当 Clash 匹配到这些规则时， 不会进行 DNS 解析，也就 不会使用本地 DNS 服务器。
国内域名直连规则: 手动配置国内常用域名的直连规则 (例如 DOMAIN-SUFFIX, baidu.com, DIRECT)，确保国内网站走直连，提高访问速度。

规则配置思路:

国内域名直连规则: 添加国内常用域名的直连规则，例如 DOMAIN-SUFFIX, baidu.com, DIRECT， DOMAIN-SUFFIX, qq.com, DIRECT 等。
IP 相关规则 + no-resolve: 将所有 IP 相关规则 (例如 GEOIP,CN,DIRECT, RULE-SET,cncidr,DIRECT) 都加上 no-resolve 关键字，例如 GEOIP,CN,DIRECT,no-resolve， RULE-SET,cncidr,DIRECT,no-resolve。
默认规则 (走代理): 最后添加 MATCH,节点1 规则，作为默认规则，确保所有没有匹配到前面规则的流量都走代理。

DNS 配置: DNS 配置可以相对简化， nameserver 可以配置为国外加密 DNS， nameserver-policy 可以只保留 geosite:cn 规则，用于国内域名直连时的 DNS 解析。

DNS 配置示例:

dns:
  enable: true
  ipv6: false
  listen: 0.0.0.0:53
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - tls://8.8.4.4    # 国外加密 DNS
    - tls://1.1.1.1    # 国外加密 DNS
    prefer-h3: true
  nameserver-policy:
    'geosite:cn':
      - system
      - 223.5.5.5
      - 114.114.114.114
  proxy-server-nameserver:
    - tls://8.8.4.4
  fallback: []
  fake-ip-filter:
    - dns.msftncsi.com
    - www.msftncsi.com
    - www.msftconnecttest.com

展开

方案优点:

极致 DNS 防泄露: 所有 DNS 查询都通过代理节点或国外 DNS 服务器完成 (除了国内直连域名)， 彻底避免 DNS 泄露。
可以通过 Netflix 等网站检测: 由于所有国外网站的 DNS 查询都通过代理节点完成， Netflix 等网站无法检测到 DNS 泄露问题。

方案缺点:

国内小众网站可能走代理: 如果国内小众网站没有被国内域名直连规则覆盖，可能会走代理，影响访问速度和浪费流量。
配置相对复杂: 需要手动配置国内域名直连规则，并确保所有 IP 相关规则都添加了 no-resolve 关键字。

适合人群: 对 DNS 泄露零容忍，需要通过 Netflix 等网站检测，且主要访问国外网站的用户。

DNS Leak Test 结果示例 (方案二):

可以看到， DNS 服务器 IP 地址都是香港 IP 或台湾 IP (代理节点所在地或附近)，没有境内 IP，说明 DNS 没有泄露，且所有 DNS 查询都通过代理节点完成。

6. 一些其他操作 - 完善 DNS 防护

除了上述两种方案，还有一些其他操作可以进一步完善 DNS 防护，提升隐私安全。

6.1 关闭浏览器的安全 DNS

浏览器的安全 DNS (例如 Chrome 的 “使用安全 DNS”) 功能，会绕过操作系统设置的 DNS 服务器，使用浏览器内置的 DNS 服务器进行 DNS 查询。这可能会干扰 Clash 的 DNS 设置，导致 DNS 泄露。

操作: 在浏览器设置中关闭安全 DNS 功能。

Chrome 浏览器关闭安全 DNS:

6.2 禁用多宿主 DNS 解析

Windows 系统默认使用多宿主 DNS 解析 (Multi-homed Name Resolution, MNR)。 MNR 会使用 **所有可用的网卡** 发起 DNS 查询请求，包括物理网卡和虚拟网卡。开启 TUN 模式后，我们希望所有 DNS 请求都通过 Clash 虚拟网卡， MNR 可能会导致 DNS 请求绕过 Clash，发生 DNS 泄露。

操作: 禁用多宿主 DNS 解析。

方法一：组策略编辑器 (适用于 Windows 专业版及以上):

打开组策略编辑器 (gpedit.msc)。
依次展开：计算机配置 -> 管理模板 -> 网络 -> DNS 客户端。
找到 “关闭多宿主名称解析”，双击打开。
选择 “已启用”，点击 “确定”。

组策略编辑器禁用多宿主 DNS 解析:

方法二：Clash 严格路由 (Strict Route):

Clash 软件本身也提供了一个 “严格路由” (Strict Route) 功能，可以 阻止 Windows 的多宿主 DNS 解析行为，防止 DNS 泄露。

Clash Verge Rev 开启严格路由:

注意： 开启 “严格路由” 可能会导致某些应用程序 (例如 VirtualBo😆 在某些情况下无法正常工作。如果遇到问题，可以尝试关闭 “严格路由” 或只开启 “严格路由” 而不禁用多宿主 DNS 解析。

6.3 WebRTC

WebRTC (网页实时通信) 是一种支持网页浏览器进行实时语音对话或视频对话的 API。 WebRTC 存在一个漏洞，可能会 **泄露用户的真实 IP 地址**，即使使用了代理。

解决方案：使用浏览器扩展程序禁用 WebRTC 或限制 WebRTC 的 IP 泄露。

推荐扩展程序： WebRTC Control

WebRTC Control 浏览器扩展可以 完全禁用 WebRTC 或 只允许 WebRTC 使用代理 IP 地址，防止真实 IP 泄露。

6.4 关掉浏览器的 QUIC 功能

QUIC (快速 UDP 互联网连接) 是一种基于 UDP 协议的网络传输协议。由于 UDP 协议在某些场景下必须使用真实 IP 地址， Clash 在处理 UDP 流量的域名时，即使使用 fake-ip 模式，仍然可能会发起 DNS 请求，导致 DNS 泄露。此外， QUIC 协议可能与部分代理协议不兼容，导致连接不稳定或速度缓慢。

操作：关闭浏览器的 QUIC 功能。

Chrome/Edge 浏览器关闭 QUIC 功能:

在浏览器地址栏输入 chrome://flags/#enable-quic 或 edge://flags/#enable-quic。
找到 “Experimental QUIC protocol” 选项。
将选项设置为 “Disabled”。
重启浏览器使配置生效。

7. TUN 模式的一个小缺陷

开启 TUN 模式后， ping 命令可能无法获取真实的延迟。因为 ping 命令使用 ICMP 协议， ICMP 协议工作在网络层，与 IP 协议同层。 TUN 模式只能接管网络层 IP 协议的流量，无法完全接管 ICMP 流量。因此， ping 命令可能仍然会使用物理网卡发送 ICMP 请求，而不是通过虚拟网卡和代理节点，导致延迟测试结果不准确。

总结： TUN 模式在 DNS 防泄露方面非常强大，但也存在一些小缺陷和需要注意的地方。通过合理的配置和一些辅助操作，可以最大限度地提升 DNS 安全性和上网体验。

希望这份总结能够帮助你彻底理解 DNS 泄露的原理和解决方案！如果有任何疑问，欢迎继续提问。

前言

1. 前置知识 - 理解基础概念

1.1 计算机网络五层结构

1.2 系统代理

1.3 TUN 模式

1.4 DNS 的过程 - 域名解析

2. DNS 泄露 - 隐私泄露的风险

2.1 什么是 DNS 泄露？

2.2 ipleak.net 等检测 DNS 泄露网站的原理

2.3 Netflix 等网站的检测

3. 试图解决 DNS 泄露 (系统代理下)

3.1 方案一：配置好分流规则

3.2 方案二：no-resolve 关键字

4. 透明代理下的 DNS 泄露 (TUN 模式)

4.1 透明代理的概念

4.2 前置知识 - TUN 模式下的 DNS 处理

4.3 redir-host 模式及其问题

4.4 改进后的 redir-host 模式 (fallback 机制)

4.5 redir-host 模式的局限性

4.6 fake-ip 模式 - 更优的解决方案

4.7 fake-ip 模式的一些小问题

5. 实操解决 DNS 泄露

5.1 方案一：黑名单 + 自主配置 DNS

5.2 方案二：no-resolve + 配置国内域名直连

6. 一些其他操作 - 完善 DNS 防护

6.1 关闭浏览器的安全 DNS

6.2 禁用多宿主 DNS 解析

6.3 WebRTC

6.4 关掉浏览器的 QUIC 功能

7. TUN 模式的一个小缺陷

2.2 `ipleak.net` 等检测 DNS 泄露网站的原理

3.2 方案二：`no-resolve` 关键字

4.3 `redir-host` 模式及其问题

4.4 改进后的 `redir-host` 模式 (fallback 机制)

4.5 `redir-host` 模式的局限性

4.6 `fake-ip` 模式 - 更优的解决方案

4.7 `fake-ip` 模式的一些小问题

5.2 方案二：`no-resolve` + 配置国内域名直连