Q3000 + R4S 分流终极指南：同一套大陆 IP 分流下的两种 DNS 方案

2026年10月4日网络教程

客户端默认网关使用 Q3000 192.168.10.1，DNS 使用 R4S 192.168.10.3。Q3000 根据大陆 IPv4 库决定国内流量直接走 WAN，其余流量交给 R4S/Nikki/Mihomo。本文完整比较两种 DNS 子方案：已经验证运行的“dnsmasq 选择性转发”，以及配置更集中的“Mihomo 全权解析”。

一、先给出结论

本文讨论的不是两套完全不同的网络，而是同一个大方案下的两种 DNS 实现。

大方案始终不变：

text

客户端 IP：192.168.10.100-192.168.10.200
默认网关：192.168.10.1（Q3000）
DNS：192.168.10.3（R4S dnsmasq）

Q3000 判断目标 IP：
大陆 IP → WAN1 直接出网
其他 IP → 下一跳 192.168.10.3 → R4S/Nikki/Mihomo

两种 DNS 子方案如下：

子方案	DNS 的第一判断者	国内 DNS 是否依赖 Mihomo	手工维护内容	当前状态
A：dnsmasq 选择性转发	dnsmasq	否	`services.googleapis.cn` 一条例外	已验证，正在使用
B：Mihomo 全权解析	Mihomo	是	Nikki YAML	可行，但尚未切换

当前更推荐方案 A。它已经解决淘宝、微信、Google、YouTube、Google SSH、Muse、Google Play 等实际问题，而且 Nikki/Mihomo 单独停止时，普通国内 DNS 仍可工作。

方案 B 的优点是配置集中、重装项目更少；代价是 Mihomo 会成为全网 DNS 的单点。它适合愿意为配置统一性接受这一故障范围的人。

二、先分清 Q3000、R4S、Nikki、Mihomo 和 dnsmasq

text

Q3000（主路由）
├─ 负责 WAN 拨号和 NAT
├─ 负责 DHCP、Wi-Fi、VLAN 和客户端管理
├─ 保存大陆 IPv4 分组
└─ 根据目标 IP 决定 WAN1 直连或下一跳 R4S

R4S（硬件设备）
└─ ImmortalWrt/OpenWrt（操作系统）
   ├─ dnsmasq（监听 192.168.10.3:53，接收客户端 DNS 查询）
   ├─ Tailscale（独立的组网服务）
   └─ Nikki（代理管理插件）
      └─ Mihomo（真正执行 DNS、Fake-IP、规则匹配和代理连接的核心）

用通俗的话说：

Q3000 是总路口，负责决定真实业务流量往哪里走。
dnsmasq 是 DNS 前台，负责接收客户端“这个域名对应什么 IP”的问题。
Nikki 是管理 Mihomo 的控制系统，不是代理内核本身。
Mihomo 才是代理内核，也可以提供 DNS 和 Fake-IP 服务。
Zashboard 只是 Mihomo 的控制面板，不负责实际转发。

“数据包到达 R4S”不等于“已经使用代理节点”。数据包还要被 Nikki 的透明代理规则接管，再由 Mihomo 根据 YAML 规则决定使用代理或 DIRECT。

三、Q3000 的大陆 IP 分流如何触发

1. 大陆 IP 数据放在哪里

Q3000 中保存了约 6200 条大陆 IPv4 网段。为了适应设备的对象容量，它们被拆成八个 IP 分组：

text

CN4-A01
CN4-A02
CN4-A03
CN4-A04
CN4-A05
CN4-A06
CN4-A07
CN4-A08

这些分组只是“地址资料库”，本身不会主动改变流量方向。

2. 真正引用 IP 库的是两条规则

Q3000 当前的核心规则是：

text

优先级 0：CodexCNDirect
来源地址：192.168.10.100-192.168.10.200
目标地址：CN4-A01～CN4-A08
动作：WAN1 直接出网

text

优先级 1：CodexR4S
来源地址：192.168.10.100-192.168.10.200
目标地址：任意
动作：下一跳 192.168.10.3

客户端每建立一个连接，Q3000 都会用数据包中的“来源 IP”和“目标 IP”匹配规则：

text

先检查 CodexCNDirect
  ↓
目标 IP 属于大陆 IPv4 库
  → WAN1 直接出网

目标 IP 不属于大陆 IPv4 库
  ↓
