Clash Fake-IP 模式原理：DNS 映射流程、适用场景与排除规则

Fake-IP 是 Clash 与 mihomo 常用的增强 DNS 处理方式。它不会把域名查询结果直接替换成目标服务器的公网地址，而是先从一段专用地址范围中分配虚拟地址，并在内核中保存“域名—虚拟地址”的对应关系。应用随后连接这个虚拟地址时，Clash 根据映射还原域名，再执行域名规则、策略组选择和远端解析。

这种方式的重点不是改变目标网站，而是让流量入口保留准确的域名信息。对于经过 TUN 虚拟网卡接管、只向操作系统提交 IP 连接的程序，Fake-IP 可以把先前 DNS 查询得到的域名重新关联到连接。规则引擎因此更容易命中 DOMAIN、DOMAIN-SUFFIX、规则集合等域名规则，也能减少本地 DNS 结果与代理出口实际访问结果不一致的问题。

Fake-IP 的 DNS 映射流程

一次典型访问可以拆成 DNS 查询和连接建立两个阶段。理解这两个阶段，才能判断异常发生在域名解析、流量接管、规则匹配还是代理出口。

1. 应用向系统 DNS 发起域名查询，例如请求某个服务的 A 记录或 AAAA 记录。
2. 系统查询被送到 Clash 的 DNS 模块。使用 TUN 时，常见做法是通过 dns-hijack 接收指定端口上的 DNS 请求；使用其他接管方式时，也可能由操作系统 DNS 设置直接指向本地监听地址。
3. Fake-IP 模块为域名分配一个虚拟地址，并记录映射关系。常见地址池位于基准测试用途保留网段中，实际范围由 fake-ip-range 决定。
4. 应用拿到虚拟地址后发起 TCP 或 UDP 连接。该连接必须继续进入 Clash；如果流量绕开 Clash，虚拟地址本身不能直接在公网建立连接。
5. Clash 根据目标虚拟地址查回原始域名，将域名交给规则引擎，并选择直连、代理、拒绝或指定策略组。
6. 需要建立真实连接时，Clash 按配置使用上游 DNS、代理侧解析或目标协议所需的解析方式取得真实地址。

因此，Fake-IP 并不是一个独立代理模式。它依赖 DNS 请求和后续连接都被同一套 Clash 实例接收。DNS 查询进入 Clash、连接却绕过 TUN，或者连接进入 Clash、DNS 查询却由其他程序截获，都会破坏映射链路。排查时要把“DNS 是否经过 Clash”和“目标连接是否经过 Clash”分开检查。

域名规则的匹配通常发生在映射还原之后。比如规则中存在某个域名后缀，Clash 可以直接使用还原后的主机名进行判断，不必先把它当作普通公网 IP 交给 IP 规则。对于直接输入 IP 地址的连接，因为没有前置域名查询，也就没有 Fake-IP 映射，规则仍会按 IP、端口和其他可用信息处理。

mihomo 中的基础配置与字段关系

不同客户端会用图形开关生成配置，也可能通过订阅覆写写入 DNS 段。最终应以客户端实际加载的配置为准。下面是一组用于理解字段关系的简化示例，监听地址、上游 DNS 和地址池应根据设备环境调整。

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "time.*.com"
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

tun:
  enable: true
  stack: mixed
  dns-hijack:
    - any:53

enhanced-mode: fake-ip 用于选择 Fake-IP 增强模式；fake-ip-range 定义虚拟地址池；fake-ip-filter 列出不应返回虚拟地址的域名。命中过滤项后，DNS 模块会为这些域名返回真实解析结果，而不是建立 Fake-IP 映射。

dns-hijack 与 Fake-IP 的职责不同。前者负责让设备上的 DNS 请求进入 Clash，后者负责决定进入后的回答方式。只开启 Fake-IP 但没有让查询到达 Clash，配置不会作用于那些绕行的 DNS 请求；只配置 DNS 劫持但仍使用普通解析模式，也不会产生虚拟地址映射。

在 mihomo 中，Fake-IP 映射默认主要用于运行期间的连接关联。部分配置可以在 profile 中启用 Fake-IP 数据持久化，使核心重启后继续使用已保存的映射。是否需要持久化取决于客户端的配置管理方式。遇到地址池调整、历史映射异常或配置切换后行为不一致时，可以关闭核心后清理客户端提供的 DNS/Fake-IP 缓存，再重新加载配置。

