2_DNS解析与FakeIP深度解析

发表于 2025-08-01 更新于 2026-02-15 分类于 3-计算机系统，代理工具阅读次数： Waline：本文字数： 17k 阅读时长 ≈ 16 分钟

代理工具 DNS 体系拆解：加密协议对比、污染机制、redir-host 与 FakeIP 原理、地址池回收与持久化、fallback 决策逻辑、五款工具横向对比、配置实践与排障。

代理规则写了 DOMAIN-SUFFIX,google.com,Proxy，DNS 查询却把域名暴露给了 ISP；开了 TUN 模式，某些应用报 “DNS 解析失败 “。根源相同——DNS 解析发生在代理介入之前。

本文从加密协议讲起，逐层拆解 DNS 污染、FakeIP 机制、fallback 决策逻辑，最后横向对比五款主流工具的实现差异。

1. DNS 覆写与 FakeIP

1.1 两者的关系

DNS 覆写和 FakeIP 是包含关系，不是并列关系：

1
2
3

DNS 覆写（机制层：拦截 DNS 查询）
├── redir-host 模式（策略 A：返回真实 IP）
└── fake-ip 模式（策略 B：返回假 IP）

DNS 覆写是 “ 拦截动作 “——代理工具劫持系统 DNS 查询，用自身 DNS 模块替代系统默认解析，控制 “ 域名→IP” 的映射过程。与恶意 DNS 劫持不同，DNS 覆写由用户主动开启，目的是控制分流和防泄漏。对应配置项 dns.enable: true。

FakeIP 和 redir-host 是 “ 拦截后的应答策略 “——拦截到 DNS 查询后，代理工具有两种回应方式：

redir-host：向上游 DNS 查出真实 IP 返回给应用。对应 dns.enhanced-mode: redir-host
fake-ip：不查询上游，直接从保留地址池分配一个假 IP（如 198.18.0.1）返回。对应 dns.enhanced-mode: fake-ip

类比：DNS 覆写是在大门口设保安，拦截所有进出的快递。保安有两种工作模式——redir-host：帮你查好真实地址再给你；FakeIP：给你一个临时取件码，你先签收，真实地址由后台处理。

1.2 接管 DNS 的必要性

DNS 泄漏：不接管 DNS，ISP 能看到你查询了哪些域名，代理形同虚设
连接延迟：传统模式需先完成 DNS 解析再建立连接，多一轮网络往返
分流准确性：基于 IP 分流不可靠（CDN 返回的 IP 经常变化），基于域名分流才精准
DNS 污染：ISP 或审查系统可能篡改解析结果，导致连接到错误服务器

1.3 全景架构

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#3B82F6', 'primaryTextColor': '#1E3A5F', 'primaryBorderColor': '#2563EB', 'lineColor': '#60A5FA', 'secondaryColor': '#10B981', 'tertiaryColor': '#F59E0B'}}}%%
flowchart TD
    App["应用程序"] -->|"DNS 查询: google.com"| DI{{"DNS 拦截引擎"}}

    DI -->|"redir-host 模式"| RH["真实 DNS 解析"]
    RH --> RHR["返回真实 IP: 142.250.80.46"]
    RHR --> Cache["建立 IP↔域名 映射缓存"]
    Cache --> Route1{{"分流引擎"}}

    DI -->|"fake-ip 模式"| FI["FakeIP 池分配"]
    FI --> FIR["返回假 IP: 198.18.0.5"]
    FIR --> Route2{{"分流引擎"}}

    Route1 -->|"匹配规则"| Proxy1["代理出站"]
    Route1 -->|"直连规则"| Direct1["直接连接"]

    Route2 -->|"查表还原域名"| Proxy2["远端 DNS + 代理出站"]
    Route2 -->|"直连规则"| Direct2["本地 DNS 解析真实 IP + 直连"]

    classDef primary fill:#3B82F6,stroke:#2563EB,color:#fff
    classDef success fill:#10B981,stroke:#059669,color:#fff
    classDef warning fill:#F59E0B,stroke:#D97706,color:#000
    classDef info fill:#0EA5E9,stroke:#0284C7,color:#fff

    class DI primary
    class RH,FI warning
    class Route1,Route2 info
    class Proxy1,Proxy2 success
    class Direct1,Direct2 success