继续检查 CodexR4S
  → 下一跳交给 R4S

匹配工作由 Q3000 自己的路由引擎实时完成，不需要电脑脚本持续运行。此前的脚本只负责下载 IP 库、创建八个对象并建立两条引用规则。

3. “被引用次数 1”不是访问次数

IP 分组中的“被引用次数”表示有多少条配置规则正在使用这个分组：

text

CN4-A01 被 CodexCNDirect 引用
→ 被引用次数为 1

访问淘宝一万次仍然是 1。只有再创建一条规则并引用 CN4-A01，它才会变成 2。真正的流量和连接数量应在 Q3000 的终端监控、连接监控或流量统计中查看。

四、一次上网请求其实分为两个阶段

很多误解来自把 DNS 查询和网页流量混成一件事。实际上每次访问通常包含两个阶段。

第一阶段是查询地址：

text

“taobao.com 对应哪个 IP？”

第二阶段才是真正访问：

text

“向刚才得到的 IP 建立 TCP、TLS、QUIC 或其他连接。”

DNS 服务器只负责回答地址，不承担网页、视频和下载数据。默认网关只处理真正的数据连接，不负责替客户端理解域名。

下面分别展开两种 DNS 子方案。

五、方案 A：dnsmasq 选择性转发

这是当前已经验证、正在使用的方案。

1. 核心结构

所有客户端都向 192.168.10.3:53 查询 DNS，但 dnsmasq 会先分类：

text

客户端 DNS 查询
  ↓
R4S dnsmasq
  ├─ 命中自动代理域名表
  │    → 127.0.0.1:1053 → Mihomo DNS
  │
  ├─ 命中自定义插件例外
  │    → 127.0.0.1:1053 → Mihomo DNS
  │
  └─ 没有命中
       → 223.5.5.5 / 223.6.6.6
       → 返回真实 IP

自动代理域名表来自 Loyalsoldier 的 gfw.txt，当前约 4393 条，通过以下程序每天更新：

text

更新程序：/usr/local/sbin/update-gfw-dnsmasq
定时任务：每天 04:17
生成文件：/etc/dnsmasq.d/gwf-gfwlist.conf

更新程序会拒绝安装少于 3000 条的不完整列表。因此这四千多条不需要人工逐条维护。

自定义插件只维护自动列表没有收录的特殊例外：

text

服务 → 域名分流
当前只保留：services.googleapis.cn
数据文件：/etc/dnsmasq.d/gwf-ui.conf

2. 国内请求：第一阶段，DNS 查询

以手机打开淘宝为例：

text

淘宝 App（准备访问 taobao.com）
  ↓
手机系统 DNS 缓存（检查是否已有未过期答案）
  ↓ 缓存没有可用答案
手机网络系统（生成查询 taobao.com 的 DNS 数据包）
  ↓
手机 Wi-Fi 网卡（把 DNS 数据包发送给 DNS 服务器 192.168.10.3）
  ↓
无线 AP / K2P（只负责交换和转发局域网数据）
  ↓
R4S 网卡（收到目标端口为 53 的 DNS 查询）
  ↓
R4S Linux 网络系统（把本机 53 端口查询交给 dnsmasq）
  ↓
dnsmasq（检查本地缓存、Hosts、自动代理域名表和插件例外）
  ↓ taobao.com 没有命中代理域名表
dnsmasq（把查询发给默认上游 223.5.5.5 或 223.6.6.6）
  ↓
R4S 默认路由（把上游 DNS 查询交给 Q3000 192.168.10.1）
  ↓
Q3000 WAN（将查询发送到互联网中的国内 DNS）
  ↓
国内上游 DNS（返回 taobao.com 的真实 IP）
  ↓
Q3000（收到 DNS 回应并转回 R4S）
  ↓
R4S dnsmasq（缓存答案，并生成发往手机的 DNS 回应）
  ↓
无线 AP / K2P（把局域网回应转交手机）
  ↓
手机系统 DNS 缓存（保存 taobao.com 的真实 IP）
  ↓
淘宝 App（取得真实大陆 IP）

这一阶段 R4S 参与了 DNS，但 Mihomo 没有参与。

3. 国内请求：第二阶段，真实业务流量

text

淘宝 App（向刚才得到的真实大陆 IP 发起 HTTPS/QUIC 连接）
  ↓