适合使用 Fake-IP 的场景

桌面设备上的 TUN 全流量接管

TUN 会创建虚拟网络接口，接收没有遵循系统 HTTP 代理设置的 TCP、UDP 和部分系统服务流量。许多程序在建立连接时只向网络栈提交解析后的 IP，规则引擎未必能从连接本身获得域名。Fake-IP 通过前一次 DNS 查询补回域名信息，因此与 TUN 配合较为直接。

浏览器、命令行工具、游戏平台和后台更新服务可能使用不同网络接口与代理机制。统一让 DNS 查询和连接经过 TUN，可减少某个程序遵循系统代理、另一个程序绕过系统代理造成的分流差异。启用后仍应检查路由表、DNS 劫持和客户端日志，确认不是只有浏览器流量生效。

依赖域名规则的大型规则集

订阅配置经常包含大量域名后缀、域名关键字和规则集合。使用 Fake-IP 后，核心可以在连接到达时恢复查询域名，并优先执行这些规则。域名规则比单纯按服务器 IP 判断更稳定，因为同一服务可能使用 CDN、动态调度或共享地址，一个公网 IP 也可能承载多个完全不同的域名。

如果某条规则希望直连局域网服务、代理公开站点或拒绝特定域名，Fake-IP 能让规则目标更明确。不过，规则顺序仍然有效。较宽泛的规则放在前面，仍可能覆盖后面的精确域名规则；Fake-IP 只提供匹配信息，不会自动修正规则优先级。

希望减少本地解析差异的代理连接

普通 DNS 模式往往先在本地取得真实 IP，再让规则引擎根据域名或 IP 做决定。若代理出口与本地网络得到的 CDN 地址不同，可能出现线路绕行或连接结果不一致。Fake-IP 可以延后真实目标地址的确定，让核心按策略和上游设置选择解析路径，适合需要域名分流并由代理侧完成后续连接的环境。

局域网、游戏与特殊域名的常见问题

局域网主机名和设备发现

打印机、NAS、电视投屏和路由器管理页经常使用 .local、.lan 或厂商自定义主机名。部分名称由 mDNS、LLMNR、路由器本地域名服务或搜索域完成解析，并不适合交给公共上游 DNS。若这些名称收到 Fake-IP，应用可能无法完成同网段发现，或者把本应直连的管理请求交给代理规则。

处理顺序应是先确认名称由哪种协议解析，再增加精确排除项。对于固定设备，可以优先保留 DHCP 主机名解析或使用明确的局域网域名后缀。仅将需要本地解析的后缀加入 fake-ip-filter，同时确保局域网 IP 段有直连规则。单独排除域名但没有直连路由，仍可能在连接阶段选错策略。

游戏登录、语音和 UDP 会话

部分游戏同时使用账号登录域名、内容下载域名、对战服务器 IP、语音 UDP 和 NAT 探测服务。登录网页正常不代表整个游戏链路都正常。若启动器查询域名后把结果交给独立进程，而后续进程未被同一个 TUN 接管，虚拟地址就可能失去对应的转发入口。

出现登录循环、区服列表空白或语音连接失败时，应先查看核心日志中是否能看到对应 UDP/TCP 连接，再确认进程是否进入 TUN。只有在日志证明某个域名不适合 Fake-IP 时，才把该域名加入过滤列表。游戏通常会使用多个服务域名，直接排除整个顶级域或关闭全部 Fake-IP，容易让原有域名分流失效。

时间同步、网络检测和强制门户

系统时间同步、网络连通性检测、校园或酒店的登录门户可能期待真实 DNS 结果，或者在代理核心启动前就需要完成访问。此类请求若收到虚拟地址，但连接尚未进入 Clash，系统可能误判为离线。时间同步域名、操作系统网络探测域名以及门户认证使用的域名，都是排除规则的常见候选。

排除项应来自实际日志和抓取结果，而不是照抄很长的通用清单。操作系统版本、地区和网络环境不同，检测域名也会变化。先复现问题，记录查询域名，再添加最小范围规则，能够避免把普通业务流量一并改回真实 IP。

IP 地址写入配置或由其他设备复用