DNS 覆写解决了 “ 谁来回答查询 “ 的问题，但查询本身如果是明文传输，任然可以被窃听和篡改。下一章看看加密协议如何补上这个缺口。

2. DNS 加密协议

传统 DNS（Do53）以明文 UDP 传输查询，任何中间设备都能窥探和篡改。加密 DNS 协议的目标就是封堵这条泄漏通道。

2.1 三种加密协议

DoH（DNS Over HTTPS）

将 DNS 查询封装在标准 HTTPS 请求中，走 443 端口。外部观察者看到的流量和普通网页浏览一致。

1 2	客户端 → HTTPS POST https://dns.google/dns-query → DNS 服务器 (与访问 google.com 的流量特征相同)

流量伪装性强——防火墙很难在不影响正常 HTTPS 的情况下单独封锁 DoH。代价是 HTTP 协议本身带来额外开销（头部、连接管理）。

DoT（DNS Over TLS）

在 TCP 连接上直接建立 TLS 加密通道，使用专用 853 端口。

1 2	客户端 → TLS 连接 :853 → DNS 服务器 (独立端口，容易被识别和封锁)

加密强度与 DoH 等同，但专用端口使其在网络层可被识别。企业环境中管理员可精确控制 DoT 流量；反过来，审查系统也可轻松封锁 853 端口。

DoQ（DNS Over QUIC）

基于 QUIC 协议传输 DNS，走 UDP 端口（通常 8853 或 443）。QUIC 将传输层和加密握手合并为一次往返，天然抗丢包。

1 2	客户端 → QUIC 连接 :443/8853 → DNS 服务器 (单次往返建连，UDP 抗丢包)

性能最优——连接建立只需 1-RTT（首次）或 0-RTT（恢复），实测响应速度比 DoH 快约 10%，仅比明文 DNS 慢 2%。QUIC 的多路复用消除了 TCP 的队头阻塞，移动网络和高丢包环境下优势明显。

2.2 协议对比

维度	DoH	DoT	DoQ
传输协议	TCP (HTTPS)	TCP (TLS)	UDP (QUIC)
默认端口	443	853	8853/443
连接建立	2-3 RTT	2-3 RTT	1 RTT / 0-RTT
抗封锁能力	强（与 HTTPS 混流）	弱（专用端口易识别）	中等（UDP 443 可能被限速）
性能	中等（HTTP 开销）	中等	最优（约快 10%）
抗丢包	差（TCP 重传）	差（TCP 重传）	强（QUIC 前向纠错）
移动端适配	一般	一般	优秀（连接迁移）
生态成熟度	最高（主流浏览器内置）	高（Android 9+ 原生）	较新（AdGuard、NextDNS）

2.3 代理工具中的协议选择

代理场景下，DNS 加密协议的选择逻辑和浏览器场景不同：

DoH 首选：抗封锁能力最强，几乎所有代理工具都支持，配置简单，一个 URL 即可
DoQ 是趋势：sing-box 和 AdGuard Home 已支持，高延迟链路上性能优势明显
DoT 适合内网：可控网络中（如家庭 AdGuard Home），DoT 配置直观且无 HTTP 开销

# Mihomo 加密 DNS 配置示例
nameserver:
  - https://dns.google/dns-query      # DoH
  - tls://8.8.4.4:853                 # DoT
  - quic://dns.adguard.com            # DoQ（需工具支持）

加密协议保护了传输通道，但如果查询以明文方式发出，在到达加密通道之前就已经被截获了。这正是 DNS 污染的手段。

