在 Clash Meta（mihomo）配置中，DNS 模式会直接影响域名解析、规则匹配和连接建立。Fake-IP 是其中较常见的一种工作方式：客户端不把目标域名立即解析成真实公网地址，而是为域名分配一个来自专用地址池的虚拟 IP，并在内部保存域名与虚拟 IP 的对应关系。应用看到的是这个虚拟地址，代理内核则可以在后续连接阶段恢复原始域名，再根据规则决定直连、代理或拒绝。

这套流程常与 TUN 模式一起使用，但两者不是同一个概念。Fake-IP 解决的是 DNS 响应和域名保留问题，TUN 解决的是如何接收系统及应用产生的网络流量。理解二者的边界，才能判断故障究竟发生在 DNS、规则、路由，还是应用本身。本文按解析流程、配置选择、应用场景和排错顺序展开说明。

Fake-IP 到底改变了什么

传统的 redir-host 思路通常是：应用向系统解析器查询域名，解析器返回真实 IP，应用再使用这个 IP 建立连接。代理内核如果只看到目标 IP，便需要依赖域名嗅探、规则补充或已知地址段来推断访问对象。对于 HTTPS 流量，内核可能从 TLS 的 SNI 中得到域名；对于部分加密或非标准协议，这种推断并不一定成立。

Fake-IP 模式将顺序调整为“先保留域名，再建立连接”。当应用查询 example.com 时，DNS 模块返回地址池中的一个虚拟地址，例如 198.18.0.23。这个地址并不是目标服务器的真实地址，而是内核用于标记该域名的索引。应用随后连接 198.18.0.23，流量被代理接管后，内核通过映射表还原出 example.com，再执行域名规则。

常见的 Fake-IP 地址池会使用专门保留的测试网段，例如 198.18.0.1/16。这类地址不应被当作公网目标使用。地址池大小、排除列表和映射生命周期由内核及配置共同决定。虚拟 IP 与域名的对应关系通常会在缓存中维护，因此同一域名在一段时间内可能持续得到相同地址，也可能在缓存清理、配置重载或地址池变化后重新分配。

一次请求的处理链路

  1. 应用发起 DNS 查询，查询内容是域名而非最终 IP。
  2. Clash 接收查询，根据 nameserver、fallback、fake-ip-filter 等设置处理请求。
  3. Fake-IP 模块为域名建立映射，并向应用返回地址池内的虚拟 IP。
  4. 应用连接虚拟 IP；系统代理、透明代理或 TUN 将这条连接交给 Clash。
  5. Clash 根据映射恢复域名，依次执行域名规则、进程规则、IP 规则和兜底规则。
  6. 选定策略组后，内核通过直连或代理线路连接真实目标。

这里的关键点是“规则看到的目标”。在映射有效且流量经过 Clash 的情况下，域名规则通常能够在连接早期发挥作用。若应用绕过了系统 DNS、直接使用硬编码 IP，或者流量没有进入 Clash，Fake-IP 并不能凭空恢复域名，也不能替代路由接管。

Fake-IP、真实解析与 TUN 模式的关系

Fake-IP 与 redir-host 是 DNS 返回策略的两种取向。Fake-IP 更强调保留域名上下文，适合需要稳定域名规则匹配的场景；redir-host 更接近普通 DNS 的直觉，应用得到真实 IP，部分依赖真实地址的程序兼容性会更好。两种模式都需要正确的 DNS 劫持、系统代理或流量接管，不能简单理解为某一种模式一定更快。

TUN 模式则位于另一层。启用 TUN 后，系统会创建虚拟网络接口，符合路由条件的流量被送入 Clash。这样可以接管不遵循 HTTP 或 SOCKS 系统代理的程序，也能覆盖部分后台服务和 UDP 流量。TUN 开启并不意味着 DNS 自动正确：如果系统仍把查询发送到外部 DNS，或者应用启用了自己的加密 DNS，Fake-IP 映射可能无法参与整个请求链路。

组件 主要职责 常见误解
Fake-IP 为域名分配虚拟地址并保留映射 不是一个远端 DNS 服务器，也不是代理节点
DNS 模块 接收查询、选择解析器并返回结果 只改 nameserver 就能解决所有 DNS 泄漏问题
TUN 接管系统路由中的网络流量 开启 TUN 后所有应用必然走代理
规则系统 根据域名、IP、端口等条件选择策略 规则不能处理完全没有进入内核的连接