手机网络系统（发现目标不在本地网段，需要交给默认网关）
  ↓
手机 Wi-Fi 网卡（把真实业务数据发给默认网关 192.168.10.1）
  ↓
无线 AP / K2P（把数据转交 Q3000）
  ↓
Q3000（读取来源 IP 和目标 IP）
  ↓
CodexCNDirect（发现目标 IP 位于 CN4-A01～CN4-A08）
  ↓
Q3000 WAN1 与 NAT（把客户端私网地址转换成宽带出口地址）
  ↓
运营商网络（把连接送到淘宝服务器）
  ↓
淘宝服务器（返回网页、图片、视频或接口数据）
  ↓
Q3000 连接跟踪与 NAT 还原（确认回应属于原客户端）
  ↓
无线 AP / K2P（把回应转交手机）
  ↓
淘宝 App（收到真实业务数据）

真正的淘宝流量没有进入 R4S、Nikki 或 Mihomo。

4. 国外请求：第一阶段，DNS 查询

以手机打开 Google 为例：

text

浏览器或 Google App（准备访问 google.com）
  ↓
手机系统 DNS 缓存（没有可用答案）
  ↓
手机网络系统（生成查询 google.com 的 DNS 数据包）
  ↓
手机 Wi-Fi 网卡（发送给 DNS 服务器 192.168.10.3）
  ↓
无线 AP / K2P（转交 R4S）
  ↓
R4S 网卡与 Linux 网络系统（把 53 端口查询交给 dnsmasq）
  ↓
dnsmasq（发现 google.com 命中自动代理域名表）
  ↓
dnsmasq（把查询转交本机 127.0.0.1:1053）
  ↓
Mihomo DNS（检查 DNS 缓存、nameserver-policy 和 Fake-IP 规则）
  ↓
Mihomo Fake-IP 映射表（为 google.com 分配并记录 198.18.x.x）
  ↓
Mihomo DNS（把 198.18.x.x 返回给 dnsmasq）
  ↓
dnsmasq（把 Fake-IP 回答发送给手机）
  ↓
手机系统 DNS 缓存（记录 google.com = 198.18.x.x）
  ↓
浏览器或 Google App（取得 Fake-IP）

Fake-IP 不是 Google 的真实服务器地址，而是 Mihomo 给该域名发放的内部号码牌。

5. 国外请求：第二阶段，真实业务流量

text

浏览器或 Google App（向 198.18.x.x:443 发起 HTTPS/QUIC 连接）
  ↓
手机网络系统（把连接交给默认网关 192.168.10.1）
  ↓
无线 AP / K2P（转交 Q3000）
  ↓
Q3000（检查目标 IP）
  ↓
CodexCNDirect（198.18.x.x 不属于大陆 IP 库，因此不匹配）
  ↓
CodexR4S（兜底匹配，将连接的下一跳设为 192.168.10.3）
  ↓
R4S 网卡（收到 Q3000 转来的业务连接）
  ↓
Nikki 防火墙与透明代理规则（把连接交给 Mihomo）
  ↓
Mihomo Fake-IP 映射表（查出 198.18.x.x 对应 google.com）
  ↓
Mihomo 规则引擎（命中 Google 规则和对应策略组）
  ↓
Mihomo 代理节点（建立加密代理连接）
  ↓
R4S 默认路由（把代理节点连接交给 Q3000）
  ↓
Q3000（发现来源是 R4S，不再送回 R4S，直接从 WAN1 出网）
  ↓
代理节点（代表家庭网络访问 Google 真实服务器）
  ↓
返回数据沿代理隧道回到 R4S/Mihomo
  ↓
Mihomo（解密并交还原始客户端连接）
  ↓
Q3000 / 局域网交换路径（把回应送回手机）
  ↓
浏览器或 Google App（收到 Google 内容）

6. Google Play 特例的完整流程

services.googleapis.cn 是国外服务使用中国域名和大陆地址的特殊情况。若按普通国内域名处理，它会返回类似 211.95.34.139 的大陆真实 IP，Q3000 随即直接走 WAN，导致 Google Play 的控制连接和下载连接使用不同出口，下载卡在 1%。

插件中加入该域名后：

text

Google Play（查询 services.googleapis.cn）
  ↓
R4S dnsmasq（命中插件自定义规则）
  ↓
Mihomo DNS 1053（返回 198.18.x.x Fake-IP）
  ↓
