DNS 与模式 预计阅读 10 分钟

Fake-IP 模式原理解析：198.18 保留地址、fake-ip-filter 与适用场景

讲解 Fake-IP 如何用 198.18.0.1/16 地址段加速 DNS 响应，对比 redir-host 的取舍，并说明 fake-ip-filter 的用途及局域网、游戏场景的注意点。

Fake-IP 原理：先返回映射地址，再处理真实连接

开启 Fake-IP 后，查询域名却得到 198.18.x.x，通常不是 DNS 出错，而是内核在返回一个用于本地映射的地址。理解这点之前，先拆开两个动作：DNS 回答“应用接下来连接哪个地址”，代理规则决定“这条连接走哪个出口”。两者相互配合，但不是同一个开关。

本文的配置示例以 Clash Meta 后续发展的 mihomo 内核为对象。不同客户端的界面名称与配置合并方式不同，旧版 Clash 内核也不一定支持全部 DNS 扩展字段。修改前，应在客户端的内核信息与运行配置中确认实际生效内容，而不是只看编辑器里保存的文件。

一次域名访问经过哪些步骤

  1. 应用查询 example.com 的 IPv4 地址，请求进入 mihomo 的 DNS 服务。
  2. 内核从 Fake-IP 地址池分配一个地址，建立“域名 ↔ 假地址”的映射，并把假地址返回给应用。
  3. 应用连接这个地址；连接必须再次被同一个内核接管，例如经由正确配置的 TUN 路由。
  4. 内核根据映射恢复域名，执行规则匹配，再通过直连或代理建立真正的目标连接。

关键收益是：对可以直接分配 Fake-IP 的查询，DNS 回答不必先等待上游返回真实地址。域名身份也能保留到分流阶段。不过，后续直连、IP 类规则匹配或某些代理协议仍可能需要真实解析；具体由规则、出口与内核行为决定。“DNS 回答更快”不等于“所有网页都更快”。

198.18.0.1/16 是什么：地址池与保留网段

198.18.0.0/15 是用于网络设备基准测试的特殊用途 IPv4 网段，范围覆盖 198.18.0.0 至 198.19.255.255，不是正常网站使用的全球可路由公网地址。常见配置中的 198.18.0.1/16 则让 Fake-IP 使用其中的一个 /16 地址池；不要把 /16 与整个 /15 混为一谈。

配置写的是 198.18.0.1/16，并不意味着所有域名都返回 198.18.0.1。内核会维护地址池与映射，不同域名可以获得不同地址。这个地址也不是节点服务器地址，不需要拿它去测速节点，更不应该填进订阅地址栏。

  • 看见保留地址：先确认它来自 Fake-IP 回答，而不是马上更换 DNS。
  • 企业网络或实验网络已使用该网段：可能发生路由冲突，需检查路由表与地址池规划。
  • 更改地址池：还要同步检查 TUN 路由、旁路由转发和应用缓存，不能只改一行 YAML。

不要为了“像真实 IP”而随手把地址池改成 192.168.1.0/24。它很可能与家中路由器、打印机或 NAS 所在网络重叠。保留地址的用途正是隔离这层映射，不是让界面上的数字更眼熟。

Fake-IP 与 redir-host：如何选择 DNS 模式

redir-host 通常向应用返回上游解析得到的真实地址，再结合 DNS 映射等信息处理连接；fake-ip 则主要返回本地映射地址。这里的模式名称属于 DNS 增强模式，不等于客户端首页的“规则、全局、直连”模式。

比较项fake-ipredir-host
应用收到的 A 记录通常为地址池中的映射地址通常为上游返回的真实 IPv4 地址
首次 DNS 响应可先分配映射，减少等待上游的环节未命中缓存时一般需要等待真实解析
连接接管要求假地址连接必须回到持有映射的内核仍需正确接管，但真实地址可被普通网络识别
常见兼容问题地址探测、局域网发现、绕过接管的程序共享 IP、DNS 缓存及域名关联不完整等情况
适合优先尝试的场景接管完整、以域名规则分流的日常上网依赖真实解析结果、Fake-IP 例外较多的环境

选型不需要站队。日常浏览与 TUN 接管可以先用 Fake-IP，再给确有问题的服务配置例外；企业 VPN、复杂局域网或依赖地址探测的业务，可以先验证真实解析模式是否更容易维护。判断标准应是业务访问、日志与路由是否一致，而不是单看一次 DNS 查询耗时。

mihomo DNS 配置：最小片段与验证方法

下面只展示 dns 配置片段，不是完整订阅。应合并到现有配置，避免重复出现两个顶层 dns:。示例监听本机 127.0.0.1:1053，用于隔离验证；它不会自动把系统 DNS 改到这个端口，也不会自动开启 TUN。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter-mode: blacklist
  fake-ip-filter:
    - 'localhost'
    - '+.lan'
    - '+.local'
  nameserver:
    - 223.5.5.5
    - 1.1.1.1

nameserver 是示例上游，不表示两项都会在当前网络可达，也不表示这里配置了加密 DNS。应根据网络位置和解析需求选择上游；若改用 DoH 或 DoT，还需考虑服务器域名的引导解析、连接可达性以及现有 DNS 分流策略，避免请求绕圈。

先测内核，再测系统链路

保存配置并确认内核成功加载后，在安装了 dig 的环境执行以下命令。这里使用 -p 1053 明确指定测试端口，避免误测到系统正在使用的其他 DNS 服务。

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