某些程序会长期缓存 DNS 结果，甚至把获得的地址写入配置文件。Fake-IP 只在掌握映射的 Clash 实例中有效，这个地址复制到另一台设备后没有意义。旁路由环境也要特别注意：如果 DNS 由旁路由 A 返回虚拟地址，实际连接却经过网关 B，网关 B 无法知道该虚拟地址对应哪个域名。

同一局域网为多台设备提供 Fake-IP DNS 时，应让这些设备的后续流量稳定经过同一个核心实例，并保证虚拟地址池路由指向该实例。否则更适合使用返回真实地址的 DNS 模式，或仅让本机客户端使用 Fake-IP。

如何编写 Fake-IP 排除规则

排除规则的目标是让少数不兼容域名返回真实地址，而不是建立一份覆盖全部服务的例外表。可按“精确域名、有限通配、后缀范围”的顺序逐步扩大。

mihomo 的具体匹配能力会随版本与配置格式变化，客户端也可能在合并订阅和覆写时改变字段。修改后应打开客户端的最终配置视图，确认 fake-ip-filter 没有被订阅更新覆盖，并查看核心启动日志是否报告字段错误。

部分新版 mihomo 配置支持为 Fake-IP 过滤设置黑名单或白名单逻辑。黑名单方式表示列表内域名使用真实解析，其他域名使用 Fake-IP；白名单方式则反过来，只让列表命中的域名使用 Fake-IP。日常桌面环境通常更适合从少量排除项开始。若启用白名单，应确保未命中的大量域名返回真实地址是有意设计，而不是字段含义理解相反。

Fake-IP 异常排查顺序

1. 确认配置已加载。在客户端运行配置中核对 DNS 已启用、增强模式为 Fake-IP，并检查核心启动日志。订阅文件、覆写文件和客户端开关可能同时修改 DNS 段。
2. 确认 DNS 查询进入核心。观察连接日志或 DNS 日志，检查目标域名是否出现。若系统启用了加密 DNS、浏览器独立 DNS 或其他 DNS 工具，请确认它们是否绕过本地监听。
3. 确认虚拟地址属于设定地址池。查询结果应落在 fake-ip-range 中。若仍返回普通公网 IP，可能命中过滤项，也可能查询未经过 Clash。
4. 确认后续连接也被接管。应用拿到虚拟地址后，日志中应出现对应连接。完全没有连接记录时，优先检查 TUN 权限、系统路由和应用绕行设置。
5. 检查映射能否还原域名。连接日志应显示原始域名或命中域名规则。若只显示虚拟 IP，尝试清理 DNS 与 Fake-IP 缓存，并确认查询和连接由同一个核心处理。
6. 检查规则顺序与策略组。域名已恢复但出口错误时，问题通常位于规则优先级、规则集合更新或策略组选择，而不是 Fake-IP 本身。
7. 最后添加排除项。只有确认目标服务确实要求真实 DNS 结果后，再把精确域名加入过滤列表。

修改 DNS 配置后，浏览器、操作系统和应用可能继续使用旧缓存。应先重载 Clash 配置，再清理系统 DNS 缓存并完全退出相关应用。若客户端提供“清理 DNS 缓存”或“刷新 Fake-IP 缓存”入口，可在停止相关连接后执行。频繁切换多个核心实例时，还要确认系统 DNS 和默认路由已经指向当前实例。

Fake-IP 与 Redir-Host 的选择

Fake-IP 强调通过虚拟地址保留域名映射，适合 TUN 接管、域名规则较多并且 DNS 与连接路径可统一控制的设备。Redir-Host 一类返回真实地址的模式更接近常规 DNS 行为，对需要真实地址的局域网服务、跨设备 DNS 和部分特殊应用更容易兼容，但域名关联与解析路径会受客户端实现和连接类型影响。

选择时不要只比较某个网页能否打开。应同时检查浏览器、系统更新、局域网设备、游戏 UDP、休眠恢复和网络切换。单机桌面设备通常可以先使用 Fake-IP，再针对明确异常建立小范围过滤；由路由器为多台设备统一提供服务时，应先设计 DNS 请求与回程流量路径，确保虚拟地址始终回到同一实例。

最终判断标准是链路是否完整：DNS 查询进入 Clash，虚拟地址由当前核心分配，后续连接再次进入同一核心，域名规则正确命中，策略组能够建立真实连接。只要按这个顺序观察日志，Fake-IP 问题通常可以定位到具体环节，而不需要反复切换全部 DNS 配置。