手机（向 Fake-IP 发起 Play 下载连接）
  ↓
Q3000（Fake-IP 不属于大陆 IP，交给 R4S）
  ↓
Nikki/Mihomo（还原 services.googleapis.cn 并使用 Google 代理策略）
  ↓
Google Play（正常高速下载）

这一条已经经过多次实际测试：删除就无法下载，恢复后立即正常。

7. 方案 A 的故障边界

text

Mihomo停止，但 R4S 和 dnsmasq 正常
→ 普通国内 DNS 仍可通过 223.5.5.5/223.6.6.6 解析
→ 国内真实流量仍由 Q3000 直接出网
→ 自动代理名单和插件例外无法正常使用

text

整个 R4S断电或 dnsmasq停止
→ 客户端配置的 DNS 192.168.10.3 不可用
→ 国内外新域名都无法正常解析

因此方案 A 只能隔离“Mihomo 进程故障”，不能抵抗“R4S 整机故障”。

六、方案 B：所有 DNS 全权交给 Mihomo

这是一套可行但尚未正式切换的替代方案。它不是让所有真实流量都经过 R4S，而是让所有 DNS 查询都先经过 Mihomo。

1. 核心结构

text

客户端所有 DNS 查询
  ↓
R4S dnsmasq 192.168.10.3:53
  ↓ 无条件转发
Mihomo DNS 127.0.0.1:1053
  ↓
Mihomo 根据规则返回真实 IP 或 Fake-IP
  ↓
Q3000 根据最终 IP 决定 WAN1 或 R4S

Mihomo不是权威 DNS 数据库。它仍然需要向上游 DNS 查询，只是由它选择上游并决定最终向客户端返回真实 IP 还是 Fake-IP：

text

cn_domain → 阿里 DNS / 腾讯 DNS 等国内上游
geolocation-!cn → Google / Cloudflare 等国外 DoH 上游

2. 为什么不能直接把所有 DNS 转给当前 Mihomo

当前配置使用：

yaml

fake-ip-filter-mode: blacklist

在 blacklist 模式下，fake-ip-filter 是“不返回 Fake-IP”的例外名单。命中列表返回真实 IP，其他域名默认返回 Fake-IP。

如果不修改 YAML 就把所有 DNS 都转给 Mihomo，很多没有进入例外名单的国内域名也会获得 Fake-IP，随后被 Q3000 交给 R4S，国内直连优势会被削弱。

因此需要改成 Mihomo 支持的规则模式：

yaml

dns:
  fake-ip-filter-mode: rule
  fake-ip-filter:
    - DOMAIN,services.googleapis.cn,fake-ip
    - RULE-SET,fakeipfilter_domain,real-ip
    - RULE-SET,cn_domain,real-ip
    - RULE-SET,geolocation-!cn,fake-ip
    - MATCH,real-ip

注意：这段内容应替换现有 dns: 中的 fake-ip-filter-mode 和 fake-ip-filter，不能再增加第二个 dns:。

持久配置应修改：

text

/etc/nikki/profiles/nikki_optimized_config.yaml

不要只修改：

text

/etc/nikki/run/config.yaml

后者是 Nikki 生成的运行配置，重启或重新应用配置后可能被覆盖。

3. 每条规则是什么意思

yaml

- DOMAIN,services.googleapis.cn,fake-ip

精确匹配 Google Play 特例，并在国内域名规则之前强制返回 Fake-IP。

yaml

- RULE-SET,fakeipfilter_domain,real-ip

局域网、设备发现、时间同步等不适合 Fake-IP 的域名返回真实 IP。

yaml

- RULE-SET,cn_domain,real-ip

已知国内域名返回真实 IP，让 Q3000 有机会命中大陆 IP 库并直接出 WAN。

yaml

- RULE-SET,geolocation-!cn,fake-ip

已知非中国域名返回 Fake-IP，确保 Q3000 把连接交给 R4S。

yaml

- MATCH,real-ip

无法按域名判断的新域名返回真实 IP，最后由 Q3000 的大陆 IP 库判断走向。

当前 Mihomo 为 v1.19.27，支持 fake-ip-filter-mode: rule；现有 fakeipfilter_domain、cn_domain 和 geolocation-!cn 也都是可用于 DNS 规则的 domain 类型规则集。

