Clash Fake-IP 与 Redir-Host 深度对比 底层架构网络协议与联机游戏模式选型

传统 Redir-Host 模式的运作机理与天花板#

Redir-Host 是一种忠实还原真实网络交互的传统设计。当本地应用程序（例如浏览器）发起对某个外部域名的请求时，系统必须先拿到一个真实且合法的 IP 地址，然后才能建立 TCP 握手。

1
Redir-Host 模式解析与建连时序
2
[本地应用]               [Clash 内核]               [上游 DNS / 远端代理]
3
    │                        │                             │
4
    │ 1. 查询目标域名 IP      │                             │
5
    ├───────────────────────>│                             │
6
    │                        │ 2. 向上游发起实际解析        │
7
    │                        ├────────────────────────────>│
8
    │                        │ 3. 等待并接收真实 IP 返回    │
9
    │                        │<────────────────────────────┤
10
    │ 4. 将真实 IP 返回应用   │                             │
11
    │<───────────────────────┤                             │
12
    │                        │                             │
13
    │ 5. 向真实 IP 发起 TCP  │                             │
14
    ├───────────────────────>│ (根据 IP 规则分流匹配)       │
15
    │                        ├────────────────────────────> 转发至目标网站

在 Redir-Host 流程中，本地必须真实完成一次完整的 DNS 往返。如果遇到被污染的域名，内核还必须等待境外的加密 DNS（如 DoH 或 DoT）返回未被篡改的真实 IP。

这种传统模式暴露出了致命的性能短板。由于每一个外部域名都必须等待境外 DNS 解析落地，用户打开一个包含几十个外部资源的复杂网页时，会感受到明显的首屏等待迟滞。更严重的是，部分特定域名的真实 IP 可能会因为本地运营商的路由策略发生漂移，进而触发针对 IP 的精准阻断。这也是为什么 Clash Meta 与后续演进的 Mihomo 内核逐步将 Redir-Host 标记为弃用并全面推荐 Fake-IP 的技术诱因。

Fake-IP 模式的伪装哲学与零延迟握手#

Fake-IP 采用了反客为主的激进优化思路。既然客户端最终的代理请求是要交给远端节点在境外落地执行的，那么本地操作系统根本没有必要知道目标域名的真实全球 IP 是什么。

1
Fake-IP 模式极致秒开处理时序
2
[本地应用]               [Clash 内核]               [远端落地节点]
3
    │                        │                           │
4
    │ 1. 查询目标域名 IP      │                           │
5
    ├───────────────────────>│ (记录映射: 198.18.0.25 <-> target.com)
6
    │ 2. 毫秒级闪退伪造 IP   │                           │
7
    │<───────────────────────┤ (直接返回保留地址 198.18.0.25)
8
    │                        │                           │
9
    │ 3. 立即向伪造 IP 建连   │                           │
10
    ├───────────────────────>│ (查表还原真实域名 target.com)│
11
    │                        │ 4. 直接封装域名并发往代理   │
12
    │                        ├──────────────────────────>│ (在远端解析真实 IP 并连接)

在 Fake-IP 机制下，当应用程序发起 DNS 查询时，Clash 内核不会等待任何外部网络请求，而是立即从保留的虚拟网段（通常是 198.18.0.0/16）中抓取一个未被占用的私有 IP 地址，瞬间回复给本地应用。

整个过程耗时不到一毫秒。本地浏览器拿到这个伪造 IP 后，立刻心满意足地向该地址发起 TCP 连接。当数据包到达网卡或虚拟 TUN 适配器时，Clash 内核根据内部的高速映射表，瞬间将 198.18.0.25 重新还原为原始的域名 target.com，随后将带有完整域名信息的代理请求直接打包发送给境外落地服务器。

远端服务器在其本土的网络环境中执行真实的 DNS 查询并完成连接。这种设计一举消除了本地 DNS 往返等待，并彻底规避了本地 DNS 污染风险。

两种模式核心特性的多维度全景对比#

为了在不同业务场景中做出精准选择，可以通过以下关键维度的参数进行系统性横向评估。

从对比结果可以清晰看出，Fake-IP 在网页浏览、视频流媒体以及常规科学上网场景中具备碾压式的性能优势。但在涉及特定局域网发现、P2P 直连传输和私有网络协作时，需要配套针对性的配置规避其副作用。

Fake-IP 的经典副作用与工业级规避配置#

很多用户在开启 Fake-IP 后遇到网络异常，根源通常在于本地环境缺少针对性的过滤名单（Fake-IP Filter）。

1
dns:
2
  enable: true
3
  listen: 0.0.0.0:1053
4
  ipv6: false
5
  enhanced-mode: fake-ip
6
  fake-ip-range: 198.18.0.1/16
7
  fake-ip-filter:
8
    # 局域网与标准本地保留域名
9
    - "*.lan"
10
    - "*.local"
11
    - "*.localhost"
12
    - "*.msftconnecttest.com"
13
    - "*.msftncsi.com"
14

15
    # 联机游戏与主机对战平台 STUN 服务
16
    - "+.stun.*.*"
17
    - "+.stun.*.*.*"
18
    - "+.stun.*.*.*.*"
19
    - "stun.*"
20
    - "*.nintendo.net"
21
    - "*.n.nintendoswitch.cn"
22
    - "+.xboxlive.com"
23
    - "+.playstation.net"
24

25
    # 音乐与流媒体版权直连服务
26
    - "*.music.163.com"
27
    - "*.y.qq.com"
28

29
    # 常用公共测速与 NTP 时间同步服务
30
    - "time.*.com"
31
    - "ntp.*.com"
32
    - "*.pool.ntp.org"
33

34
  nameserver:
35
    - 223.5.5.5
36
    - 119.29.29.29
37

38
  fallback:
39
    - https://dns.cloudflare.com/dns-query
40
    - https://dns.google/dns-query

场景选型决策指南#

根据实际的网络核心诉求，选型逻辑非常清晰明确。

如果日常主要以个人电脑办公、网页浏览、观看 4K 流媒体以及技术资料检索为主，同时启用了客户端的 TUN 虚拟网卡模式，应当毫不犹豫地锁定 enhanced-mode: fake-ip。这一选择能让整体网页响应速度提升至少百分之三十以上，并彻底终结各类隐蔽的域名投毒干扰。

如果本地设备长期承担高频的局域网联机对战、作为主路由进行严苛的 P2P 种子做种，或者重度依赖特定企业私有 VPN 隧道，则需要确保所有游戏与企业内网域名均已录入过滤清单。对于极少数必须要求终端实时看到物理公网 IP 的旧版工业监控网络，才建议在旁路网关中退守至特定的物理分流方案。