3. DNS 污染机制

3.1 传统 DNS 的三个隐患

没有代理工具介入时，DNS 查询面临三重威胁：

%%{init: {'theme': 'base', 'themeVariables': {'actorBkg': '#3B82F6', 'actorTextColor': '#fff', 'actorBorder': '#2563EB', 'signalColor': '#60A5FA', 'activationBkgColor': '#DBEAFE', 'activationBorderColor': '#3B82F6'}}}%%
sequenceDiagram
    autonumber
    participant App as "应用程序"
    participant OS as "系统 DNS"
    participant ISP as "ISP DNS"
    participant GFW as "审查系统"

    App->>OS: "查询 google.com"
    OS->>ISP: "请求解析 google.com（明文 UDP）"

    Note over ISP: "隐患1: ISP 完整记录查询域名"

    par "ISP 正常响应"
        ISP-->>OS: "返回真实 IP（较慢）"
    and "GFW 旁路抢答"
        GFW-->>OS: "伪造响应: 93.46.8.89（更快到达）"
    end

    Note over OS: "隐患2: 系统采信先到达的伪造响应"

    OS-->>App: "解析结果: 93.46.8.89"
    App->>App: "连接 93.46.8.89"
    Note over App: "隐患3: 连接错误服务器"

3.2 GFW DNS 污染的工作原理

GFW 的 DNS 污染并非 “ 劫持 DNS 服务器 “，而是旁路注入——在网络链路上旁听经过的 DNS 查询包，抢先发送伪造响应。

旁路监听：GFW 设备部署在国际出口骨干网上，以旁路（非串联）方式镜像流量。它不需要 “ 经手 “ 数据包，只需要 “ 看到 “
关键词匹配：检测 DNS 查询包中的域名是否命中黑名单（如 google.com、youtube.com）
抢先注入：一旦命中，伪造一个 DNS 响应包，源地址设为你请求的 DNS 服务器 IP，发送给客户端
时序竞争：伪造包从 GFW 设备直接发出，网络路径短，几乎总是比真实 DNS 响应先到达。UDP 协议无状态，系统接受先到的包并丢弃后到的

为什么用 8.8.8.8 也会被污染？因为 GFW 不拦截请求，只是在旁路注入假响应。请求确实发给了 8.8.8.8，Google DNS 也确实返回了正确结果——但假响应先到了，系统已经采信。

3.3 已知投毒 IP 段

GFW 注入的伪造 IP 并不随机，集中在固定网段。这些 IP 的共同特征是：不属于任何正常 CDN、地理位置分散、端口不通。

IP 段	特征
`93.46.8.x`	意大利 IP 段，经典污染地址
`203.98.7.x`	新西兰 IP 段
`243.185.187.x`	保留地址段
`8.7.198.x`	Level 3 网段
`78.16.49.x`	英国 IP 段
`159.106.121.x`	韩国 IP 段
`240.0.0.0/4`	IANA 保留段，正常网络绝不会出现

代理工具的 fallback-filter 正是利用这个特征：如果 nameserver 返回的 IP 命中这些已知污染段，就改用 fallback 的结果。

3.4 防污染策略

策略	原理	适用场景
加密 DNS（DoH/DoT/DoQ）	GFW 无法读取加密查询内容	所有场景首选
FakeIP 模式	代理域名根本不发起 DNS 查询	代理工具用户
fallback-filter	检测并丢弃污染结果	redir-host 模式
DNS over TCP	部分规避（GFW 也能注入 TCP RST）	备选方案

理解了污染机制和防护手段后，接下来看代理工具的两种 DNS 应答模式是如何运作的。

4. Redir-host 模式

4.1 数据流

代理工具接管 DNS，通过加密通道向上游查询真实 IP：

