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

在 Clash、Clash Meta 与其后续维护分支 mihomo 的 DNS 配置中，Fake-IP 是一个容易被误解的选项。它返回的地址看起来像真实 IP，但这个地址的主要用途不是直接代表远端服务器，而是让内核在接管连接时重新找回原始域名。理解这一点，才能判断某个连接失败究竟来自 DNS、规则、代理节点，还是应用本身的网络行为。

Fake-IP 特别适合以域名规则为主的配置，也经常与 TUN 模式一起使用。它能减少应用提前解析域名造成的规则信息丢失，但并非所有设备、协议和局域网名称都适合接收映射地址。正确做法不是盲目扩大排除列表，而是先看清查询与连接经过了哪些环节，再针对确实依赖真实地址的目标设置过滤项。

Fake-IP 解决的核心问题

普通 DNS 查询会把域名解析成真实 IP。应用随后连接这个 IP 时，如果代理内核只看到目标地址，原始域名可能已经不在连接信息里。此时，诸如 DOMAIN-SUFFIX、DOMAIN-KEYWORD 和特定域名规则就难以直接参与匹配，只能退回 IP、GeoIP 或兜底规则。对于同一 IP 承载多个站点的内容分发网络，这种退化尤其明显。

Fake-IP 的思路是由 Clash 内置 DNS 接收查询，为域名分配一个临时映射地址，并保存“域名—映射地址”的对应关系。应用拿到这个地址后发起连接，流量再次进入内核；内核依据映射表识别原始域名，然后按域名规则选取策略。实际访问远端时，内核仍会根据配置查询可用的真实地址，并通过直连或选定代理建立连接。

许多配置使用 198.18.0.1/16 作为默认地址池。该网段保留用于基准测试场景，通常不会在公网路由。内核利用这种不应被公开互联网使用的地址范围建立映射，可以降低它与正常公网目标冲突的概率。若本地实验网络已经使用相同网段，则需要调整地址池，避免路由判断互相覆盖。

Fake-IP 与 Redir-Host 的差别

redir-host 模式通常向应用返回真实解析结果，连接目标更接近传统网络行为。它对部分依赖真实 IP 的程序更直观，但域名规则能否准确命中，会受到流量入口、嗅探能力和应用解析路径影响。Fake-IP 则通过映射关系主动保留域名上下文，更适合需要细粒度域名分流的配置。

比较项	Fake-IP	Redir-Host
返回给应用的地址	地址池中的映射地址	上游 DNS 的真实结果
保留域名信息	依赖内核映射表，路径明确	依赖入口、嗅探或其他上下文
域名规则匹配	通常更稳定	可能提前变为 IP 匹配
特殊设备兼容	可能需要排除项	更接近常规 DNS 行为

从 DNS 查询到规则匹配的完整流程

排查 Fake-IP 问题时，不能只看一次 DNS 查询。完整路径至少包含应用发起查询、内置 DNS 应答、应用连接映射地址、内核恢复域名、规则匹配以及上游解析六个环节。任一环节绕开 Clash，都可能让结果与预期不同。

应用查询域名。浏览器、游戏客户端或系统服务向所配置的 DNS 地址查询 A 或 AAAA 记录。若查询没有进入 Clash 内置 DNS，Fake-IP 配置不会参与。
内核检查排除规则。域名若命中 fake-ip-filter，内核会返回真实解析结果；未命中时继续分配映射地址。
生成或读取映射。内核从 Fake-IP 地址池取出地址，并把该地址与原始域名关联。重复查询可能复用已有映射，具体生命周期由内核缓存管理。
应用发起连接。应用把映射地址当成目标建立 TCP 或 UDP 会话。系统代理模式和 TUN 模式的接管路径不同，但关键是连接必须再次进入 Clash。
恢复目标域名。内核读取映射表，把目标还原为查询时的域名，并用它执行规则匹配。
选择策略与解析路径。规则决定走直连、代理或某个策略组。需要实际连接时，再按 DNS 配置获得远端真实地址。

这套机制也解释了一个常见现象：命令行执行 nslookup 时看到映射地址，并不代表访问已经通过代理。DNS 应答只完成了映射阶段，最终使用哪个策略仍由后续连接和规则决定。反过来，如果应用使用内置 DoH、固定 IP 或自己的 DNS 通道，系统查询可能完全没有出现，Fake-IP 也就无法凭空获得域名。

系统代理与 TUN 模式中的区别