这里必须分清两层规则：fake-ip-filter 只决定 DNS 阶段向客户端返回 Fake-IP 还是真实 IP，并不直接等于 PROXY 或 DIRECT。真实业务连接到达 R4S 后，仍由 YAML 中正式的 rules: 从上到下匹配，并由对应策略组决定使用代理节点还是直连。本文让国外域名优先取得 Fake-IP，是为了让 Q3000 稳定地把连接送到 R4S，同时让 Mihomo 能从 Fake-IP 映射表还原域名；最终代理动作仍属于第二阶段。

4. 国内请求：第一阶段，DNS 查询

text

淘宝 App（准备访问 taobao.com）
  ↓
手机系统 DNS 缓存（没有可用答案）
  ↓
手机网络系统（向 192.168.10.3 发送 DNS 查询）
  ↓
无线 AP / K2P（转交 R4S）
  ↓
R4S dnsmasq（不再检查四千域名，所有查询都转给 127.0.0.1:1053）
  ↓
Mihomo DNS（从上到下检查 fake-ip-filter 规则）
  ↓
RULE-SET,cn_domain,real-ip（确认 taobao.com 属于国内域名）
  ↓
nameserver-policy（选择阿里 DNS 或腾讯 DNS 等国内上游）
  ↓
国内上游 DNS（返回淘宝真实大陆 IP）
  ↓
Mihomo DNS（因为规则要求 real-ip，所以把真实 IP 返回给 dnsmasq）
  ↓
dnsmasq（把真实 IP 返回手机）
  ↓
手机系统 DNS 缓存（保存淘宝真实 IP）
  ↓
淘宝 App（取得真实大陆 IP）

这里国内 DNS 也依赖 Mihomo，但真实业务流量仍然可以绕过 R4S。

5. 国内请求：第二阶段，真实业务流量

text

淘宝 App（向真实大陆 IP 发起连接）
  ↓
手机默认网关 192.168.10.1
  ↓
Q3000（目标 IP 命中 CN4-A01～CN4-A08）
  ↓
CodexCNDirect
  ↓
WAN1 与 NAT
  ↓
淘宝服务器
  ↓
Q3000 连接跟踪与 NAT 还原
  ↓
手机淘宝 App

Mihomo只参加了 DNS，没有承载淘宝业务流量。

6. 国外请求：第一阶段，DNS 查询

text

浏览器或 Google App（查询 google.com）
  ↓
手机 DNS → R4S dnsmasq
  ↓
dnsmasq（全部转给 Mihomo DNS 1053）
  ↓
Mihomo DNS（检查规则）
  ↓
RULE-SET,geolocation-!cn,fake-ip（确认属于非中国域名）
  ↓
Mihomo Fake-IP 映射表（生成并记录 198.18.x.x = google.com）
  ↓
Mihomo DNS → dnsmasq → 手机
  ↓
手机系统 DNS 缓存（保存 Fake-IP）

7. 国外请求：第二阶段，真实业务流量

text

浏览器或 Google App（向 198.18.x.x 发起连接）
  ↓
手机默认网关 192.168.10.1
  ↓
Q3000（Fake-IP 不属于大陆 IP 库）
  ↓
CodexR4S（下一跳 192.168.10.3）
  ↓
R4S Nikki 透明代理
  ↓
Mihomo（通过 Fake-IP 映射还原 google.com）
  ↓
Mihomo规则引擎（选择 Google 策略组和代理节点）
  ↓
Q3000 WAN1 → 代理节点 → Google
  ↓
回应经代理隧道返回 Mihomo
  ↓
Mihomo → 局域网 → 手机

8. Google Play 特例：两个阶段

第一阶段：

text

Google Play（查询 services.googleapis.cn）
  ↓
dnsmasq（全部转给 Mihomo）
  ↓
Mihomo首先命中 DOMAIN,services.googleapis.cn,fake-ip
  ↓
因为该规则位于 cn_domain 之前，所以强制返回 Fake-IP
  ↓
手机取得 198.18.x.x

第二阶段：

text

Google Play（向 Fake-IP 建立下载连接）
  ↓
Q3000（不命中大陆 IP 库）
  ↓
CodexR4S → R4S/Nikki/Mihomo
  ↓
Mihomo还原 services.googleapis.cn 并使用 Google 代理策略
  ↓
Google Play 正常下载

因此方案 B 不再需要域名分流插件维护这一条规则。