%%{init: {'theme': 'base', 'themeVariables': {'actorBkg': '#3B82F6', 'actorTextColor': '#fff', 'actorBorder': '#2563EB', 'signalColor': '#60A5FA', 'activationBkgColor': '#DBEAFE', 'activationBorderColor': '#3B82F6'}}}%%
sequenceDiagram
    autonumber
    participant App as "应用程序"
    participant Clash as "Clash DNS 模块"
    participant DoH as "加密 DNS (DoH)"
    participant Engine as "分流引擎"
    participant Proxy as "代理服务器"

    App->>Clash: "查询 google.com"
    Clash->>DoH: "加密查询 google.com"
    DoH-->>Clash: "返回真实 IP: 142.250.80.46"

    Clash->>Clash: "缓存 142.250.80.46 ↔ google.com"
    Clash-->>App: "返回 142.250.80.46"

    App->>Engine: "连接 142.250.80.46:443"
    Engine->>Engine: "查缓存: 142.250.80.46 → google.com"
    Engine->>Engine: "匹配规则: google.com → Proxy"
    Engine->>Proxy: "CONNECT google.com:443"

4.2 优缺点

优点：应用拿到真实 IP，兼容性好。对 IP 敏感的应用（如某些游戏、P2P 软件）能正常工作。

缺点：

延迟高：每次新域名查询都要等上游 DNS 返回，多一轮网络往返
IP↔域名映射不稳定：大型 CDN（如 Cloudflare）让数千个域名共享同一个 IP，代理工具无法准确还原域名。这就是 redir-host 模式偶尔出现 “ 访问 A 站却打开 B 站 “ 的根因
DNS 提供商可见查询内容：虽然传输通道加密，但 DoH/DoT 提供商仍能看到你查了什么域名

redir-host 的 CDN 共享 IP 问题促成了 FakeIP 方案的诞生——用假 IP 做一一映射，彻底回避域名歧义。

5. FakeIP 模式

5.1 数据流

FakeIP 跳过本地 DNS 解析，将域名解析延迟到代理服务器端完成：

%%{init: {'theme': 'base', 'themeVariables': {'actorBkg': '#10B981', 'actorTextColor': '#fff', 'actorBorder': '#059669', 'signalColor': '#34D399', 'activationBkgColor': '#D1FAE5', 'activationBorderColor': '#10B981'}}}%%
sequenceDiagram
    autonumber
    participant App as "应用程序"
    participant Clash as "Clash FakeIP 模块"
    participant Engine as "分流引擎"
    participant Proxy as "代理服务器"
    participant Remote as "远端 DNS"
    participant LocalDNS as "本地 DNS"

    App->>Clash: "查询 google.com"
    Clash->>Clash: "从 198.18.0.1/16 池分配 198.18.0.5"
    Clash->>Clash: "记录 198.18.0.5 ↔ google.com"
    Clash-->>App: "立即返回 198.18.0.5"

    Note over App,Clash: "零延迟响应，无网络往返"

    App->>Engine: "连接 198.18.0.5:443"
    Engine->>Engine: "查 FakeIP 表: 198.18.0.5 → google.com"

    alt "匹配代理规则"
        Engine->>Proxy: "CONNECT google.com:443"
        Proxy->>Remote: "解析 google.com"
        Remote-->>Proxy: "142.250.80.46"
        Proxy->>Proxy: "连接 142.250.80.46:443"
    else "匹配直连规则"
        Engine->>LocalDNS: "解析 google.com 获取真实 IP"
        LocalDNS-->>Engine: "142.250.80.46"
        Engine->>Engine: "直连 142.250.80.46:443"
    end

三个优势：

DNS 响应零延迟——应用瞬间拿到结果，彻底消除 DNS 解析等待
域名信息完整——假 IP 和域名一一对应，分流精准，不存在 CDN 共享 IP 导致的域名歧义
DNS 泄漏风险极低——代理域名完全不触发本地 DNS 查询（直连域名仍通过本地 DNS 解析）

