Fake-IP（常被界面写成「虚拟 IP / 虚拟 DNS」）是规则代理客户端里的一种名字解析模式：本机先把域名映射成保留网段中的占位地址，再按这个地址做分流与建连。2026 年 Clash 系、sing-box 等客户端仍广泛默认或推荐它。选 Fake-IP 还是真实 DNS，关键不是开关名字，而是你是否接受「应用看到的 IP 不是公网上的那个」。
Fake-IP 到底改了哪一步
普通路径是：应用问 DNS → 得到真实 A/AAAA → 向该 IP 建连。Fake-IP 把前半截换成客户端控制的映射表。
一个可独立引用的定义句：Fake-IP 是用占位地址承接域名规则的解析模式，不是另一种加密协议。
典型顺序：
- 应用向系统（或客户端劫持的）DNS 查询
example.com； - 客户端立刻返回例如
198.18.0.x一类保留测试网段地址（具体前缀因实现而异）； - 应用以为目标就是该占位 IP，把连接交给协议栈；
- 包进入 TUN 全局代理 或增强栈后，客户端用「占位 IP → 原域名」反查，再按域名规则决定代理 / 直连；
- 真正向上游问真实地址、或直接向节点请求该域名，发生在客户端内部，而不是应用此刻看到的那次系统解析。
| 模式 | 应用看到的地址 | 规则何时能用域名 | 本地网络是否易看到完整查询 |
|---|---|---|---|
| 真实 DNS（redir-host 等） | 公网/权威结果 | 常需先解析再匹配，或另做嗅探 | 若解析走运营商，查询更易暴露 |
| Fake-IP | 保留网段占位地址 | 在返回占位地址时即可按域名分流 | 查询多留在客户端内，运营商侧更少 |
这与 DNS 泄漏检查 讨论的「解析器是谁」相关，但不是同一问题：泄漏看的是问了谁；Fake-IP 看的是返回了什么形态的答案。
为什么规则代理喜欢 Fake-IP
VPN 分流是什么里写过：域名规则要在连接前知道「这是哪个名字」。若系统已经解析出真实 IP，客户端有时只能看到目标 IP，域名策略就失效或要靠延迟的协议嗅探补救。
Fake-IP 的工程动机通常是：
- 让域名规则更早、更稳地命中：占位地址由客户端发出，反查表在自己手里；
- 降低「解析出口」和「连接出口」打架的一类情况：真实解析若在运营商完成，CDN 可能把你指到与隧道出口不匹配的节点；
- 减少本机把查询列表送给本地解析器：在意运营商侧查询可见性时，这是常见理由之一；
- 配合 TUN：应用不认 SOCKS 时，仍能在 IP 层被带进「按域名决策」的路径。
它不自动等于「更匿名」或「更快」。节点质量、协议与 MTU 仍各自独立。
和真实 DNS 差在哪里
| 维度 | Fake-IP | 真实 DNS |
|---|---|---|
| 应用拿到的 IP | 占位地址 | 权威/上游返回的真实地址 |
| 谁保存域名映射 | 客户端映射表 | 系统缓存 + 权威结果 |
| 对「只认真实 IP」的软件 | 更容易异常 | 通常更兼容 |
| 诊断（ping/traceroute 目标名） | 常 ping 到占位地址，结果难读 | 更接近公网路径 |
| 与检测页/CDN | 偶发显示保留地址或行为怪异 | 更贴近未开代理时的解析形态 |
「真实 DNS」在不同客户端里的名称不一：redir-host、normal、system、关闭 Fake-IP 等。共同点是：应用侧看到的是可路由的真实结果（或系统解析器给出的结果），而不是客户端私有的占位段。
测试环境写法示例：2026 年 9 月，家庭宽带，Windows 11 + 规则模式客户端。同一域名分别在 Fake-IP 与真实 DNS 下查询，记下应用看到的 IP、客户端规则命中日志，以及浏览器打开后的出口地区。
常见副作用与怎么对照
Fake-IP 把「名字」和「应用以为的 IP」拆开，副作用也来自这道缝：
- 游戏、启动器、部分下载器：把占位 IP 写入配置或做 IP 级白名单，联机失败；
- 企业软件 / 证书钉扎：预期连向固定地址，收到保留段地址后握手或策略失败；
- 系统与命令行诊断：
ping、tracert/traceroute打到198.18.0.x，不能代表公网路径； - 双栈：只对 A 记录做 Fake-IP、AAAA 仍真实（或相反）时，IPv6 泄漏检查 与 Happy Eyeballs 会让「有时走占位、有时走真实」更难读；
- 映射表过期或冲突：长连接跨过 TTL、或不同进程拿到同一占位地址的不同世代，表现为偶发连错站。
结果对照表
| 现象 | 更可能的含义 | 下一步 |
|---|---|---|
| 浏览器正常，某游戏只能填 IP 才行 | 应用依赖真实地址 | 对该进程/域名改真实 DNS 或直连例外 |
| 规则写了代理，仍走家庭出口 | 未走 Fake-IP 路径或规则未命中 | 看客户端命中日志与模式是否为规则 |
| ping 域名得到 198.18/198.19 段 | Fake-IP 按设计工作 | 不要用这次 ping 判断节点延迟 |
| 仅部分站点证书错误 | 占位映射错代或分流与嗅探冲突 | 清 DNS 缓存、改该域真实解析后复测 |
| 检测页列出保留地址 | 页面读到了应用侧地址 | 对照隧道出口检测，勿与「真实公网 IP」混读 |
无法核对客户端实现细节时，写「据客户端文档 / 日志显示」，不要断言所有产品使用同一保留网段。
怎么选，而不是默认全开或全关
更适合 Fake-IP 的情况：
- 以浏览器与普通 HTTPS 为主，依赖长域名规则集；
- 已开 TUN，希望域名分流在进隧道前就稳定命中；
- 你明确不想让本地运营商 DNS 看到完整查询列表，并已理解占位地址的兼容代价。
更适合真实 DNS（或按域名关闭 Fake-IP）的情况：
- 游戏、语音、行业软件频繁联机失败，日志里出现保留段地址；
- 需要用 ping/mtr/证书链对真实目标做排障；
- 设备上有严格的 IP 白名单、防火墙或零信任客户端；
- 双栈行为混乱，且短期只想减少变量。
务实做法是默认 Fake-IP + 例外名单：把不兼容的域名或进程打回真实解析，而不是一出问题就整机关停。例外越写越长时，回到分流文里的期望表，检查是不是粒度选错了。
和泄漏检查放在同一清单里
换客户端、改 DNS 模式或从系统代理切到 TUN 之后，建议固定做三步：
- 看一次系统/应用解析到的地址形态（占位还是公网）；
- 跑 DNS 泄漏检查，确认解析器仍是你期望的隧道侧，而不是「开了 Fake-IP 就必然不漏」；
- 抽查一个应代理、一个应直连的目标，核对出口与规则命中。
Fake-IP 不替代 Kill Switch，也不处理 WebRTC 候选地址；那些仍要按各自专文验证。
常见误解
误解 1：Fake-IP = 防 DNS 泄漏的充分条件。
它改变答案的形态与查询是否出网，但浏览器 DoH、独立网络栈、错误的直连规则仍可把查询送走。以检测为准。
误解 2：看到 198.18 开头就是配置坏了。
在 Fake-IP 模式下这经常是预期结果。坏的是「本该真实解析的应用拿到了占位地址还继续用」。
误解 3：真实 DNS 一定更慢或一定被污染。
速度与污染取决于解析器选谁、是否进隧道，以及权威/CDN 调度，不取决于名字叫不叫 Fake-IP。
误解 4：关了 Fake-IP 就等于关了代理。
只是改回真实地址再匹配规则或走默认策略；隧道与节点可以仍在。
建议怎么落地
先确认客户端当前是 Fake-IP 还是真实 DNS，再列两列应用：能接受占位地址的（浏览器等）与必须真实 IP 的（游戏、诊断、企业客户端）。前者留在 Fake-IP，后者写例外或切真实解析；改动后用规则命中日志和 DNS 泄漏检查做回归。目标是让「域名规则」和「应用 compatibility」同时可验证，而不是迷信某一个默认开关。