Clash Fake-IP 是什么：DNS 映射流程、fake-ip-filter 与适用场景

先看结论：Fake-IP 是域名映射，不是代理出口

Fake-IP 模式让 Clash 内核先给应用返回一个合成地址，再在接管连接时把这个地址还原成域名。应用看到的地址可能是 198.18.0.2，实际网站和代理出口却不在这个地址上。看到这个地址本身，不代表 DNS 被污染，也不能据此判断请求有没有经过代理。

这套机制需要两个环节同时成立：DNS 查询交给内核处理，随后发往合成地址的连接也交回同一个内核。桌面端常用 TUN 接管流量；路由器可能通过透明代理规则完成接管。仅在配置里写入 enhanced-mode: fake-ip，并不会自动替操作系统建立全部路由和 DNS 转发。

DNS 映射到连接还原的五个步骤

以应用访问 example.com:443 为例，假设 DNS 与连接都已由同一 mihomo 实例接管，处理顺序如下。

应用发起查询。应用请求 example.com 的 IPv4 地址，查询进入内核 DNS 服务。若应用另用加密 DNS 且未被接管，这一步可能绕过内核。
内核分配合成地址。域名未命中过滤列表时，内核从 Fake-IP 地址池分配地址，例如 198.18.0.2，并保存域名与地址之间的映射。已有有效映射时可以复用。
应用连接合成地址。应用按普通网络流程向 198.18.0.2:443 发起连接。TUN 或透明代理规则将连接送回内核，而不是让它直接进入公网。
内核找回原始域名。内核查询映射表，恢复出 example.com，据此执行域名规则、策略组选择及后续连接处理。
按出口建立真实连接。走代理时，若协议与实现支持传递域名，解析可在代理端进行；走直连时，通常仍需由本地内核完成真实解析。具体行为还取决于规则和 DNS 配置。

198.18.0.0/15 是用于网络设备基准测试的特殊用途地址段，不是网站实际使用的公网地址。常见配置选用其中的 198.18.0.1/16 作为地址池。企业网络若已经使用该网段，应先处理路由冲突，不能直接套用默认值。

为什么保留域名有助于规则分流

只看到一个共享 CDN 地址时，内核很难仅凭该地址区分不同网站。Fake-IP 映射让连接保留域名线索，便于匹配 DOMAIN、DOMAIN-SUFFIX 等规则。不过规则仍然按顺序执行：靠前的进程规则、网段规则或其他匹配项，仍可能先决定出口。

首包延迟：省去的是哪一段等待

Fake-IP 能让应用较早拿到地址，从而提前进入连接阶段；它不需要先等真实 A 记录返回，才给应用一个可用的合成地址。与必须等待真实解析结果的路径相比，这可能缩短启动连接前的等待，但不等于所有网站都能固定提速。

处理环节	返回真实地址的路径	Fake-IP 路径
应用收到 DNS 响应	通常需要拿到真实解析结果，缓存命中除外	可从地址池分配并返回合成地址
域名规则匹配	依赖可用的域名关联信息	可通过合成地址映射恢复域名
直连网站	使用真实地址建立连接	内核可能仍需解析真实地址
代理访问	解析位置受协议与配置影响	支持传递域名时可交由代理端解析

例如，假设一次未缓存的真实 DNS 查询耗时 80 毫秒，Fake-IP 可以让应用不必先等待这 80 毫秒再开始提交连接。这只是说明机制的假设数值，不是实测收益；后续直连解析、代理握手、TLS 握手与服务端响应仍然需要时间。

怎样比较才有意义

固定同一网络、同一节点与同一规则模式，分别测试冷缓存和热缓存，不能把两者混在一起。
使用浏览器开发者工具的「网络」面板观察 DNS、连接和 TLS 阶段，同时查看内核日志。浏览器显示的 DNS 时间未必包含内核后续解析耗时。
至少记录多次页面请求的中位数，区分 DNS 响应速度与页面首字节时间。不要用一次测速下载结果代替 DNS 对比。

最小 DNS 配置与验证命令

下面是配置片段，不是完整的可联网配置。它只开启内核 DNS 并监听本机 1053 端口，代理节点、规则、TUN 与系统 DNS 接管仍需由现有配置提供。这里关闭 IPv6，目的是把验证范围限定为 IPv4 A 记录；正常使用时应根据网络的 IPv6 接管能力决定是否开启。

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:
    - "localhost"
    - "+.lan"
    - "+.local"
    - "+.home.arpa"
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

这两个上游 DNS 地址需要在当前网络中可达。公司、校园或家庭分离解析环境应使用相应的内部解析器；把所有查询都发给公共 DNS，可能导致内部域名解析失败。监听 127.0.0.1 仅接受本机查询，不适合作为其他局域网设备直接访问的 DNS 服务。

先测内核，再测系统解析路径

在已经启动内核的设备上，用以下命令明确指定服务器和端口。Windows 可使用第一条；安装了 dig 的 macOS 或 Linux 可使用第二条。两条命令是替代关系，不必连续执行。

nslookup -port=1053 example.com 127.0.0.1

dig @127.0.0.1 -p 1053 example.com A +short