5.2 地址池与分配机制

FakeIP 使用 IANA 为基准测试保留的地址段 198.18.0.0/15（RFC 2544），正常互联网路由器不会转发这个段的数据包。选用这个段的原因：不与真实地址冲突、地址数量充足（/15 提供约 131,072 个地址）、即使泄漏也不影响正常网络。

Mihomo 默认使用 198.18.0.1/16（约 65,534 个有效地址）作为子池：

配置项	默认值	说明
地址池范围	`198.18.0.1/16`	IPv4 可用 IP 约 65,534 个
IPv6 池	`fc00::/18`（可选）	IPv6 FakeIP 地址段
TTL	1 秒	极短 TTL，防止应用长期缓存假 IP

分配流程：

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#3B82F6', 'primaryTextColor': '#1E3A5F', 'primaryBorderColor': '#2563EB', 'lineColor': '#60A5FA'}}}%%
flowchart TD
    Q["收到 DNS 查询: example.com"] --> C1{"映射表中已存在?"}
    C1 -->|"是"| R1["直接返回已分配的假 IP"]
    C1 -->|"否"| C2{"地址池有空闲?"}
    C2 -->|"是"| A["顺序分配下一个 IP"]
    C2 -->|"否"| LRU["LRU 回收最久未使用的映射"]
    LRU --> A
    A --> W["写入映射表: 198.18.x.x ↔ example.com"]
    W --> R2["返回假 IP，TTL=1s"]

    classDef primary fill:#3B82F6,stroke:#2563EB,color:#fff
    classDef warning fill:#F59E0B,stroke:#D97706,color:#000
    classDef success fill:#10B981,stroke:#059669,color:#fff

    class Q primary
    class C1,C2 warning
    class R1,R2 success
    class LRU warning

5.3 LRU 回收策略

地址池有限（65,534 个），但互联网域名无限。当池满时，代理工具使用 LRU（Least Recently Used）策略回收：

淘汰最久没有被查询的域名映射
将其 IP 地址重新分配给新域名
同一域名短期内再次查询，返回相同的假 IP（缓存命中）

65,534 个地址远超日常需求——普通用户一天接触的独立域名很少超过几千个。地址耗尽只可能出现在恶意软件大量随机查询域名（DGA 攻击）的极端情况。

5.4 持久化存储

FakeIP 映射的持久化是容易被忽略的细节。代理工具重启后，之前的映射表清空。如果应用内缓存了旧的假 IP（如 198.18.0.5 ↔ google.com），重启后再连接 198.18.0.5，代理工具查表找不到对应域名，连接失败，表现为重启后短暂的网络中断。

各工具的处理方式：

工具	持久化	实现方式
Mihomo	可选，`store-fake-ip: true`	映射表写入磁盘文件，重启后加载
sing-box	内存缓存为主	依赖 `cache_capacity` 控制缓存大小
Surge	自动管理	VIF 模式内部维护，用户无需配置
OpenClash	跟随 Mihomo 配置	通过 Mihomo 内核实现

开启持久化的代价是磁盘 I/O 增加，对 SSD 设备影响可忽略。路由器等闪存设备应谨慎评估，频繁写入会缩短闪存寿命。

5.5 两种模式对比

维度	redir-host	fake-ip
DNS 解析时机	收到查询时立即解析	延迟到代理服务器端
返回给应用的 IP	真实 IP	假 IP（198.18.x.x）
连接速度	较慢（多一轮 DNS 往返）	更快（即时响应）
域名还原方式	IP↔域名映射表还原（可能歧义）	假 IP 直接映射域名（精确一一对应）
DNS 泄漏风险	较高（本地解析可能泄漏）	极低（代理域名不触发本地查询）
兼容性	高（应用拿到真实 IP）	中等（某些应用缓存 IP 或 WebRTC 不兼容）
适用场景	需要真实 IP 的特殊应用	日常代理，追求速度和隐私