9. 未识别域名：两个阶段

第一阶段：

text

客户端查询一个新域名
  ↓
Mihomo没有命中 cn_domain 或 geolocation-!cn
  ↓
MATCH,real-ip
  ↓
Mihomo通过默认安全上游取得真实 IP
  ↓
把真实 IP 返回客户端

第二阶段：

text

客户端向真实 IP 发起连接
  ↓
Q3000检查大陆 IPv4 库
  ├─ 属于大陆 → WAN1
  └─ 不属于大陆 → R4S/Nikki/Mihomo

这让 Q3000 的 IP 数据库成为域名规则没有覆盖时的最后保险。

10. 方案 B 的故障边界

text

Mihomo停止
→ dnsmasq虽然仍监听 192.168.10.3:53
→ 但唯一上游 127.0.0.1:1053 不可用
→ 国内外新域名都无法正常解析

text

整个 R4S断电
→ 客户端 DNS 192.168.10.3 不可用
→ 国内外新域名都无法正常解析

可以另做健康检查，在 Mihomo停止时临时把 dnsmasq 切回国内 DNS，从而保住国内访问；但这会增加新的自动化与回滚逻辑，不能把普通国内 DNS 与 Mihomo DNS 同时无条件配置成竞争上游，否则可能造成国外域名泄漏或解析不一致。

七、两种 DNS 方案的本质区别

方案 A

text

dnsmasq先按域名名单决定：
代理名单/插件例外 → Mihomo
其他域名 → 国内普通 DNS

Q3000再按最终 IP 决定：
大陆 IP → WAN1
其他 IP/Fake-IP → R4S

方案 B

text

dnsmasq把全部查询交给 Mihomo

Mihomo按 YAML 决定：
国内域名 → 真实 IP
国外域名 → Fake-IP
特殊域名 → 明确指定 fake-ip 或 real-ip
未知域名 → 真实 IP

Q3000再按最终 IP决定：
大陆 IP → WAN1
其他 IP/Fake-IP → R4S

对比表

对比项	方案 A：选择性转发	方案 B：Mihomo 全权解析
国内 DNS	dnsmasq 直接访问国内上游	Mihomo选择国内上游
国外 DNS	自动名单命中后进入 Mihomo	全部进入 Mihomo并按规则分类
Google Play 特例	LuCI 插件维护	YAML 第一条规则维护
四千域名文件	需要，但自动更新	不需要
自定义插件	需要，当前仅一条	不需要
配置集中度	中等	高
Mihomo停止后国内 DNS	大部分仍可用	不可用
域名规则漏收	依赖 Q3000 非大陆 IP 兜底，但可能受普通 DNS 结果影响	MATCH real-ip 后由 Q3000 兜底
当前实测状态	已完整验证	尚未正式切换
推荐对象	稳定优先	配置统一优先

八、为什么方案 A 当前更值得保留

方案 A 看起来多了四千域名文件、更新脚本和一个插件，但实际人工维护量并不大：

text

四千多条域名 → 每天自动更新
插件 → 只维护 services.googleapis.cn 一条

它最大的价值不是“域名更多”，而是把普通国内 DNS 与 Mihomo 的运行状态分开。Nikki/Mihomo 单独重启、崩溃或更新时，国内 DNS 和 Q3000 国内直连仍有机会继续工作。

方案 B 的设计更加整洁，但整洁不等于故障范围更小。在家庭网络中，DNS 是所有应用的入口，一旦 Mihomo成为唯一 DNS 上游，它的停止会表现成“整个网络都打不开”。

因此当前建议是：

text

生产使用：继续方案 A
研究或后续简化：先以可回滚方式测试方案 B

九、重装 R4S 时分别恢复什么

方案 A 的恢复项目

text

1. 安装 Nikki 和 Mihomo 内核
2. 导入并验证 nikki_optimized_config.yaml
3. 恢复 dnsmasq 默认上游 223.5.5.5、223.6.6.6
4. 安装 update-gfw-dnsmasq
5. 恢复每天 04:17 的更新任务
6. 生成 gwf-gfwlist.conf
7. 安装 LuCI 域名分流插件
8. 添加 services.googleapis.cn
9. 检查 google.com 返回 Fake-IP
10. 检查 services.googleapis.cn 返回 Fake-IP
11. 检查 taobao.com 返回大陆真实 IP

