Clash DNS 泄漏检测方法与 fake-ip 防泄漏配置实操

1. DNS 泄漏判断：先确定哪些请求应该走代理

网页出口 IP 已经变成代理地址，DNS 却仍可能交给本地网络。原因很直接：网页连接与域名解析是两条链路。系统代理通常只影响遵循代理设置的应用，并不自动接管系统发往 UDP 53 端口的查询；浏览器还可能使用自己的加密 DNS。

本文把“泄漏”限定为：本应经代理处理的域名查询，意外通过本地直连链路发给解析服务。如果配置本来就要求国内域名使用本地解析，这类直连是预期行为。不要把测试页出现两个解析服务，直接等同于配置失效。

看到的现象	能说明什么	下一步
网页出口属于代理节点	该网页连接走了代理	继续检查 DNS 路径
测试显示本地运营商解析器	存在本地递归解析的可能	核对分流策略及抓包结果
测试显示公共 DNS 提供商	该提供商参与了递归查询	不能仅凭名称判断是否经代理
查询返回 `198.18.x.x`	可能已进入 fake-ip 映射	仍需检查上游查询与连接路由

2. DNS 泄漏检测步骤：基线、对照、抓包

先固定测试条件

记录客户端名称、客户端版本和内核版本。下文配置面向 mihomo；原版 Clash 与较旧内核不一定支持全部字段。
记录当前代理模式、节点、TUN 开关、浏览器安全 DNS 开关。测试期间不要同时更换节点和解析服务。
在同一网络下先关闭代理，运行 DNS 检测并记录解析器名称、IP、网页出口 IP。这份结果作为直连基线。
启用代理后，在检测页发起一轮新的测试。优先使用会生成随机子域名的检测功能，减少缓存影响。
再启用 TUN，重复同样的测试。如果只有 TUN 开启后结果才变化，优先排查系统 DNS 是否原先绕过了内核。

清理缓存，再检查本地监听

Windows 可在终端执行下面的命令。第一条清理系统缓存，第二条直接查询本文配置的本地 DNS 监听端口。浏览器有自己的缓存与连接池，测试时还应完全退出再启动；仅刷新页面不一定触发新的解析。

ipconfig /flushdns
nslookup example.com 127.0.0.1

后面的示例监听 127.0.0.1:1053，而上面的 nslookup 默认查询 53 端口，因此只有在本机另有 53 端口转发时才适用。检查 1053 端口应使用支持指定端口的工具，例如已安装的 dig：

dig @127.0.0.1 -p 1053 example.com A
dig @127.0.0.1 -p 1053 example.com AAAA

如果返回假 IP，说明这一次查询进入了内核 DNS；它不能证明所有应用都使用这个入口。还要看客户端连接记录中目标域名对应的规则与出站策略。

抓包确认本地链路

在实际联网的物理网卡上抓包，过滤 udp.port == 53 || tcp.port == 53，然后重新发起检测。若能看到测试用随机域名被直接发往路由器或运营商 DNS，且它不在预期直连策略中，就有明确的旁路证据。抓包含域名等隐私信息，分享前先脱敏。

DoH 常使用 TCP 443 或 QUIC 443，DoT 通常使用 TCP 853；53 端口没有流量不等于没有 DNS 旁路。加密请求还要结合目标解析服务 IP、进程和客户端连接日志判断。

3. fake-ip、解析策略与 TUN 劫持分别解决什么

机制	实际作用	边界
`fake-ip`	为域名分配假 IP，便于内核还原域名并匹配规则	不自动接管应用自带的 DoH
`nameserver-policy`	按域名选择解析服务	选择解析器不等于指定代理出站
`respect-rules`	让 DNS 上游连接遵循路由规则	规则若命中直连，上游仍会直连
TUN 的 `dns-hijack`	把经过 TUN 的匹配 DNS 流量交给内核处理	不能解密并改写任意 HTTPS 内的 DNS

198.18.0.0/16 是常用的 fake-ip 配置范围，属于用于基准测试的保留地址空间，不是代理节点的真实公网地址。应用访问这些假 IP 时，内核利用映射恢复域名，再进行规则匹配与连接处理。

因此，fake-ip 是域名映射机制，不是“所有 DNS 都走代理”的总开关。可靠配置需要同时确认三个入口：应用把查询交给谁、内核选择哪台解析器、连接这台解析器时走哪条路。

4. mihomo DNS 配置：先建立可验证的基础段

先备份当前配置。下面片段可合并到支持这些字段的 mihomo 配置中，保留原有节点、策略组与规则；不要把它当作完整订阅文件导入。同名 dns: 节只能保留一份，YAML 缩进使用空格。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
  respect-rules: true
  default-nameserver:
    - 223.5.5.5
  proxy-server-nameserver:
    - https://223.5.5.5/dns-query
  nameserver:
    - https://1.1.1.1/dns-query

逐项确认，不要只看配置加载成功