了解了两种模式的差异后，还需要理清一次 DNS 查询在代理工具内部走过的完整路径——这直接决定了排障的切入点。

6. DNS 全链路时序

从 DNS 查询到连接建立，代理工具内部经过多层判断。理解这个链路对排障至关重要。

6.1 完整链路

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#3B82F6', 'primaryTextColor': '#1E3A5F', 'primaryBorderColor': '#2563EB', 'lineColor': '#60A5FA', 'secondaryColor': '#10B981', 'tertiaryColor': '#F59E0B'}}}%%
flowchart TD
    Start["应用发起 DNS 查询: example.com"] --> FakeIPCheck{"FakeIP 模式?"}

    FakeIPCheck -->|"是"| FilterCheck{"命中 fake-ip-filter?"}
    FilterCheck -->|"是（如 *.lan）"| RealDNS["走真实 DNS 解析"]
    FilterCheck -->|"否"| AssignFake["分配假 IP 并返回"]

    FakeIPCheck -->|"否（redir-host）"| NSPolicy{"命中 nameserver-policy?"}
    NSPolicy -->|"是（如 +.cn）"| SpecDNS["用指定 DNS 解析"]
    NSPolicy -->|"否"| ParallelDNS["并发查询 nameserver + fallback"]

    ParallelDNS --> NSResult["nameserver 返回结果"]
    ParallelDNS --> FBResult["fallback 返回结果"]

    NSResult --> FBFilter{"fallback-filter 检查"}
    FBFilter -->|"nameserver 结果可信"| UseNS["采用 nameserver 结果"]
    FBFilter -->|"疑似污染"| UseFB["采用 fallback 结果"]

    SpecDNS --> ReturnIP["返回解析 IP"]
    RealDNS --> ReturnIP
    UseNS --> ReturnIP
    UseFB --> ReturnIP
    AssignFake --> ReturnIP2["返回假 IP"]

    ReturnIP --> ConnectReal["应用发起连接"]
    ReturnIP2 --> ConnectFake["应用发起连接"]

    ConnectReal --> RuleMatch{{"分流规则匹配"}}
    ConnectFake --> RuleMatch

    RuleMatch -->|"PROXY"| ProxyOut["代理出站"]
    RuleMatch -->|"DIRECT"| DirectOut["直连出站"]

    classDef primary fill:#3B82F6,stroke:#2563EB,color:#fff
    classDef success fill:#10B981,stroke:#059669,color:#fff
    classDef warning fill:#F59E0B,stroke:#D97706,color:#000
    classDef info fill:#0EA5E9,stroke:#0284C7,color:#fff

    class Start primary
    class FakeIPCheck,NSPolicy,FilterCheck,FBFilter warning
    class ProxyOut,DirectOut success
    class RuleMatch info

6.2 Fallback 与 Fallback-filter 决策逻辑

fallback 不是 “ 备胎 DNS”，它和 nameserver 是并发查询的。Mihomo 同时向两方发请求，然后用 fallback-filter 判断采信哪个结果。

决策规则（Mihomo 实现）：

nameserver 和 fallback 同时发起查询
等待 nameserver 返回结果，用 fallback-filter 检查
如果 nameserver 结果通过检查 → 采用 nameserver 的结果
如果 nameserver 结果未通过检查 → 等待 fallback 结果并采用

fallback-filter 的检查条件（满足任一则判定为 “ 疑似污染 “）：

fallback-filter:
  geoip: true        # 条件1: 返回的 IP 经 GeoIP 查询不在 CN → 疑似污染
  geoip-code: CN
  ipcidr:             # 条件2: 返回的 IP 命中这些段 → 确认污染
    - 240.0.0.0/4     # IANA 保留段
    - 0.0.0.0/32      # 无效地址
    - 127.0.0.1/32    # 回环地址
  domain:             # 条件3: 这些域名强制走 fallback
    - "+.google.com"
    - "+.youtube.com"