在系统代理模式下，遵循代理设置的 HTTP 或 SOCKS 应用可以直接把域名交给代理端处理，部分场景并不依赖 Fake-IP。无法读取系统代理设置的应用则可能直连，除非另有透明接管方案。TUN 模式从虚拟网卡层接收更多系统流量，因此常与 DNS 劫持、Fake-IP 和路由配置组合使用。

TUN 并不意味着所有 DNS 都会自动进入内核。操作系统可能使用加密 DNS，浏览器也可能启用独立的安全 DNS。配置时应确认 DNS 劫持范围、监听端口、局域网共享方式和系统防火墙状态。若查询走外部 DNS，而连接却被 TUN 接管，内核看到的通常是真实 IP，域名规则可能依赖嗅探才能恢复。

mihomo 中的基础配置方法

下面是一段用于理解字段关系的简化示例。实际客户端可能通过图形界面生成部分字段，也可能把用户覆写与订阅内容合并。修改前应保留原始配置，并在客户端日志中确认当前加载的是哪一份文件。

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"
    - "localhost"
    - "time.*.com"
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://1.1.1.1/dns-query

enable 控制内置 DNS，enhanced-mode 选择增强模式，fake-ip-range 定义映射地址池，fake-ip-filter 决定哪些域名返回真实结果。nameserver 是主要上游解析器；default-nameserver 常用于解析 DoH、DoT 等上游服务器自身的域名，因此一般需要填写可直接访问的 IP 地址形式解析器。

配置格式会随内核版本与客户端封装方式变化。mihomo 支持较丰富的 DNS 字段和规则表达能力，但旧版 Clash 客户端未必识别所有新字段。若订阅在多个客户端之间使用，应先确认各客户端绑定的内核及版本，不要因为某个界面能保存字段，就默认运行中的内核已经采用它。

DNS 上游与分流的关系

上游 DNS 的选择会影响真实地址获取、污染规避和连接延迟，但它与代理规则不是同一层。某个域名由境外 DoH 解析，不代表连接一定走代理；同样，使用本地 DNS 解析也不等于该连接一定直连。最终策略仍取决于规则顺序和匹配结果。

部分 mihomo 配置还会使用 nameserver-policy，按域名规则指定不同上游。例如让局域网或特定区域域名使用本地解析器，让其他域名使用加密解析器。此功能适合明确掌握解析需求的配置，规则过多时则会增加排查难度。遇到问题应先缩减到单一可用上游，确认 Fake-IP 流程正常后再恢复分流。

适用场景与不宜直接套用的环境

适合以域名规则为主的订阅

许多订阅规则以域名后缀、关键词和规则集为主体。Fake-IP 可以让连接在进入规则引擎时保留域名，减少同一 CDN 地址承载多个服务时的误判。对于浏览器、桌面应用和移动应用混合使用的设备，这种行为通常比单纯依靠目标 IP 更可预测。

适合 TUN 接管的桌面环境

有些应用不读取系统代理，还有些程序同时使用 TCP 与 UDP。TUN 模式能够接管更广泛的流量，Fake-IP 则帮助内核把 DNS 查询与后续连接关联起来。两者配合时，应把“查询是否进入内置 DNS”和“连接是否经过 TUN”作为两个独立项目检查，不能只看到 TUN 已启动就认为 DNS 路径正确。

局域网网关需要更谨慎

当 Clash 或 mihomo 部署在路由器、旁路网关或家庭服务器上时，客户端设备可能把网关当作 DNS，也可能继续使用运营商 DNS、路由器下发的 IPv6 DNS 或应用内置 DoH。网关若向整个局域网返回 Fake-IP，就必须保证这些映射连接都能回到同一内核；否则客户端会尝试把映射地址直接发往其他路由，最终表现为连接超时。

局域网设备发现、打印机、NAS、智能家居和媒体投放常依赖 .local、单标签主机名、mDNS、LLMNR 或厂商自定义域名。这些名称不一定应由公网 DNS 处理。网关方案通常需要保留本地解析器，并对内部域名设置真实解析或专用上游。

游戏与实时通信需要按现象判断

部分游戏启动器使用域名下载资源，但实际对战阶段通过 UDP、固定 IP 或区域调度服务通信。Fake-IP 对启动器网页接口可能工作正常，却可能影响延迟探测、服务器列表或反作弊组件的地址判断。出现问题时，不应直接关闭全部 DNS 功能；可先从日志确认失败域名，再将确实要求真实地址的域名加入过滤列表。

Fake-IP 排除项的设计方法