listen 只绑定本机回环地址，避免向局域网开放解析服务。系统网络设置通常不能填写 DNS 端口 1053；需要 TUN 劫持或本地转发才能接入。
ipv6: false 控制内核 DNS 对 AAAA 查询的处理，不是关闭操作系统 IPv6，也不能阻止应用通过其他方式获得 IPv6 地址。
default-nameserver 用于解析 DNS 服务自身的域名。示例保留了明文引导解析入口，因此不能声称所有查询都已加密；使用 IP 形式的 DoH 地址可减少相关引导需求。
proxy-server-nameserver 用于解析代理服务器域名，减少“先连接代理才能解析代理地址”的循环依赖。示例选择独立的 DoH 服务，其可达性仍需在当前网络测试。
respect-rules: true 需要配合可用的代理服务器解析配置。还必须核对 1.1.1.1:443 的连接是否命中预期代理策略；若现有规则把它直连，查询依然没有经过代理。

应用后先看配置检查结果，再看运行日志。如果出现未知字段，先确认实际加载的内核，不要不断往旧内核里增加新字段。客户端可能用界面设置覆盖订阅的 DNS 段，订阅更新也可能覆盖手动修改；应使用客户端提供的持久覆写功能，并检查最终生效配置。

5. nameserver-policy：给局域网域名单独指定解析器

公司内网、家庭 NAS 和路由器管理域名，往往只有本地 DNS 知道。把它们全部交给公共解析服务，结果通常是无法解析，而不是更安全。下面展示明确的分域解析；仅当路由器实际地址是 192.168.1.1，且它提供这些域名的解析时再使用。

  nameserver-policy:
    "+.lan":
      - 192.168.1.1
    "+.home.arpa":
      - 192.168.1.1

把这段放在已有 dns: 下，与 nameserver 同级。此处两格缩进有实际含义。+.lan 匹配该域及其子域，home.arpa 是家庭网络专用域名。不要为了让一个内网服务恢复，就把整个公共域名后缀交给本地解析器。

如果应用需要拿到内网真实地址，还应把对应域加入已有的 fake-ip-filter，例如 "*.home.arpa"。过滤项只改变假 IP 的返回方式，不负责选择解析器，也不自动指定直连路由；局域网网段仍应有正确的直连规则。

测试时先查询内网服务，再查询公共域名。内网查询直连路由器是这份策略的预期结果，不应与公共域名的意外旁路混为一谈。

6. TUN DNS 劫持：覆盖系统查询与不遵循系统代理的应用

只打开系统代理时，部分应用仍会自行发送 DNS 查询。桌面 mihomo 客户端可通过 TUN 扩大接管范围；通常需要服务模式或管理员权限。下面是可与前述 DNS 段配合的基础片段：

tun:
  enable: true
  stack: system
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53

any:53 用于匹配经过 TUN 的 UDP DNS，另一条处理 TCP DNS。关键前提是流量确实进入 TUN：其他 VPN、虚拟机桥接、容器网络、IPv6 路由和应用排除列表，都可能形成另一条路径。某些系统对本地网络 DNS 的接管还存在平台限制，必须以实际抓包为准。

浏览器安全 DNS 单独测试

Chrome 可在「设置」→「隐私和安全」→「安全」→「使用安全 DNS」检查当前选项；不同版本文案可能稍有变化。排查时先关闭该选项，让浏览器使用系统解析，再验证 TUN。随后重新开启，检查浏览器连接解析服务时是否仍命中预期代理规则。

这不是要求长期关闭加密 DNS。目的是隔离变量：应用自带的 DoH 是普通加密网络连接，不会因为配置了 53 端口劫持就被自动替换。Android 的「私人 DNS」也需要单独核对；其入口通常位于「设置」→「网络和互联网」→「私人 DNS」，厂商系统可能调整位置。

7. 常见故障与最终验收清单

开启 fake-ip 后，打印机或 NAS 无法访问

先确认内网域名由谁解析，再补充精确的 nameserver-policy 和必要的 fake-ip 过滤项。mDNS 使用 UDP 5353，和普通单播 DNS 不是同一机制；仅添加 53 端口劫持不会解决所有 .local 发现问题。

开启 respect-rules 后，节点域名解析超时

先检查 proxy-server-nameserver 的连通性，以及连接该解析服务是否又依赖尚未解析成功的代理。必要时回退到备份，先恢复独立可用的节点域名解析路径，再逐步收紧 DNS 出站规则。不要把故障直接归因于节点失效。

检测结果没有变化

按“实际生效配置 → DNS 缓存 → 浏览器 DoH → TUN 路由 → 规则命中”顺序排查。若日志中根本没有本次测试域名的记录，优先查入口；若已有查询但出站是直连，查规则；若出站符合预期，仅地理标记不同，查解析服务的任播与转发情况。

公共测试域名：新查询进入内核，解析服务连接命中预期出站。
本地物理网卡：没有发现违背策略的明文测试域名查询。
浏览器与系统：分别测试安全 DNS 开关，不靠单一网页结果下结论。
局域网服务：路由器、NAS、打印机保持可用，预期直连域名有明确例外。
持久性：重启客户端、更新订阅后再次测试，确认覆写仍生效。

验收标准不是“检测页只剩一行”，而是每一类查询都有可解释的入口、解析器和出站路径。先让路径可见，再减少不必要的例外；配置越容易复核，下一次网络变化就越容易定位。