设计意图：nameserver 配国内 DNS（如 AliDNS），解析国内域名时返回 CN IP，通过 GeoIP 检查，直接采信（速度快）。解析被污染域名时返回的假 IP 不在 CN，触发 fallback，转为采用海外 DNS 的正确结果。

6.3 Nameserver-policy 分流

nameserver-policy 为特定域名指定专用 DNS 服务器，绕过 nameserver/fallback 流程：

nameserver-policy:
  "+.cn": "https://dns.alidns.com/dns-query"      # 所有 .cn 域名走阿里 DNS
  "geosite:cn": "https://dns.alidns.com/dns-query" # GeoSite 中国域名集
  "+.internal.company.com": "10.0.0.1"             # 公司内网域名走内网 DNS

命中 nameserver-policy 的域名不会触发 fallback 流程——显式指定了 DNS 服务器，代理工具假设结果可信。

6.4 常见误判场景

场景 1：国内域名被误判为污染

症状：访问国内网站偶现卡顿。原因：某些国内 CDN 返回的 IP 经 GeoIP 查询不在 CN（如使用了香港 CDN 节点），触发 fallback，换用海外 DNS 解析，反而拿到更远的节点。调优：将这类域名加入 nameserver-policy，指定国内 DNS 直接解析。

场景 2：fallback DNS 不可用导致解析超时

症状：被污染域名长时间无法解析。原因：fallback 中配置的海外 DNS 全部不通（网络封锁升级时常发生）。调优：fallback 中配置多个不同地区的 DNS，包括不同协议（DoH + DoT），增加冗余。

场景 3：GeoIP 数据库过期

症状：分流异常，本该直连的域名走了代理。原因：GeoIP 数据库中 IP 归属地信息过时，新分配的 CN IP 段未被收录。调优：定期更新 geoip.dat / GeoLite2-Country.mmdb 数据库文件。

机制讲完了，下面横向对比主流工具在 DNS/FakeIP 上的实现差异。

7. 配置实践与排障

7.1 Mihomo 完整 DNS 配置

dns:
  enable: true            # 开启 DNS 模块
  listen: 0.0.0.0:53      # 监听端口
  enhanced-mode: fake-ip  # fake-ip 或 redir-host

  # FakeIP 配置
  fake-ip-range: 198.18.0.1/16
  store-fake-ip: true     # 持久化 FakeIP 映射（推荐 SSD 设备开启）

  # FakeIP 排除列表（这些域名返回真实 IP）
  fake-ip-filter:
    - "*.lan"             # 局域网设备
    - "*.local"           # mDNS（Bonjour 服务发现）
    - "*.direct"          # 直连标记
    - "+.msftconnecttest.com"  # Windows 网络连接检测
    - "+.msftncsi.com"
    - "dns.msftncsi.com"
    - "www.msftncsi.com"
    - "+.ntp.org"         # NTP 时间同步
    - "+.pool.ntp.org"
    - "ntp.ubuntu.com"
    - "+.stun.*.*"        # STUN/TURN（WebRTC、VoIP）
    - "+.stun.*.*.*"
    - "localhost.ptlogin2.qq.com"  # QQ 登录
    - "*.logon.battlenet.com.cn"   # 暴雪战网
    - "*.logon.battle.net"

  # 主 DNS（国内 DNS，解析国内域名快）
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query

  # 备用 DNS（海外 DNS，解析被污染域名）
  fallback:
    - https://dns.google/dns-query
    - https://1.0.0.1/dns-query
    - tls://8.8.4.4:853

  # fallback 触发条件
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4
      - 0.0.0.0/32
      - 127.0.0.1/32
    domain:
      - "+.google.com"
      - "+.youtube.com"
      - "+.github.com"

  # 域名级 DNS 分流
  nameserver-policy:
    "+.cn": "https://dns.alidns.com/dns-query"
    "geosite:cn": "https://dns.alidns.com/dns-query"