fake-ip-filter 的目标是让特定域名跳过映射，直接向应用返回真实 IP。排除范围越大，能够用于域名规则匹配的连接越少，因此排除列表应围绕具体兼容需求建立，而不是复制一份无法说明来源的超长清单。

局域网与本地域名

*.lan、*.local 和家庭内部自定义后缀通常值得优先检查。如果 NAS 使用 storage.home.arpa，就应结合本地 DNS 与实际后缀设置对应规则。单纯排除域名但没有可回答查询的本地解析器，仍然无法得到正确地址。

时间同步与网络连通性检测

某些系统服务会通过特定域名寻找 NTP 服务器、检测网络是否可用，或判断当前是否需要登录认证门户。这类程序可能希望拿到真实地址，甚至会比较 DNS 与 HTTP 响应。若设备频繁显示“网络不可用”，但浏览器访问正常，可以从系统连通性检测域名和时间同步域名开始查看日志。

设备发现、语音与游戏服务

依赖局域网广播的设备通常不应把本地名称映射到 Fake-IP。游戏和语音程序则要区分登录、更新、匹配和实时通信域名，避免用一个过宽的通配符排除整个厂商域名。过宽排除可能导致下载域名失去原有代理规则，只能按真实 IP 或兜底规则处理。

dns:
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "*.home.arpa"
    - "localhost"
    - "time.windows.com"
    - "time.apple.com"

不同内核版本对通配符、规则集和附加匹配语法的支持可能不同。最稳妥的做法是先用明确的完整域名验证，再根据日志扩展到必要的子域范围。配置加载后还应清理系统 DNS 缓存，关闭应用中已有的长连接，并重新查询，避免旧缓存掩盖修改结果。

常见故障与定位顺序

查询结果仍是真实 IP

先确认客户端显示的运行模式和实际内核配置中是否为 enhanced-mode: fake-ip，再检查域名是否命中过滤项。随后确认测试工具使用的是哪个 DNS 服务器。浏览器安全 DNS、系统 DoH、VPN 软件或局域网 DHCP 下发的其他 DNS，都可能让查询绕过 Clash。

可以解析，但连接一直超时

看到映射地址说明 DNS 阶段可能已经进入内核，但后续连接未必被接管。系统代理模式下，不遵循代理设置的应用可能直接访问 198.18.x.x；TUN 模式下，则需检查虚拟网卡、路由表、防火墙权限和 DNS 劫持设置。部署在网关时，还要确认 Fake-IP 地址池的流量会被正确送回网关内核。

规则没有按域名命中

查看日志中的目标类型。如果日志只显示真实 IP，可能是查询绕过内置 DNS、应用直接连接固定 IP，或该域名被加入了 Fake-IP 过滤。若日志能够显示域名但策略仍不正确，应检查规则顺序：Clash 通常按从上到下的顺序匹配，较宽泛的规则放在前面会提前截获连接。

局域网设备名称无法访问

确认名称究竟由哪种机制解析。.local 常与 mDNS 有关，不一定经过普通单播 DNS；自定义 NAS 域名则可能由路由器 DNS 回答。应把对应域名交给能够返回内网地址的解析器，并根据需要加入 Fake-IP 排除。只设置 DIRECT 规则并不能修复错误的 DNS 应答，因为规则匹配发生在解析链路之后。

切换配置后结果没有变化

DNS 结果可能缓存在操作系统、浏览器、应用和内核中。测试时可依次重载配置、清理系统 DNS 缓存、完全退出应用并重新打开。不要只刷新网页，因为浏览器可能继续复用现有连接。若客户端支持查看当前配置，应确认订阅更新或覆写过程没有把手工修改覆盖掉。

配置结论：先保证闭环，再增加排除

Fake-IP 的关键不是“返回一个特殊 IP”，而是建立 DNS 查询与后续连接之间的映射闭环。查询进入 Clash、连接再次进入 Clash、映射表恢复域名、规则选择策略，这四步完整时，域名分流才具有稳定基础。任何一步绕开内核，都可能出现解析正常但无法连接，或连接成功却命中错误规则的情况。

桌面设备使用 mihomo 与 TUN 时，可以从基础 Fake-IP 配置开始，再按日志添加局域网、时间同步、游戏和设备发现域名。路由器与旁路网关则要额外确认 DHCP、IPv6 DNS、地址池路由和客户端加密 DNS。排除项应小而明确，每条都对应可复现的兼容需求，这样配置在订阅更新、内核升级和设备迁移后仍然容易维护。