在桌面端，系统代理通常足以覆盖浏览器和遵循系统设置的应用；在需要覆盖更多程序时，可以考虑 TUN。Android 上，VpnService 是常见的流量接管基础，系统 VPN 权限、省电策略和其他 VPN 应用状态都会影响结果。iOS 的网络扩展权限和客户端能力也有自身限制，不应直接套用桌面端的 TUN 配置。

配置 Fake-IP 时应先确认的项目

配置文件的字段名称和可用选项应以当前 mihomo 版本文档及客户端界面为准。不同客户端可能对 DNS、TUN 和覆写配置提供不同的编辑入口。下面给出检查思路，而不是要求所有平台复制一份完全相同的配置。

1. 明确 DNS 请求由谁接收

首先确认客户端是否启用了内核 DNS，以及系统 DNS 查询是否会被转发到 Clash。桌面客户端可能通过本地监听地址接收查询，TUN 客户端可能通过 DNS 劫持处理 UDP 或 TCP 查询。若浏览器启用了“安全 DNS”并直接连接指定服务商，系统 DNS 的设置可能不会生效。测试时应暂时关闭应用自带的加密 DNS，或者把它纳入明确的网络策略。

2. 规划 Fake-IP 地址池

地址池应使用适合虚拟映射的保留网段，并避开实际局域网、公司内网、容器网络和常用 VPN 网段。比如局域网使用 192.168.1.0/24 时，不要把 Fake-IP 地址池设成同一网段。地址冲突会导致系统把虚拟地址误认为局域网主机，表现为连接超时、路由异常或某些内网服务无法访问。

Fake-IP 地址池不宜随意设置为常见家庭网段。配置前可检查当前设备的路由表、Docker 网桥、虚拟机网卡和公司 VPN 使用的网段。如果地址池与真实网络重叠，优先更换地址池，再清理缓存并重新测试，而不是反复切换代理节点。

3. 设置 fake-ip-filter

并非所有域名都适合返回 Fake-IP。局域网主机名、路由器管理地址、需要真实 IP 判断的服务，以及某些依赖本地解析的域名，通常应加入排除列表。过滤后，这些域名会走真实解析或按客户端实现返回原始结果。过滤范围不宜一开始就写得过大，否则大量域名回到真实解析，规则匹配和 DNS 行为会变得难以判断。

过滤列表应根据实际故障增加，并记录每次修改的目的。例如，打印机发现失败可以先检查局域网域名和多播名称解析；某个企业内网域名打不开，可以检查企业 DNS 是否必须在特定网络中使用。不要把整个顶级域名或所有国内域名都排除，只因为某一次请求失败。

4. 检查 nameserver 与 fallback 的分工

nameserver 是常规解析器，fallback 是备用解析器或用于特定判断的解析来源，具体行为取决于内核版本和配置。配置解析器时要关注可达性、响应速度、是否支持需要的记录类型，以及请求是否应通过代理发送。解析器本身不可达时，Fake-IP 仍可能返回缓存结果，但新域名会出现解析等待或连接失败。

如果配置了 nameserver-policy，应确认规则写法和域名范围准确。策略的目标是让不同域名使用合适的解析器，不是替代代理规则。DNS 解析成功也不代表目标连接一定成功，最终还要看规则命中的策略组、节点可用性和远端服务响应。

哪些场景适合使用 Fake-IP

当配置依赖域名规则分流时，Fake-IP 通常更容易保持规则上下文。例如需要按域名后缀区分直连和代理、需要对一组服务使用独立策略组，或希望减少仅凭目标 IP 判断造成的误分流。域名在连接早期仍然可用，规则维护也更接近用户实际看到的站点名称。

在 TUN 模式下，Fake-IP 对不遵循系统代理的程序尤其有帮助。程序只要通过系统网络栈发出 DNS 查询并连接返回地址，内核就有机会根据映射识别目标。不过，程序使用自定义 DNS、DoH、DoT，或把域名解析结果固定在自身缓存中时，仍需要单独处理。某些应用还会使用 QUIC、IPv6 或自有网络协议，测试时应把协议差异纳入判断。

对于局域网设备，Fake-IP 应保持谨慎。打印机、NAS、智能家居控制器、路由器后台和局域网游戏发现通常依赖真实局域网地址、多播或广播，这些流量不一定适合经过代理。将相关域名加入 fake-ip-filter，并为局域网网段设置直连规则，是更稳妥的起点。

常见异常与排错顺序

浏览器显示 DNS_PROBE_FINISHED_NXDOMAIN 或解析超时