配置逻辑：nameserver 和 fallback 并发查询。国内域名经 nameserver（阿里/腾讯 DNS）解析，GeoIP 判定 CN，直接采信。海外域名经 nameserver 解析后 IP 不在 CN，触发 fallback-filter，改用 fallback（Google/Cloudflare DNS）的结果。nameserver-policy 中的域名跳过 fallback 流程。

7.2 实战案例：nslookup 返回 198.18.x.x

路由器开了 OpenClash 的 FakeIP 模式后，执行 nslookup 看到异常 IP：

$ nslookup jump.example.xyz 114.114.114.114
Server:   114.114.114.114
Address:  114.114.114.114#53

Name:     jump.example.xyz
Address:  198.18.61.81      # ← 不是预期的真实 IP

虽然命令中指定了 114.114.114.114，返回的仍然是假 IP。原因：OpenClash 通过 iptables/nftables 在网络层劫持了所有目标端口 53 的 UDP/TCP 包，nslookup 指定的 DNS 服务器形同虚设——查询包离开系统后就被截获。

完整路径：

%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#3B82F6', 'primaryTextColor': '#1E3A5F', 'primaryBorderColor': '#2563EB', 'lineColor': '#60A5FA'}}}%%
flowchart TD
    A["电脑发起 DNS 查询"] --> B["路由器收到请求"]
    B --> C["OpenClash 通过 iptables 劫持 53 端口"]
    C --> D["分配假 IP: 198.18.61.81"]
    D --> E["记录映射: 198.18.61.81 ↔ jump.example.xyz"]
    E --> F["返回 198.18.61.81 给电脑"]
    F --> G["电脑向 198.18.61.81 发送数据"]
    G --> H["OpenClash 截获，查映射表还原域名"]
    H --> I{{"匹配分流规则"}}
    I -->|"代理规则"| J["通过代理解析真实 IP 并转发"]
    I -->|"直连规则"| K["本地解析真实 IP 并直连"]

    classDef primary fill:#3B82F6,stroke:#2563EB,color:#fff
    classDef success fill:#10B981,stroke:#059669,color:#fff
    classDef warning fill:#F59E0B,stroke:#D97706,color:#000
    classDef info fill:#0EA5E9,stroke:#0284C7,color:#fff

    class A,B info
    class C,D,E warning
    class F,G primary
    class H,I primary
    class J,K success

FakeIP 模式下 OpenClash 不区分域名——只要有 DNS 查询且域名不在 fake-ip-filter 白名单中，一律返回假 IP，保证分流精准、抗 DNS 污染、防地址泄漏。

如需调试时看到真实 IP，可将域名加入 fake-ip-filter，但日常使用不建议关闭。

7.3 常见问题排查

问题	现象	原因	解决方案
ping 返回 198.18.x.x	以为代理故障	`ping` 用 ICMP 不走代理，FakeIP 返回假 IP 正常	用 `curl -I https://google.com` 验证代理
内网设备发现失败	mDNS / SSDP 不工作	`.local`、`.lan` 被分配了假 IP	加入 `fake-ip-filter`
双重 DNS 拦截	解析异常，延迟高	路由器 OpenClash + 设备 Clash 双重截获	二选一，避免套娃
WebRTC 泄漏真实 IP	隐私泄漏	浏览器 WebRTC 绕过代理直接建立 P2P 连接	安装 WebRTC 防泄漏扩展
重启后短暂断网	几秒内网络中断	映射表清空，应用缓存的假 IP 失效	开启 `store-fake-ip: true`
某些 App 无法登录	银行/金融类 App 异常	应用校验 IP 归属地，假 IP 不通过校验	将 App 域名加入 `fake-ip-filter`

系列导航 | ← 上一篇：代理模式与 TUN | 下一篇：协议深度解析 →