确认返回地址落在配置的 Fake-IP 地址池内。若请求超时，先检查内核是否启动、端口是否被占用、最终配置中的 DNS 是否启用。
再用系统默认解析方式查询同一域名。指定端口查询成功而系统查询不同，说明应用或系统尚未走到这条 DNS 路径。
在客户端「连接」页面查找刚发起的浏览器请求，核对目标域名、命中规则和出口策略组。DNS 返回合成地址，只证明解析环节，不证明连接接管成功。

fake-ip-filter：哪些域名需要返回真实地址

fake-ip-filter 控制哪些 DNS 查询不分配合成地址。在常见的默认黑名单语义下，命中列表的域名改为返回真实解析结果。较新的 mihomo 还提供过滤模式等扩展设置；如果已有配置包含 fake-ip-filter-mode，应先确认其语义，不能直接假定列表一定代表排除项。

过滤列表不负责决定直连或代理，也不负责选择内部 DNS。一个域名加入列表后，仍然可以按规则走代理；一个域名被规则指定为 DIRECT，也不会因此自动绕开 Fake-IP。

场景	需要观察的现象	处理方式
NAS、打印机与内部服务	应用要求真实局域网地址，或内网域名解析失败	按实际后缀过滤，并将查询交给内部 DNS
游戏登录与联机	程序比较解析地址、把地址发给其他设备，或连接绕过接管	从日志定位具体域名，逐项验证过滤效果
网络连通性检测	系统误报断网、门户认证页不能打开	检查检测域名的解析、出口规则与 HTTP 响应
地址一致性校验	程序要求 DNS 结果与服务端记录或实际地址相符	仅过滤已确认依赖真实地址的域名

局域网域名还需要正确的上游

+.home.arpa 表示该域及其子域，适合已经采用这一命名方式的家庭网络。.lan 是常见的本地约定，但并非每个路由器都使用它。.local 通常涉及 mDNS；把它加入过滤列表，并不会自动让普通 DNS 上游具备 mDNS 发现能力。打印机发现异常时，还应检查多播与本地网络访问权限。

游戏与校验域名按证据添加

不要直接过滤整个游戏平台或全部 CDN 域名。先记录失败时间，在连接和 DNS 日志里定位请求，再只添加有问题的完整域名。例如下面的 login.example.com 是语法演示域名，实际使用时应换成日志里确认的目标，而不是原样用于游戏修复。

dns:
  fake-ip-filter:
    - "localhost"
    - "+.lan"
    - "+.local"
    - "+.home.arpa"
    - "login.example.com"

应将这些条目合并进现有 dns 对象，不要在同一 YAML 文件里重复创建两个顶层 dns 键。若订阅由服务端定期更新，使用客户端支持的覆写或合并功能保存修改，并在更新后检查最终生效配置。

常见故障：解析正常，为什么还是连不上

返回 198.18 地址，但网页一直超时

优先检查连接是否回到了内核。系统代理通常只覆盖愿意遵循代理设置的应用，不能天然接管所有访问合成地址的连接。使用 TUN 时，检查 TUN 是否启动、路由是否安装成功，以及是否存在另一个 VPN 抢占路由。测试时只保留一个负责接管的网络工具，避免 DNS 和流量分属不同实例。

关闭客户端后，少数网站仍访问失败

应用或操作系统可能还缓存着合成地址，而负责还原映射的内核已经退出。先恢复系统 DNS 和路由，再关闭相关应用、清理 DNS 缓存。Windows 可运行 ipconfig /flushdns；使用 systemd-resolved 的 Linux 可运行 resolvectl flush-caches。浏览器自身也可能有缓存，因此系统缓存清理后仍需重启浏览器。

加入过滤列表后没有变化

确认修改的是当前配置，客户端没有被其他配置或全局覆写覆盖。
检查过滤模式与域名写法，确认添加的是实际查询域名，而非只看到了网页地址栏的主域名。
应用配置后清理应用和系统的旧 DNS 缓存，重新查询再测试。
若已返回真实地址但连接仍失败，转查规则、UDP 支持、服务端状态或内部 DNS，不要继续扩大过滤范围。

浏览器正常，游戏或命令行程序异常

两者可能使用不同的 DNS 路径，也可能一个遵循系统代理，另一个直接发包。应用自带的 DoH、硬编码 IP 和局域网多播都不一定经过同一处理流程。域名嗅探可以补充部分连接信息，但不能恢复所有协议中的域名，也不能替代完整的 DNS 与路由接管。

特别是直接使用 IP 的连接，本来就没有“查询域名后分配假地址”这一步。此时要看 IP 规则、进程规则与连接日志，而不是期待给 fake-ip-filter 添加条目来解决。

适用场景与修改前检查清单

日常浏览、需要按域名精细分流，以及已经稳定使用 TUN 的设备，通常适合先测试 Fake-IP。依赖内部 DNS、特殊发现协议或地址一致性检查的环境，则需要把真实解析、内部上游和路由设计放在同一张排查清单里。

先确认内核。记录客户端和内核版本，确认配置字段被当前内核支持。
再确认两条路径。DNS 查询进入内核，合成地址连接也返回同一实例。
过滤保持最小范围。只添加已确认需要真实地址的域名，并说明添加原因。
核对订阅覆写。更新订阅后检查最终配置，避免手工修复被覆盖。
一次只改一类设置。先改过滤，再观察；不要同时更换 DNS、节点、规则和 TUN 参数。