在没有其他过滤项或策略覆盖的情况下，第一条命令的回答区应出现 198.18.x.x，第二条只输出地址。实际分配值由内核运行状态决定，不必与某个截图完全一致。若连接被拒绝，先检查 DNS 开关、监听端口和内核日志，而不是先改节点。

  1. 确认直接查询内核能得到符合预期的 A 记录。
  2. 检查客户端的 TUN DNS 劫持或系统 DNS 转发是否确实指向内核。
  3. 通过应用发起新连接，在连接面板确认域名、命中规则和出口。
  4. 遇到旧结果时清理应用与系统 DNS 缓存，再用新连接复测。

fake-ip-filter 写法：返回真实地址，不等于直连

在示例明确设置的 blacklist 模式下，fake-ip-filter 命中的域名不分配 Fake-IP，而是走真实解析。支持该字段的 mihomo 也提供其他过滤模式，含义可能反转，因此迁移配置时要把过滤模式与列表一起检查。旧内核若提示字段不支持，应按对应内核文档调整，不能只消除报错而不核对语义。

示例中的 '+.lan' 用来覆盖 lan 及其子域名，'+.local' 同理。这是 mihomo 域名匹配写法，不是可以任意拼接的正则表达式。保留引号便于维护，也可以减少 YAML 特殊字符带来的解析问题。

三种设置要分开处理

  • 返回什么地址：由 Fake-IP 模式及过滤策略决定。
  • 向谁解析：由上游 DNS、nameserver-policy 等设置决定。
  • 连接走哪里：由 rules 与代理组选择决定。

因此，把某个 NAS 域名加入过滤列表，不会自动让内核向家中路由器查询，也不会自动添加 DIRECT 规则。假如域名只在路由器 DNS 中存在，仍需将该域名的解析送到正确的局域网 DNS，并确保连接可以直达对应网段。

维护列表时建议一次只增加一个服务需要的域名范围，记录改动前后的解析结果与访问结果。直接加入过宽的公共域名后缀，会让大量原本适合 Fake-IP 的请求改走真实解析，也会让后续排查失去边界。

局域网与游戏场景：按实际故障添加例外

NAS、打印机与 .local 设备发现

局域网服务常见两条路径：一条通过路由器提供的单播 DNS 解析设备名，另一条通过 mDNS 在本地网络发现设备。.local 常用于 mDNS，后者通常使用 UDP 5353，不是普通 DNS 的 53 端口。把 +.local 加入过滤列表，并不能修复所有组播发现问题。

如果直接访问 NAS 的局域网 IP 正常、用主机名失败，应先检查域名解析路径；如果设备列表完全不出现，还要检查防火墙、网络隔离、组播与 TUN 路由。故障在不同层，工具就得换一把。

游戏登录、对战 UDP 与延迟显示

游戏可能将域名解析结果用于区域判断、服务器列表、连通性检测或延迟显示。有的检测逻辑不接受保留地址，此时只对受影响的域名尝试真实解析，比关闭全部 Fake-IP 更容易定位问题。

  • 登录失败：检查登录域名解析、HTTPS 连接和规则命中，不要直接归因于 UDP。
  • 能登录但不能进入对局：检查游戏 UDP 是否被接管、节点与出口是否支持所需 UDP 流量。
  • 延迟显示异常但实际可玩：确认游戏是否使用 ICMP 或独立探测域名，显示值不一定代表对战链路。
  • 只在切换模式后出错：完全退出游戏和启动器，清理缓存后重新建立连接。

不要把所有游戏域名都默认列入过滤列表，更不要把“允许 UDP”理解为降低延迟的保证。Fake-IP 处理的是地址映射；链路距离、出口拥塞、NAT 类型与游戏服务器状态仍然独立存在。

Fake-IP 无法访问的排查顺序

排查时每次只改变一个变量，并保留运行日志。下面按照从配置到连接的顺序检查，通常比反复切换全局模式更有效。

  1. 核对运行配置：确认当前配置的 enhanced-mode 为 fake-ip，订阅更新没有覆盖本地修改，内核没有配置加载错误。
  2. 核对查询入口：直接向 127.0.0.1:1053 查询，再与系统或浏览器结果比较。浏览器的安全 DNS、应用自带 DoH 可能绕过预期的系统解析路径。
  3. 核对接管范围：普通 TUN DNS 劫持常围绕传统 DNS 流量配置，不能把所有 HTTPS 加密 DNS 自动识别成普通 53 端口查询。应用拿到假地址后的连接也必须进入内核。
  4. 核对映射与缓存：内核重启、切换配置或地址池变化后，应用可能仍持有旧假地址。先清缓存、重启相关应用，再判断是否需要调整内核的 Fake-IP 映射持久化设置。
  5. 核对规则：连接已有域名却走错出口时，检查规则顺序与代理组，不要只改 DNS。依赖目标 IP 的规则还可能触发真实解析。
  6. 核对双栈：单独测试 A 与 AAAA 记录，并检查 IPv6 接管。一次 IPv4 查询正常，不代表 IPv6 路径也已配置正确。

最终应保留一份能解释清楚的配置：DNS 从哪里进来、过滤项为什么存在、真实解析交给谁、连接由哪条规则接走。Fake-IP 的价值是减少解析等待并保留域名关联，不是替代路由、规则或网络质量检查。

下载Clash按平台选择客户端