这些步骤适合封装成一个一键恢复脚本，不应依靠记忆手工重建。

方案 B 的恢复项目

text

1. 安装 Nikki 和 Mihomo 内核
2. 导入包含 rule 模式 DNS 配置的 nikki_optimized_config.yaml
3. 让 dnsmasq 的唯一上游指向 127.0.0.1#1053
4. 检查 google.com 返回 Fake-IP
5. 检查 services.googleapis.cn 返回 Fake-IP
6. 检查 taobao.com 返回大陆真实 IP
7. 确认 Q3000 的两条分流规则仍然存在

方案 B 不需要四千域名更新程序和插件，但必须保证 Nikki 启动顺序、Mihomo DNS 监听和规则集下载全部正常。

十、完整验收清单

无论选择哪种 DNS 子方案，都应按以下顺序验收：

text

DNS 层
□ taobao.com 返回真实大陆 IP
□ baidu.com 返回真实大陆 IP
□ google.com 返回 198.18.x.x
□ youtube.com 返回 198.18.x.x
□ services.googleapis.cn 返回 198.18.x.x

Q3000 分流层
□ CodexCNDirect 已启用并引用八个 CN4 分组
□ CodexR4S 已启用，下一跳为 192.168.10.3
□ 客户端范围为 192.168.10.100-192.168.10.200

应用层
□ 淘宝和微信正常
□ 国内网页打开速度正常
□ Google 搜索正常
□ YouTube 首页、缩略图和视频正常
□ ssh.cloud.google.com 能建立长连接
□ Google Play 可以下载并完成安装
□ Muse 等曾经异常的网站正常
□ Tailscale 子网访问和出口节点正常

测试 Google Play 时，不要只看到商店首页就判断成功。应实际选择一个应用，确认下载进度超过 1% 并完成安装。

十一、常见问题

1. 所有流量是否第一时间经过 Nikki

不是。客户端默认网关是 Q3000：

text

大陆真实 IP → Q3000直接 WAN1
非大陆真实 IP/Fake-IP → Q3000交给 R4S → Nikki/Mihomo

两种 DNS 方案改变的是“如何得到目标 IP”，不是把国内业务流量重新强制送进 R4S。

2. 为什么 Zashboard 中来源都是 192.168.10.1

当前 Q3000 和 R4S 位于同一 LAN。Q3000 把连接折返给 LAN 内下一跳时会隐藏原始客户端地址，因此 Mihomo看到的来源是 Q3000。这个问题不影响分流和速度，但 Zashboard 无法按真实客户端统计。

要保留真实来源 IP，需要为 Q3000 与 R4S 建立独立传输网段，可通过第二根网线或 VLAN 实现；这属于另一项网络架构改造，与两种 DNS 子方案无关。

3. 客户端手动设置 8.8.8.8 会怎样

客户端访问 8.8.8.8:53 时，目标 IP 不属于大陆地址库，Q3000 会把查询交给 R4S。若 Nikki 的透明代理 DNS 劫持正常，查询仍可能进入 Mihomo；但不应依赖客户端随意设置 DNS，标准配置仍是 192.168.10.3。

4. 为什么 `services.googleapis.cn` 不能直接按 `.cn` 直连

域名后缀只表示命名空间，不代表该服务在当前网络下可以完整直连。Google Play 同时使用控制域名、下载 CDN 和账号连接；如果其中一部分直连、一部分代理，同一个下载任务会产生出口不一致并卡住。

5. Q3000 大陆 IP 库是否自动更新

当前八个 CN4 分组是一次性导入的快照，数据保存在 Q3000 中，访问时无需外部脚本；但它不会自行跟随互联网地址分配变化。长期使用应增加定期同步与备份工具，并在更新后检查八个对象和两条规则的引用关系。

十二、最终选择建议

稳定性优先时：

text

选择方案 A
dnsmasq 维护自动代理域名表
插件只保留 services.googleapis.cn
国内 DNS 不依赖 Mihomo进程

配置集中优先时：

text

选择方案 B
所有 DNS 交给 Mihomo
YAML 使用 fake-ip-filter-mode: rule
services.googleapis.cn 写入第一条强制 Fake-IP 规则
接受 Mihomo成为全网 DNS 单点

无论选择哪一种，真正决定国内业务流量是否绕过 R4S 的核心都不是域名列表，而是 Q3000 中的两条规则：