先确认问题是所有域名都发生，还是只有某个域名发生。检查 Clash 日志中是否出现 DNS 请求，查看客户端 DNS 监听是否启动，再确认系统或浏览器是否绕过了该监听。随后临时切换到可访问的解析器，清理客户端 DNS 缓存并重新加载配置。如果只有一个域名失败，检查 nameserver-policy、域名拼写、过滤列表和该域名的记录类型。

网页能打开，但规则命中直连或代理错误

查看连接详情中的目标域名、目标 IP 和命中规则。若连接详情只显示 Fake-IP 地址，说明映射没有被正确恢复，可能是连接没有从 Clash 接收，或者应用使用了缓存 IP。若显示真实域名但规则不符合预期，检查规则顺序：更具体的 DOMAIN、DOMAIN-SUFFIX 或 DOMAIN-KEYWORD 应放在更宽泛的规则之前，MATCH 兜底项应位于规则末尾。

规则修改后要保存并执行配置重载。只编辑文件但没有重载时，运行中的内核仍可能使用旧规则。测试应使用新的连接，旧连接和旧缓存不一定会重新走完整的解析与匹配流程。

开启 TUN 后局域网设备或公司内网失效

先关闭 TUN 进行对照测试。如果关闭后恢复，检查 TUN 的路由设置、自动路由、严格路由、DNS 劫持和绕过网段配置。确认家庭路由器、公司内网、打印机所在网段没有被错误送往代理策略。对局域网流量，应确保规则和路由都允许直连；只写一条 IP-CIDR 规则而没有让流量进入内核，仍不能解决问题。

多个 VPN、虚拟机、容器和安全软件可能同时修改路由表。排错时应暂时停用不必要的 VPN 或虚拟网卡，记录启用 TUN 前后的默认路由和 DNS 服务器。Windows、Linux、Android 的权限模型不同，客户端显示“已启用”不代表系统一定授予了全部所需权限。

部分应用完全无法联网

检查应用是否使用 IPv6、QUIC、硬编码 IP、内置 DoH 或独立代理。Fake-IP 主要围绕域名解析建立映射，直接使用 IP 的连接可能只能依靠 IP 规则处理。若应用优先使用 IPv6，而当前 TUN、节点或规则未覆盖 IPv6，可能出现浏览器正常、单个应用失败的情况。可以在测试阶段分别验证 IPv4、IPv6、TCP 和 UDP，再决定是否调整协议或路由范围。

# 仅用于排查思路，实际字段请按当前客户端和 mihomo 版本确认
dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"

tun:
  enable: true
  auto-route: true
  dns-hijack:
    - any:53

上面的片段只展示字段之间的关系，不代表所有系统都应原样使用。dns-hijack、TUN 路由和过滤项可能受到客户端封装及版本差异影响。尤其是局域网域名、企业 DNS 和 IPv6 环境，应先了解现有网络，再逐项加入配置。

一套可重复的检查清单

  1. 记录当前客户端版本、内核版本、系统版本和网络环境，保留原配置。
  2. 关闭其他 VPN、代理软件和浏览器独立 DNS，建立单一变量的测试环境。
  3. 确认普通域名能获得解析结果，观察 Clash 是否出现对应 DNS 请求。
  4. 检查返回地址是否属于 Fake-IP 地址池，并确认该地址池没有与局域网重叠。
  5. 查看连接详情，确认映射能恢复域名，并核对实际命中的规则和策略组。
  6. 分别测试普通网页、局域网设备、需要登录的应用、UDP 服务和 IPv6 服务。
  7. 每次只修改一个项目，保存、重载、清理缓存后再重复同一组测试。

如果切换到 redir-host 后某个应用恢复，说明该应用可能依赖真实 IP、局域网解析或特殊协议；这并不自动证明 Fake-IP 配置错误。可以先把具体域名加入过滤列表，或为该应用的流量设置明确的直连策略。反过来，如果 redir-host 下域名规则容易失效，而 Fake-IP 下规则稳定，则应优先检查 DNS 劫持和映射回收，而不是只更换节点。

结语：按请求链路定位问题

Fake-IP 的价值在于让域名信息贯穿 DNS、连接接管和规则匹配。它不是单独的加速开关，也不能替代可用的解析器、正确的路由和有效的代理策略。配置是否适合，取决于设备类型、应用协议、局域网结构以及是否需要 TUN 接管。

遇到异常时，按照“应用查询 DNS—Clash 返回地址—流量进入内核—映射恢复域名—规则选择策略—节点建立连接”的顺序检查，通常比反复切换 DNS 或节点更快定位原因。对局域网、企业内网和特殊应用保留明确的例外处理，再用日志和连接详情验证每次修改，能够让 Fake-IP 配置保持可维护。