FakeIP 与 DNS 泄露
第一次 `dig @127.0.0.1 -p 1053 example.com`,返回的不是普通公网 IP,而是个既不私网也不公网的地址:198.18.0.32。这不是内核故障,是 fake-ip 在接管寻址——把域名先换成保留段的“假地址”,用一张表记住映射,连接时再还原成域名。浏览器冲着假地址发起连接,照样完整打开 example.com;代价是 IP-CIDR、GEOIP 这类按真实地址匹配的规则几乎全部失效。这套先假后真的交换,就是 fake-ip 的本质。
redir-host 为什么会翻车:共享 IP 时代的地址反查
2019 年前后,透明代理把 TUN 流量接进来时,内核手里只有目标 IP,没有域名。早期方案 redir-host 的思路是:DNS 解析时返回真实 IP,同时记下“这个 IP 对应哪个域名”,等连接进来再反查。独享 IP 的 VPS 时代这套没问题,CDN 铺开后直接崩——几十个域名共用一个边缘节点 IP,反查表里存哪个?按域名分流的规则全部失准。2023 年原版 Clash 把 redir-host 从配置里移除,大批老订阅报
invalid dns enhanced-mode: redir-host(clash-verge issue #461 就是现场)。mihomo 虽然恢复了 redir-host 并用 sniffer 从 TCP 首包读 SNI 补地址,主流路径已经彻底倒向 fake-ip。假地址从哪来:为什么偏偏是 198.18.0.0/16
假地址不能随便挑。RFC 1918 私网段会跟真实内网撞车——给家里设备发 192.168.x 的假地址,访问 NAS 时可能真的连上别的东西。fake-ip 用的是 198.18.0.0/16,这是 RFC 2544 专为网络基准测试保留的 Benchmark 段,既非公网也非私网,正常设备永远不会往这段发包。内核从池子里给每个域名分配一个稳定地址,同一个域名 dig 两次都返回 198.18.0.32,因为 LRU 表把“域名↔假地址”记死了。多设备、多进程共享同一映射,连接识别零歧义。选这段的讲究被很多人忽略:假地址必须落在“地球上没人用”的网段。
还原那一刻:从 connect 到域名,规则怎么接棒
浏览器拿到 198.18.0.32 照常
connect。内核收包后查 fake-ip 表,把目标从假地址还原成 example.com,才交给规则引擎。这就是为什么 fake-ip 模式下域名规则(DOMAIN-SUFFIX、RULE-SET)总能命中,而 IP-CIDR、GEOIP 几乎永远失效——它们匹配到的是假地址,不是真实 IP。2023-2024 年 mihomo 把控制做得更细:fake-ip-filter 默认黑名单模式,放行局域网、NTP、腾讯登录域名这类必须拿真实 IP 的项;切 whitelist 则语义反转,只有列表内域名才用假地址;v1.18+ 还并存 fake-ip-pool 作为 fake-ip-range 的等价字段名。TUN 是 fake-ip 的前置条件:一次“Google 打不开”事故
FlClash issue #1993 记了一个经典事故:TUN 模式开着,但 DNS 没被劫持。系统照旧直连 8.8.8.8 查询,拿到的是真实 IP,连接也按真实 IP 建立——域名规则全被架空,症状是“系统代理能开 Google,TUN/游戏打不开”。fake-ip 的一切都建立在“所有 DNS 请求必须进内核”这个前提上,所以 TUN 里必须配
dns-hijack 把 any:53 的流量截下来。记住:fake-ip 不是 DNS 优化,是一整套接管寻址的拦截链,断一环整体失效。实战示例
把配置里
enhanced-mode: redir-host 改成 fake-ip,重启 mihomo,再验证映射:dig 两次都返回 198.18.0.15,地址稳定不变。此时 curl -x http://127.0.0.1:7890 https://github.com 照常出内容,开 debug 日志能看到 [UDP] fake-ip 198.18.0.15 -> github.com——假地址当场被还原成域名,规则按域名接棒分流。子关键词
fake-ip-range 与 fake-ip-pool 同字段两个名,别当写错
原版 Clash 用
fake-ip-range,mihomo v1.18+ 新增 fake-ip-pool 作等价字段名,两个都认。范围一般取 198.18.0.1/16,足够几百万域名使用。fake-ip-filter-mode 黑名单还是白名单
默认
blacklist:列表内域名拿真实 IP,其余走假地址。切 whitelist 语义反转,只有列表内域名用 fake-ip。很多人切反导致所有域名直连解析,规则直接架空。sniffer 域名嗅探 redir-host 的救火队员
mihomo 恢复 redir-host 后靠 sniffer 补缺陷:开启后内核读 TCP 连接首包的 TLS SNI 或 HTTP Host,把真实 IP 对应域名补出来再走规则。明文 HTTP 可靠,加密流量握手差异会漏。
dns-hijack TUN 抢 DNS 的关键
fake-ip 要接管解析,TUN 段必须配
dns-hijack 截下 any:53 的查询,否则系统仍走系统 DNS 拿到真实 IP。stack 用 mixed 时 UDP/TCP 的 53 都要 hijack。fake-ip 与规则引擎的接棒 假地址会架空 IP 规则
还原发生在规则匹配之前,所以域名规则始终命中,而 IP-CIDR/GEOIP 匹配到的是 198.18.x 假地址、几乎永远不中。fake-ip 模式下写规则要忘掉 IP 维度,只信域名。
198.18.0.0/16 的来源 RFC 2544 基准测试段
这段既非公网也非私网,是 RFC 2544 专为网络基准测试保留的 Benchmark block,正常设备不会发包到这段,拿来当假地址永不与真实网络冲突。
衍生角度
设计模式:地址即映射表
先发一个确定性占位地址,把真实语义(域名)推迟到连接时再查。解析从网络往返里挪走,连接直接建在本地表上,零额外 DNS 等待,代价是 IP 维度规则失效。
概念拆解:先假后真 vs 先真后猜
redir-host 先解析出真实 IP 再按 IP 反查域名,共享 IP 下必歧义;fake-ip 干脆不解析,先发 198.18 假地址,连接时再还原域名并解析。一个先真后猜,一个先假后真。
风格架构:三层拦截链
DNS 代答出假地址、连接时查表还原域名、规则引擎按域名分流,三层环环相扣。配置调的不是一个开关,而是让整条寻址链路内聚进内核,TUN 少了 dns-hijack 就断链。
原理分析:泄漏点搬家了
域名只在连接建立时于内核侧解析,客户端到上游 DNS 的查询被内核代答,应用层暴露域名大幅减少。泄漏风险并未消失,只是搬到了 fallback-filter 与 proxy-server-nameserver,别指望 fake-ip 挡一切。
实际用法与坑
- 先 `dig @127.0.0.1 -p 1053 example.com +short`,确认返回 198.18.x 再往下调。
- `fake-ip-filter` 放上 `*.lan`、`*.local`、NTP 域名,否则打印机和 NAS 互相找不到。
- 腾讯登录域名 `localhost.ptlogin2.qq.com` 记得 filter,否则网页登录反复转圈。
- fake-ip 模式下少写 IP-CIDR/GEOIP,域名分流全靠 DOMAIN-SUFFIX 和 RULE-SET。
- TUN 下务必配 `dns-hijack` 截 any:53,否则 DNS 直查拿真 IP,fake-ip 整体失效。
下一步动手做
改自己配置的
dns: 段为 enhanced-mode: fake-ip,在 fake-ip-filter 补上 *.lan、*.local 和腾讯登录域名。mihomo -t 校验后重启,dig 看 198.18.x、curl 验链路,最后开 debug 日志确认 fake-ip -> domain 还原。相关书籍
深入理解计算机系统（CSAPP）
第 11 章网络编程讲清 DNS 解析与 connect 的系统调用链——fake-ip 拦截的正是这两步之间。
TCP/IP 详解（卷1：协议）
第 2 章 DNS 与 CDN 解释 redir-host 为何在共享 IP 下必败,即 fake-ip 诞生的根。