text

大陆 IP → CodexCNDirect → WAN1
其他 IP → CodexR4S → R4S/Nikki/Mihomo

DNS 负责发放“目的地址”，Q3000 负责选择“实际道路”，R4S/Nikki/Mihomo 负责处理“需要代理的那部分连接”。把这三层职责分开理解，整套网络就不再神秘。

一、先给出结论 ​

二、先分清 Q3000、R4S、Nikki、Mihomo 和 dnsmasq ​

三、Q3000 的大陆 IP 分流如何触发 ​

1. 大陆 IP 数据放在哪里 ​

2. 真正引用 IP 库的是两条规则 ​

3. “被引用次数 1”不是访问次数 ​

四、一次上网请求其实分为两个阶段 ​

五、方案 A：dnsmasq 选择性转发 ​

1. 核心结构 ​

2. 国内请求：第一阶段，DNS 查询 ​

3. 国内请求：第二阶段，真实业务流量 ​

4. 国外请求：第一阶段，DNS 查询 ​

5. 国外请求：第二阶段，真实业务流量 ​

6. Google Play 特例的完整流程 ​

7. 方案 A 的故障边界 ​

六、方案 B：所有 DNS 全权交给 Mihomo ​

1. 核心结构 ​

2. 为什么不能直接把所有 DNS 转给当前 Mihomo ​

3. 每条规则是什么意思 ​

4. 国内请求：第一阶段，DNS 查询 ​

5. 国内请求：第二阶段，真实业务流量 ​

6. 国外请求：第一阶段，DNS 查询 ​

7. 国外请求：第二阶段，真实业务流量 ​

8. Google Play 特例：两个阶段 ​

9. 未识别域名：两个阶段 ​

10. 方案 B 的故障边界 ​

七、两种 DNS 方案的本质区别 ​

方案 A ​

方案 B ​

对比表 ​

八、为什么方案 A 当前更值得保留 ​

九、重装 R4S 时分别恢复什么 ​

方案 A 的恢复项目 ​

方案 B 的恢复项目 ​

十、完整验收清单 ​

十一、常见问题 ​

1. 所有流量是否第一时间经过 Nikki ​

2. 为什么 Zashboard 中来源都是 192.168.10.1 ​

3. 客户端手动设置 8.8.8.8 会怎样 ​

4. 为什么 services.googleapis.cn 不能直接按 .cn 直连 ​

5. Q3000 大陆 IP 库是否自动更新 ​

十二、最终选择建议 ​

一、先给出结论

二、先分清 Q3000、R4S、Nikki、Mihomo 和 dnsmasq

三、Q3000 的大陆 IP 分流如何触发

1. 大陆 IP 数据放在哪里

2. 真正引用 IP 库的是两条规则

3. “被引用次数 1”不是访问次数

四、一次上网请求其实分为两个阶段

五、方案 A：dnsmasq 选择性转发

1. 核心结构

2. 国内请求：第一阶段，DNS 查询

3. 国内请求：第二阶段，真实业务流量

4. 国外请求：第一阶段，DNS 查询

5. 国外请求：第二阶段，真实业务流量

6. Google Play 特例的完整流程

7. 方案 A 的故障边界

六、方案 B：所有 DNS 全权交给 Mihomo

1. 核心结构

2. 为什么不能直接把所有 DNS 转给当前 Mihomo

3. 每条规则是什么意思

4. 国内请求：第一阶段，DNS 查询

5. 国内请求：第二阶段，真实业务流量

6. 国外请求：第一阶段，DNS 查询

7. 国外请求：第二阶段，真实业务流量

8. Google Play 特例：两个阶段

9. 未识别域名：两个阶段

10. 方案 B 的故障边界

七、两种 DNS 方案的本质区别

方案 A

方案 B

对比表

八、为什么方案 A 当前更值得保留

九、重装 R4S 时分别恢复什么

方案 A 的恢复项目

方案 B 的恢复项目

十、完整验收清单

十一、常见问题

1. 所有流量是否第一时间经过 Nikki

2. 为什么 Zashboard 中来源都是 192.168.10.1

3. 客户端手动设置 8.8.8.8 会怎样

4. 为什么 `services.googleapis.cn` 不能直接按 `.cn` 直连

5. Q3000 大陆 IP 库是否自动更新

十二、最终选择建议