Fake IP
最后更新：2026-06-24 · 适用版本：Mihomo v1.17.0+ · 客户端：Clash Verge Rev
在 安装 和 基础配置 之后，你一定已经听说过 Fake-IP 这个名字。它被称作 Clash 代理体系中“防泄漏的基石”，但很少有人把它真正的原理讲透。这篇文章将带你从数据包的第一跳开始，彻底理解 Fake-IP 是如何用一个虚拟 IP 池，既骗过了应用程序，又骗过了 DNS 污染，最终实现绝对隐私的。
- 为什么需要 Fake-IP？传统模式的三重困境
- Fake-IP 工作流：从域名到连接的四步魔法
- 核心机制：Fake-IP 映射表与 DNS 缓存
- 关键参数精解：fake-ip-range 与 fake-ip-filter
- 与 TUN 模式的深度绑定：为什么它们是天作之合
- 与 DNS 防泄漏模块的完美协作
- 生产级 Fake-IP 配置模板
- 常见误区与排错
- 下一步学习
在没有代理的普通网络中，当你访问 google.com 时，操作系统会向本地 DNS 服务器（通常是运营商的）发送一个 未加密的 UDP 查询。这个查询就像一张明信片，上面写着“我要去 google.com”。即使后续的 HTTPS 流量是加密的，运营商依然可以清晰地看到你访问了哪些网站。
传统 Clash 的“普通 DNS 模式”仅仅是把这个查询转发到另一个 DNS 服务器（比如 8.8.8.8），但转发过程本身可能也是明文的，而且应用程序仍然能够感知到真实的 IP 地址。
假设你有一条规则 DOMAIN-SUFFIX,google.com,PROXY。在普通模式下，浏览器先获得 google.com 的真实 IP（比如 142.250.80.46），然后用这个 IP 去建立连接。当连接建立时，Clash 内核看到的只是一个 裸 IP，它根本不知道这个连接最初是因为 google.com 发起的！于是，你精心编写的域名规则完全失效，只能依靠 IP-CIDR 规则进行模糊匹配，这很容易误伤或者漏判。
在某些网络环境下，DNS 查询会被恶意篡改，返回一个错误的 IP 地址（DNS 污染）。普通模式下，如果 Clash 直接返回这个错误 IP，浏览器就会连接到一个错误的服务器。而如果 Clash 对每个 DNS 查询都走代理去解析（远程解析），又会显著增加延迟。
Fake-IP 模式一举解决了上述全部问题。它的核心思想是：永远不要让应用程序接触到真实的 DNS 答案。
假设你开启了 Fake-IP，并且配置了 fake-ip-range: 198.18.0.1/16，下面是一次完整的访问 youtube.com 的过程：
-
第一步：应用程序发起 DNS 查询
浏览器（或任何应用）向系统 DNS 解析器询问youtube.com的 IP 地址。这个请求被 TUN 模式或系统代理的 DNS 劫持捕获，送入了 Mihomo 内核。 -
第二步：内核立即返回一个虚拟 IP
Mihomo 内核的 DNS 模块收到查询后，并不去真正的上游 DNS 查询。它在内存中的 Fake-IP 映射表 里查找youtube.com。如果之前已经分配过虚拟 IP，则直接返回那个 IP；如果没有，则从198.18.0.0/16池子中挑一个未使用的虚拟 IP（比如198.18.0.5），建立映射关系youtube.com → 198.18.0.5，然后瞬间将198.18.0.5返回给浏览器。 -
第三步：应用程序向虚拟 IP 发起连接
浏览器以为198.18.0.5就是youtube.com的真实地址，于是向这个 IP 发起 TCP/TLS 连接。这个连接请求同样被 TUN 或系统代理截获，送入 Mihomo 内核。内核看到目标 IP 是198.18.0.5，反查映射表，就知道“哦，这个连接原本是要去youtube.com的”。 -
第四步：内核拿域名去匹配规则并代理
现在，内核手里既有完整的域名youtube.com，又有连接本身。它用域名去匹配你写的所有规则（DOMAIN,DOMAIN-SUFFIX,GEOSITE等）。匹配完成后，内核才通过代理服务器去真实的上游 DNS 查询youtube.com的真实 IP，并建立代理隧道。整个过程，你的本地设备从未接触过真实的 DNS 响应。
Fake-IP 的魔法全在那张内存映射表中。它是一个简单的键值对：域名 → 虚拟IP。当 store-fake-ip: true 开启时，这张表会被持久化到磁盘，重启客户端后无需重新建立。
-
创建：首次遇到新域名时，从
fake-ip-range池中分配 IP。分配算法通常是顺序递增或哈希。 - 使用：每次连接建立时，内核通过目标 IP 反查域名，用于规则匹配。
-
淘汰：当池子中的 IP 用尽时，最久未使用的映射会被清除，以便回收 IP。你也可以通过调整
fake-ip-range的大小来控制容量。
198.18.0.0/15 是 RFC 2544 规定的网络基准测试保留地址段，不会在公网上路由，也不会与任何私有地址（如 192.168.x.x）冲突。使用它作为虚拟 IP 池，可以最大程度避免与真实网络环境发生冲突。
| 参数 | 说明 | 最佳实践 |
|---|---|---|
fake-ip-range |
虚拟 IP 地址池。所有被代理的域名都将被分配这个段内的一个 IP。 |
198.18.0.1/16（约 65534 个 IP，足够绝大多数用户） |
fake-ip-filter |
黑名单列表。匹配到的域名将 不 返回虚拟 IP，而是走真实 DNS 解析。 | 必须包含局域网设备、NTP 服务等不需要代理的域名。 |
并非所有域名都适合被分配虚拟 IP。一些典型的例外：
-
局域网设备：如
*.lan、+.local。你的打印机、NAS 需要真实的局域网 IP 才能通信。 -
NTP 时间同步：如
ntp.*、time.*。某些 NTP 客户端不接受虚拟 IP 作为时间源。 -
Windows 网络状态检测：
*.msftncsi.com、*.msftconnecttest.com。这些域名被 Windows 用来检测网络连通性，若返回虚拟 IP 可能导致系统误判“无网络”。
dns:
fake-ip-filter:
- '*.lan'
- '+.local'
- 'ntp.*'
- 'time.*'
- '*.msftncsi.com'
- '*.msftconnecttest.com'虽然 Fake-IP 可以在系统代理模式下工作，但它真正的威力需要 TUN 模式来释放。原因在于：
-
TUN 劫持所有 IP 流量：应用程序向虚拟 IP
198.18.0.5发起的连接，必须被 TUN 设备捕获并路由到 Mihomo。如果只开系统代理，某些不遵循代理设置的应用（如命令行工具、游戏）会直接尝试向198.18.0.5发起连接，但由于你的物理网卡上根本没有这个 IP，连接将失败。 -
TUN 的
route-address-set必须包含 Fake-IP 段：你需要显式告诉系统“目标为198.18.0.0/16的流量都送进 TUN”。
这就是为什么在 TUN 深度优化指南 中，我们强烈推荐同时启用 TUN 和 Fake-IP，并在 route-address-set 中添加 198.18.0.0/16。
tun:
enable: true
route-address-set:
- 198.18.0.0/16 # 至关重要！
Fake-IP 本身已经让本地设备看不到真实 DNS 响应，但上游的 DNS 查询仍然需要保护。结合 DNS 防泄漏终极方案 中的 nameserver-policy，你可以让国内域名走国内 DNS，国外域名走加密 DoH/DoT，实现“本地零泄漏 + 上游全加密”的终极形态。
同时，开启 Mihomo 内核的 Sniffer 模块 可以进一步强化 Fake-IP：即使应用程序直接拿真实 IP 发起连接（不走域名解析），Sniffer 也能从 TLS ClientHello 中嗅探出域名，并将其强制加入 Fake-IP 映射表，让规则匹配依然精准。
以下是集成了 Fake-IP、TUN 和 DNS 防泄漏的推荐配置片段，可直接合并到 config.yaml 中：
# ============================================
# Fake-IP 核心配置模板
# 仓库：https://github.com/clash-verge2026/clash-verge-rev-omni-guide
# 适用：Clash Verge Rev v2.6.0+ + Mihomo v1.17.0+
# ============================================
# DNS 模块 —— Fake-IP 核心
dns:
enable: true
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
fake-ip-filter:
- '*.lan'
- '+.local'
- 'ntp.*'
- 'time.*'
- '*.msftncsi.com'
- '*.msftconnecttest.com'
default-nameserver:
- tls://223.5.5.5
nameserver:
- https://dns.cloudflare.com/dns-query
- tls://dns.quad9.net
proxy-server-nameserver:
- tls://8.8.8.8
nameserver-policy:
"geosite:cn,private":
- tls://223.5.5.5
"geosite:geolocation-!cn":
- tls://dns.quad9.net
# 持久化 Fake-IP 映射表（重启后恢复）
profile:
store-fake-ip: true
# TUN 模块 —— 配合 Fake-IP 实现全局接管
tun:
enable: true
stack: mixed
device: Mihomo
dns-hijack:
- any:53
auto-route: true
auto-detect-interface: true
route-address-set:
- 198.18.0.0/16 # 必须包含
- 10.0.0.0/8
- 172.16.0.0/12
- 192.168.0.0/16
# 连接优化（可选）
tcp-concurrent: true
unified-delay: true
这是因为打印机域名（如 printer.local）被分配了虚拟 IP。只需将 +.local 和 *.lan 加入 fake-ip-filter 即可。如果打印机使用的是其他域名，按需添加。
这些应用很可能绕过了系统代理，又没有走 TUN。确认 TUN 模式已正确开启，并且 route-address-set 包含 198.18.0.0/16。在 Windows 上，需要以管理员权限运行 Clash Verge Rev。
/16 网段有 65534 个可用 IP，对于个人用户来说几乎不可能用完。如果你有大量独特的域名请求，可以扩大为 /15 或开启 store-fake-ip: false 让映射表不持久化，重启后自动清空。
redir-host 是另一种“保持域名上下文”的方式，它依靠嗅探透明代理流量中的 Host 头。但它对 HTTPS 流量无效，且依赖 TPROXY/redirect 网关模式。对于桌面客户端，无脑选择 Fake-IP 是最佳实践。
掌握 Fake-IP 原理后，你的代理体系已经拥有了坚不可摧的 DNS 层。继续深入，打造全栈代理方案：
- 🧠 Mihomo 内核调优 — 开启 Sniffer 让 Fake-IP 如虎添翼。
- 🔗 TUN 深度优化 — 混合栈与零拷贝，释放全部吞吐潜力。
- 🛡️ DNS 防泄漏终极方案 — 与 Fake-IP 协同，构建上游加密分流。
- 🤖 AI 网站智能分流 — 让 AI 流量智能选择最优线路。
- 🔄 自动化运维 — 用 GitHub Actions 定时更新订阅与规则集。
⬅️ 返回配置精要 · 返回 Wiki 首页
本文为 clash-verge2026/clash-verge-rev-omni-guide 官方 Wiki 的一部分。为了获得最佳体验，请确保你正在使用 最新版本的客户端与内核。