Sirenyan Notes

深色模式

Q3000 + R4S 分流进阶：方案 B 的 Mihomo 全权 DNS 实战

网络教程

本文是《Q3000 + R4S 分流终极指南：同一套大陆 IP 分流下的两种 DNS 方案》的续篇。上一篇文章对比了方案 A 与方案 B；本文只讲后来正式投入使用的方案 B：客户端网关仍为 Q3000，DNS 仍指向 R4S，但所有 DNS 查询统一交给 Mihomo 分类。本文记录最终结构、完整请求路径、关键 YAML、境外 DNS 通道、切换步骤、验收方法、故障边界和重装恢复。

一、为什么单独写这篇续篇 ​

上一篇文章完成时，方案 A 已经稳定运行，方案 B 还只是经过配置验证、尚未正式切换。因此上一篇文章给出的阶段性建议是“生产继续使用方案 A”。

后续实际测试发生了变化：

text
方案 B 已正式切换并持续运行
淘宝、微信等国内应用正常
Google、YouTube、TikTok 等国外服务正常
ssh.cloud.google.com 长连接正常
Google Play 可以正常下载并完成安装
services.googleapis.cn 特例已由 YAML 统一处理
境外 DNS 已增加跨地区专用通道
旧的四千多条 dnsmasq 代理域名和自定义插件已移除

所以这篇文章不是推翻上一篇，而是把上一篇中的“候选方案 B”补全为一套已经落地、可以备份和重装恢复的正式方案。

二、先给出最终结论 ​

当前网络的固定结构如下：

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

Q3000：
大陆目标 IP → WAN1 直接出网
其他目标 IP / Fake-IP → 下一跳 192.168.10.3

R4S：
dnsmasq 的唯一上游 → 127.0.0.1#1053

Mihomo：
国内域名 → 国内 DNS → 返回真实 IP
国外域名 → 境外 DNS → 返回 Fake-IP
特殊域名 → 按 YAML 明确指定 Fake-IP 或真实 IP
未知域名 → 返回真实 IP，再由 Q3000 按 IP 归属兜底

这套结构可以用一句话概括：

Mihomo 负责给域名分类和发放地址，Q3000 负责根据最终目标 IP 选择道路，R4S/Nikki/Mihomo 只承载真正需要代理的业务流量。

方案 B 并不是把国内业务流量全部交给 R4S。国内域名的 DNS 查询经过 Mihomo，但拿到大陆真实 IP 后，真正的淘宝、微信、银行 App 等业务连接仍由 Q3000 直接从 WAN1 出口。

三、五个组件分别负责什么 ​

text
Q3000（主路由）
├─ WAN 拨号、NAT、DHCP、VLAN、Wi-Fi 和客户端管理
├─ 保存大陆 IPv4 地址库 CN4-A01～CN4-A08
├─ 命中大陆 IP：WAN1 直连
└─ 未命中大陆 IP：下一跳交给 R4S

R4S（硬件设备）
└─ ImmortalWrt / OpenWrt（操作系统）
   ├─ dnsmasq（监听 192.168.10.3:53，接收全网 DNS 查询）
   ├─ Tailscale（独立的远程组网服务）
   └─ Nikki（管理和启动代理配置的插件）
      └─ Mihomo（实际执行 DNS、Fake-IP、规则和代理连接的内核）

再用最通俗的比喻说明：

  • dnsmasq 是对外营业的 DNS 前台，客户端只认识它。
  • Mihomo DNS 是后台判断员，决定返回真实 IP 还是 Fake-IP。
  • Q3000 是总路口，看到最终目标 IP 后决定走 WAN1 还是 R4S。
  • Nikki 是 Mihomo 的管理系统，不负责亲自转发每一个数据包。
  • Zashboard 是观察和选择策略的控制面板，也不是转发内核。

四、方案 B 与旧方案 A 到底差在哪里 ​

方案 A：dnsmasq 先用四千多个域名分类 ​

text
客户端 DNS 查询
  ↓
R4S dnsmasq
  ├─ 命中约四千多个代理域名 → Mihomo DNS
  ├─ 命中自定义插件域名 → Mihomo DNS
  └─ 其余域名 → 国内普通 DNS

这种方式的优点是普通国内 DNS 不依赖 Mihomo；缺点是分类逻辑分散在自动域名表、更新脚本、自定义插件和 YAML 多处。

方案 B：dnsmasq 不再分类，全部交给 Mihomo ​

text
客户端 DNS 查询
  ↓
R4S dnsmasq
  ↓ 所有域名
127.0.0.1:1053
  ↓
Mihomo DNS 按 YAML 统一分类

因此方案 B 中已经不再需要：

text
/etc/dnsmasq.d/gwf-gfwlist.conf
/etc/dnsmasq.d/gwf-ui.conf
/usr/local/sbin/update-gfw-dnsmasq
每天更新代理域名的 cron 任务
“域名分流”LuCI 插件

这些组件必须先备份、验证方案 B 后再移除，不能一上来直接删除。

五、Q3000 的 IP 分流仍然是核心 ​

方案 B 只替换 DNS 分类方法，Q3000 的两条核心规则没有改变。

规则 1：大陆 IP 直接出网 ​

text
名称：CodexCNDirect
来源：192.168.10.100-192.168.10.200
目标：CN4-A01～CN4-A08
出口：WAN1
优先级：高于下一条兜底规则

规则 2：其他地址交给 R4S ​

text
名称：CodexR4S
来源：192.168.10.100-192.168.10.200
目标：任意
下一跳：192.168.10.3
优先级：低于 CodexCNDirect

八个 CN4 分组只是大陆 IPv4 数据库。真正触发分流的是 CodexCNDirect 对这些分组的引用，而不是导入 IP 数据后自动发生魔法。

“被引用次数 1”表示有一条规则正在使用该分组，不表示访问次数。访问淘宝一万次，它仍然是 1。

这里还有两个不能省略的前提：

  1. Q3000 的 DHCP 固定地址和动态地址池必须落在这两条规则声明的来源范围内；超出 192.168.10.100-192.168.10.200 的客户端不会自动套用这套分流，需要同步扩大来源范围或增加规则。
  2. R4S 自身地址 192.168.10.3 不能包含在 CodexR4S 的来源范围内。Mihomo 建立到代理节点的连接时，来源是 R4S；排除它以后，Q3000 才会把该连接直接从 WAN1 发出，而不会再次送回 R4S 形成循环。

六、方案 B 的核心 DNS 配置 ​

下面是当前实测配置中与方案 B 有关的部分。节点、订阅、控制密钥等私密内容不在本文展示。

yaml
dns:
  enable: true
  cache-algorithm: arc
  listen: 0.0.0.0:1053
  ipv6: false
  respect-rules: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter-mode: rule

  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29

  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query

  direct-nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query

  direct-nameserver-follow-policy: true

  nameserver-policy:
    "rule-set:cn_domain":
      - https://dns.alidns.com/dns-query
      - https://doh.pub/dns-query
    "rule-set:geolocation-!cn":
      - https://8.8.8.8/dns-query#境外DNS通道
      - https://1.1.1.1/dns-query#境外DNS通道

  nameserver:
    - https://8.8.8.8/dns-query#境外DNS通道
    - https://1.1.1.1/dns-query#境外DNS通道

  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通道 不是 YAML 注释。它是 Mihomo 在 DNS 上游地址后使用的策略组标记，表示访问这个 DoH 上游时必须经过名为“境外DNS通道”的代理组。

七、五类 DNS 配置是什么关系 ​

这些名称容易让人误以为存在简单的上下级关系。实际上，它们是 Mihomo 在不同场景调用的不同 DNS 角色。

1. default-nameserver ​

yaml
default-nameserver:
  - 223.5.5.5
  - 119.29.29.29

它负责最基础的启动解析，例如先解析其他 DoH 服务器自身的域名。这里使用可在大陆直连的纯 IP DNS，避免 Mihomo 刚启动时需要“先解析 DNS 服务器，才能使用 DNS 服务器”的循环。

2. proxy-server-nameserver ​

yaml
proxy-server-nameserver:
  - https://dns.alidns.com/dns-query
  - https://doh.pub/dns-query

它专门解析代理节点服务器的域名。

假设订阅中的节点地址是：

text
sg-node.example.com

Mihomo 必须先知道这个节点域名对应的真实 IP，才能连上节点。这里使用阿里和腾讯的国内 DoH，即使全部代理节点当前都不可用，Mihomo 仍然可以查到各节点服务器的 IP，并在节点恢复后重新连接。

3. direct-nameserver ​

它用于直连流量需要重新解析域名时的国内 DNS。国内服务不需要绕到 Google DNS 或 Cloudflare DNS 查询。

4. nameserver-policy ​

它按域名规则集选择上游：

text
命中 cn_domain → 阿里 / 腾讯 DNS
命中 geolocation-!cn → Google / Cloudflare DNS，并经过境外DNS通道

5. nameserver ​

它是没有被更具体策略选中的默认业务 DNS。在本方案中使用 Google 和 Cloudflare DoH，并明确绑定“境外DNS通道”。

所以它们不是“一个覆盖另一个”的单一优先级列表，而是：

text
启动解析 → default-nameserver
代理节点域名 → proxy-server-nameserver
直连重解析 → direct-nameserver
已知域名分类 → nameserver-policy
其余普通查询 → nameserver

八、fake-ip-filter-mode: rule 为什么关键 ​

旧配置常见的是：

yaml
fake-ip-filter-mode: blacklist

在 blacklist 模式下，fake-ip-filter 更像“不使用 Fake-IP 的例外名单”。这不适合本方案，因为我们需要明确表达四种结果：国内真实 IP、国外 Fake-IP、兼容性域名真实 IP、特殊国外服务强制 Fake-IP。

规则模式会从上到下判断，第一条命中即停止：

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 库。

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

已知国外域名返回 Fake-IP，使 Q3000 稳定地把后续业务连接交给 R4S。

yaml
- MATCH,real-ip

无法确定的新域名保守地返回真实 IP，最后由 Q3000 的大陆 IP 库判断走 WAN1 还是 R4S。

必须再次强调：

fake-ip-filter 只决定 DNS 回答是真实 IP 还是 Fake-IP，不直接等于 DIRECT 或 PROXY。真正的业务连接到达 R4S 后，还要由 YAML 的正式 rules: 再判断一次。

九、国内服务的完整闭环 ​

下面以手机打开淘宝为例，把 DNS 阶段和真实流量阶段完整分开。

第一阶段：查询淘宝的 IP ​

text
淘宝 App（准备访问 taobao.com）
  ↓
手机系统 DNS 缓存（检查是否已有未过期答案）
  ↓ 缓存没有可用答案
手机网络系统（生成查询 taobao.com 的 DNS 数据包）
  ↓
手机 Wi-Fi 网卡（把 DNS 数据包发给 192.168.10.3）
  ↓
无线 AP / K2P（只负责局域网二层转发）
  ↓
R4S 网卡（收到目标端口为 53 的 DNS 查询）
  ↓
R4S Linux 网络系统（把 53 端口数据交给 dnsmasq）
  ↓
dnsmasq（检查本地缓存；没有答案时把查询全部转发到 127.0.0.1:1053）
  ↓
Mihomo DNS（检查自己的 DNS 缓存和 fake-ip-filter 规则）
  ↓
RULE-SET,cn_domain,real-ip（确认 taobao.com 属于国内域名）
  ↓
nameserver-policy（选择阿里 DNS 或腾讯 DNS）
  ↓
国内上游 DNS（返回 taobao.com 的真实大陆 IP）
  ↓
Mihomo DNS（按 real-ip 要求保留真实 IP，并缓存结果）
  ↓
dnsmasq（缓存答案并返回手机）
  ↓
无线 AP / K2P（把 DNS 回应转交手机）
  ↓
手机系统 DNS 缓存（保存淘宝真实 IP）
  ↓
淘宝 App（取得真实大陆 IP）

第二阶段：真正访问淘宝 ​

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（收到页面、图片和视频数据）

结论：Mihomo 参加了淘宝的 DNS 判断，但淘宝真正的大流量没有经过代理节点。

十、国外服务的完整闭环 ​

下面以手机访问 YouTube 为例。

第一阶段：查询 YouTube 的 IP ​

text
YouTube App（准备访问 youtube.com）
  ↓
手机系统 DNS 缓存（没有可用答案）
  ↓
手机网络系统（把 DNS 查询发给 192.168.10.3）
  ↓
无线 AP / K2P（转交 R4S）
  ↓
R4S dnsmasq（把查询转给 127.0.0.1:1053）
  ↓
Mihomo DNS（检查 fake-ip-filter）
  ↓
RULE-SET,geolocation-!cn,fake-ip（确认是非国内域名）
  ↓
Mihomo Fake-IP 映射表（分配并记录 198.18.x.x = youtube.com）
  ↓
Mihomo DNS（把 Fake-IP 返回 dnsmasq）
  ↓
dnsmasq（把 Fake-IP 返回手机）
  ↓
手机系统 DNS 缓存（保存 198.18.x.x）
  ↓
YouTube App（取得 Fake-IP）

这里返回 Fake-IP 时，Mihomo 不需要先把 YouTube 的真实 IP 交给手机。它记录了 Fake-IP 与域名的映射，稍后再根据域名规则建立代理连接。

第二阶段：真正播放 YouTube ​

text
YouTube App（向 198.18.x.x 的 443 端口发起 HTTPS / QUIC 连接）
  ↓
手机 Wi-Fi 网卡（把业务数据交给默认网关 192.168.10.1）
  ↓
Q3000（发现 Fake-IP 不属于大陆 IPv4 库）
  ↓
CodexR4S（把连接下一跳交给 192.168.10.3）
  ↓
R4S Linux 防火墙 / Nikki 透明代理规则（截获应该由 Mihomo 处理的连接）
  ↓
Mihomo 内核（从 Fake-IP 映射表还原 youtube.com）
  ↓
Mihomo rules（匹配 youtube_domain）
  ↓
YouTube 策略组（选择当前节点或地区组）
  ↓
Mihomo（通过代理节点建立到 YouTube / googlevideo CDN 的真实连接）
  ↓
R4S 默认路由（把代理节点连接发给 Q3000）
  ↓
Q3000（来源是 R4S，不再折返给 R4S，直接从 WAN1 出网）
  ↓
代理节点 → YouTube / googlevideo CDN
  ↓
视频数据沿代理隧道返回 Mihomo
  ↓
Mihomo → R4S 局域网接口 → Q3000 / K2P 交换路径 → 手机
  ↓
YouTube App（解码并播放视频）

十一、Google Play 为什么需要单独一条规则 ​

services.googleapis.cn 虽然以 .cn 结尾，但它属于 Google Play 的服务链。若按普通国内域名处理，它可能返回大陆真实 IP，Q3000 随即让它直连；而账号、控制接口和其他下载 CDN 又可能走代理，最终造成同一次下载出口不一致，表现为一直等待、卡在 1% 或完全无法下载。

因此它必须放在 cn_domain 之前：

yaml
fake-ip-filter:
  - DOMAIN,services.googleapis.cn,fake-ip
  - RULE-SET,fakeipfilter_domain,real-ip
  - RULE-SET,cn_domain,real-ip

完整闭环如下：

text
Google Play（查询 services.googleapis.cn）
  ↓
dnsmasq → Mihomo DNS
  ↓
第一条精确规则强制返回 Fake-IP
  ↓
手机向 Fake-IP 建立连接
  ↓
Q3000 不命中大陆 IP 库 → CodexR4S
  ↓
R4S / Nikki / Mihomo 还原域名
  ↓
正式 rules 命中 Google 策略组
  ↓
Google Play 控制连接和下载连接保持一致的代理出口
  ↓
下载进度超过 1% 并完成安装

这也是方案 B 移除旧“域名分流”插件后，仍能正常使用 Google Play 的关键。

十二、为什么增加“境外DNS通道” ​

国外域名会使用：

yaml
https://8.8.8.8/dns-query
https://1.1.1.1/dns-query

在大陆网络中，不能假设它们始终可以稳定直连。若它们跟随普通“默认代理”，DNS 能否工作就会依赖默认策略当时选中的单一地区或节点。

因此单独建立一个只服务于境外 DNS 的跨地区组：

yaml
proxy-groups:
  - name: 境外DNS通道
    type: fallback
    url: https://www.gstatic.com/generate_204
    interval: 60
    lazy: false
    proxies:
      - 新加坡-故转
      - 香港-故转
      - 日本-故转
      - 台湾-故转
      - 美国-故转

然后把境外 DoH 明确绑定到它：

yaml
- https://8.8.8.8/dns-query#境外DNS通道
- https://1.1.1.1/dns-query#境外DNS通道

它的运行逻辑是：

text
每 60 秒主动检测候选通道
  ↓
优先使用列表中第一个健康地区
  ↓
当前地区失效
  ↓
自动切换到下一个健康地区

健康检查使用 Google 的 generate_204，因为这个组的任务就是访问境外 DNS。国内连通性测试只能证明节点“能联网”，不能充分证明它可以稳定访问 Google 或 Cloudflare DNS。

这个组不放 DIRECT 作为最后候选。原因是大陆直连 8.8.8.8 或 1.1.1.1 并不是可靠兜底，反而会让故障表现变得随机。

但也要理解它的边界：

  • 一个地区故障：自动换其他地区。
  • 一个节点故障：对应地区组可以继续选择其他健康节点。
  • 所有代理地区全部故障：境外 DNS 仍会失败。
  • Mihomo 进程停止：国内外 DNS 都会失败，因为 dnsmasq 的唯一上游就是 Mihomo。

“境外DNS通道”提高的是代理节点局部故障时的可用性，不是让完全不可用的节点恢复工作。

十三、为什么不会形成 DNS 死循环 ​

常见担心是：

text
访问 Google DNS 需要代理
代理节点域名又需要 DNS
DNS 还没工作，节点就无法连接

本方案用不同 DNS 角色拆开了这个循环：

text
default-nameserver（国内纯 IP DNS）
  ↓ 先解析阿里、腾讯等 DoH 服务器自身域名
proxy-server-nameserver（国内可直连 DoH）
  ↓ 解析各代理节点服务器域名
代理节点取得真实 IP并建立连接
  ↓
境外DNS通道变为可用
  ↓
8.8.8.8 / 1.1.1.1 DoH 开始解析国外业务域名

即使所有代理节点暂时故障，阿里和腾讯 DNS 仍可以继续解析节点服务器域名。节点一旦恢复，Mihomo 知道应该连接哪个真实 IP，不会因为境外 DNS 不通而永远无法恢复。

十四、实际切换步骤 ​

以下步骤适用于已经运行方案 A、准备切换方案 B 的环境。全新安装可以跳过“清理方案 A 组件”，但仍应先备份。

1. 完整备份 ​

至少保存：

text
/etc/config/dhcp
/etc/config/nikki
/etc/nikki/profiles/当前配置.yaml
/etc/nikki/run/config.yaml
/etc/crontabs/root
/etc/dnsmasq.d/gwf-gfwlist.conf
/etc/dnsmasq.d/gwf-ui.conf
/usr/local/sbin/update-gfw-dnsmasq
域名分流插件文件
Q3000 的 DHCP、IP 分组和两条分流规则

备份必须放到 R4S 之外再保存一份，否则重刷存储卡时设备内备份也会一起消失。

2. 修改持久 YAML ​

应修改 Nikki 的持久配置，例如：

text
/etc/nikki/profiles/nikki_optimized_config.yaml

不要只修改：

text
/etc/nikki/run/config.yaml

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

把本文第六节的 DNS 片段合并到现有唯一的 dns: 段中。不能在文件底部再增加第二个 dns:。

同时确保规则集存在：

yaml
rule-providers:
  fakeipfilter_domain:
    type: http
    behavior: domain
    format: mrs
    interval: 86400
    url: "你的可信规则源/fakeip-filter.mrs"

  cn_domain:
    type: http
    behavior: domain
    format: mrs
    interval: 86400
    url: "你的可信规则源/cn.mrs"

  geolocation-!cn:
    type: http
    behavior: domain
    format: mrs
    interval: 86400
    url: "你的可信规则源/geolocation-!cn.mrs"

3. 先做内核语法校验 ​

不要直接重启碰运气。使用设备当前 Mihomo 内核检查候选文件：

sh
/usr/bin/mihomo -t -d /etc/nikki/run -f /tmp/scheme-b-candidate.yaml

看到类似下面的结果才可以继续：

text
configuration file ... test is successful

4. 应用 YAML 并重启 Nikki ​

建议先准备 5～10 分钟自动回滚，再原子替换持久 YAML，最后只重启 Nikki。

确认：

sh
/etc/init.d/nikki status

应返回：

text
running

5. 让 dnsmasq 全部转给 Mihomo ​

LuCI 路径：

text
网络 → DHCP/DNS → 转发 → DNS 转发

只保留：

text
127.0.0.1#1053

对应的 UCI 操作为：

sh
uci -q delete dhcp.@dnsmasq[0].server
uci add_list dhcp.@dnsmasq[0].server='127.0.0.1#1053'
uci set dhcp.@dnsmasq[0].noresolv='1'
uci commit dhcp
/etc/init.d/dnsmasq restart

截图中看到 127.0.0.1#1053，就表示客户端查询先到 dnsmasq，再统一转给 Mihomo 的 1053 端口。

6. 验证后再移除方案 A 组件 ​

先确认淘宝、Google、Google Play 等全部正常，再删除旧四千域名文件、更新脚本、定时任务和自定义插件。删除前必须保留可恢复副本。

十五、完整验收方法 ​

1. DNS 返回类型 ​

在 R4S 上执行：

sh
nslookup taobao.com 127.0.0.1
nslookup google.com 127.0.0.1
nslookup services.googleapis.cn 127.0.0.1

预期结果：

text
taobao.com → 真实大陆 IP
google.com → 198.18.x.x
services.googleapis.cn → 198.18.x.x

建议再测试：

text
baidu.com → 真实大陆 IP
youtube.com → 198.18.x.x

2. 境外 DNS 通道 ​

在 Zashboard 的“代理”页面检查：

text
境外DNS通道
类型：Fallback
状态：Alive
当前：某个健康地区组

在“连接”页面检查 8.8.8.8 和 1.1.1.1，代理链应包含：

text
当前节点 → 地区手动/自动组 → 地区故转组 → 境外DNS通道

3. 应用验收 ​

text
□ 淘宝首页、搜索、图片和视频正常
□ 微信消息、朋友圈图片和小程序正常
□ 国内银行及生活服务 App 正常
□ Google 搜索正常
□ YouTube 首页、缩略图和视频播放正常
□ TikTok 正常
□ ssh.cloud.google.com 能完成长连接
□ Google Play 下载超过 1% 并完成安装
□ Tailscale 子网访问和出口节点正常

Google Play 不能只测试打开商店首页，必须实际下载并完成一个应用。

十六、常见现象与排查 ​

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

Q3000 与 R4S 当前位于同一 LAN。Q3000 把非大陆流量折返给同网段 R4S 时会做连接转换，因此 Mihomo 看到的来源通常是 Q3000，而不是真实手机或电脑 IP。

这不影响分流和速度，只影响按客户端观察。若一定要保留真实来源，需要为 Q3000 与 R4S 建立独立传输网段，使用第二根网线或 VLAN；那是另一项架构改造，不是方案 B 本身的问题。

2. 电脑访问 YouTube，为什么 R4S 看不到 YouTube 代理链 ​

先检查电脑是否开启了 Clash Verge 等本机代理。

text
浏览器 → PC Clash → 代理节点

这种情况下，YouTube 已被电脑本机接管，没有把原始 YouTube 连接交给 R4S。R4S 面板只能看到 PC Clash 连接其节点的加密连接，不会显示 YouTube → 节点。

3. 手机与安卓模拟器表现为什么可能不同 ​

它们可能具有不同 DNS 缓存、QUIC 连接、Google 服务框架状态和既有长连接。修改 DNS 后应关闭并重新打开目标 App；必要时断开 Wi-Fi 后重新连接。不要把一次旧连接的结果当成新配置的最终判断。

4. 为什么页面出现 iosapps.itunes.apple.com ​

这是 Apple App Store 或系统内容下载域名，不是 YouTube 视频域名。判断大流量属于谁，必须同时看主机名、规则、代理链和实际设备状态，不能只凭下载速度猜测。

5. 专用应用策略为什么偶尔显示“默认代理” ​

Mihomo 的正式 rules: 从上到下匹配，第一条命中就停止。如果一个宽泛规则集排在 YouTube、Apple、Google 等专用规则之前，它可能提前接走连接。

需要专用策略组严格生效时，应把更具体的规则放在更宽泛的规则之前，并在修改后重新运行 Mihomo 语法校验和应用测试。

十七、方案 B 的故障边界 ​

Mihomo 正常，某个代理节点故障 ​

text
国内 DNS → 阿里 / 腾讯 DNS → 正常
国内真实流量 → Q3000 WAN1 → 正常
境外 DNS → 境外DNS通道自动切换地区

全部代理节点故障，但 Mihomo 仍在运行 ​

text
国内 DNS → 仍可由国内上游解析
国内真实流量 → 仍可由 Q3000 WAN1 直连
境外 DNS / 国外代理访问 → 失败
代理节点域名 → 仍可由 proxy-server-nameserver 解析

Mihomo 进程停止 ​

text
dnsmasq 仍监听 192.168.10.3:53
但唯一上游 127.0.0.1:1053 不可用
国内外新域名都无法解析
已有缓存和既有长连接可能暂时继续工作

R4S 断电或网线断开 ​

客户端 DNS 固定为 192.168.10.3，所以新域名都无法解析。这个物理故障不属于 DNS 规则能够解决的范围。

因此方案 B 的真实取舍是：

配置集中、覆盖完整、重装简单，但 Mihomo 成为全网 DNS 的关键服务。

十八、备份、回退与重装恢复 ​

方案 B 的最小恢复清单 ​

text
1. 安装 ImmortalWrt / OpenWrt 与 Nikki
2. 导入已经验证过的 Mihomo YAML
3. 确认 Mihomo DNS 监听 0.0.0.0:1053
4. dnsmasq 唯一上游设置为 127.0.0.1#1053
5. 确认 fake-ip-filter-mode 为 rule
6. 确认 services.googleapis.cn 位于 cn_domain 之前
7. 恢复境外DNS通道
8. 确认 Q3000 八个 CN4 分组与两条分流规则仍存在
9. 完成 DNS、国内应用、国外应用和 Google Play 验收

回退到方案 A 时需要恢复 ​

text
旧 Nikki YAML
旧 /etc/config/dhcp
四千多条 dnsmasq 代理域名文件
自定义域名例外文件
自动更新脚本与 cron 任务
域名分流 LuCI 插件

最可靠的做法不是现场凭记忆重建，而是提前准备一键备份、一键应用和一键回退脚本，并在执行网络修改前设置定时自动回滚。

十九、日常维护建议 ​

每月检查 ​

text
□ Nikki 与 Mihomo 正常运行
□ 127.0.0.1:1053 正常监听
□ 境外DNS通道状态为 Alive
□ taobao.com 返回真实 IP
□ google.com 返回 Fake-IP
□ services.googleapis.cn 返回 Fake-IP
□ Google Play 实际下载正常
□ Q3000 的 CN4 分组仍被 CodexCNDirect 引用

更新 YAML 或订阅后检查 ​

text
□ 节点域名仍能被 proxy-server-nameserver 解析
□ 地区组名称没有改变
□ 境外DNS通道引用的五个地区组仍存在
□ 应用专用规则没有被更宽泛规则提前截获
□ Nikki 混入设置没有覆盖 YAML 中的 DNS 配置

大陆 IPv4 库 ​

当前八个 CN4 分组是保存在 Q3000 内部的地址数据，访问时不依赖外部脚本。但一次性导入的快照不会自动跟随地址分配变化，长期使用应增加定期同步、差异检查和自动备份。

二十、可直接交给 Codex 的提示词 ​

1. 切换方案 B ​

text
请先完整备份 Q3000 与 R4S 当前配置，并准备定时自动回滚。保持客户端网关 192.168.10.1、DNS 192.168.10.3，以及 Q3000 的 CodexCNDirect/CodexR4S 规则不变。把 R4S dnsmasq 的唯一上游改为 127.0.0.1#1053，并在现有 Nikki YAML 的唯一 dns: 段中启用 fake-ip-filter-mode: rule。国内域名返回 real-ip，非中国域名返回 fake-ip，services.googleapis.cn 必须在 cn_domain 前强制 fake-ip。增加跨地区“境外DNS通道”，让 8.8.8.8 和 1.1.1.1 DoH 明确经过该组。先用当前 Mihomo 内核校验候选配置，应用后验证淘宝、Google、Google Play 和实际代理链；全部通过后再移除旧四千域名、更新任务和域名分流插件。

2. 诊断国内应用变慢 ​

text
请保持现有 Q3000 + R4S 方案 B 不变，分别检查 DNS 阶段和真实业务流量阶段。确认目标国内域名是否命中 cn_domain 并返回真实大陆 IP，Q3000 是否命中 CodexCNDirect，真实流量是否从 WAN1 直出。不要只根据 Zashboard 是否出现连接判断，也不要未经验证修改节点或全局 DNS。

3. 诊断国外服务打不开 ​

text
请检查该服务实际使用的主域名、子域名、CNAME 和 CDN 域名；确认 DNS 返回 Fake-IP 还是实际 IP，Q3000 是否把连接送到 R4S，Mihomo 的正式 rules 命中了哪个规则集和策略组，境外DNS通道是否健康。对比 PC Clash 与 R4S 使用同一节点时的 DNS、QUIC、IPv6、MTU 和代理链，不要先假设是节点问题。

4. 重装后恢复 ​

text
请在全新 R4S 上恢复方案 B：安装 Nikki，导入已验证 YAML，确认 Mihomo DNS 监听 1053，把 dnsmasq 唯一上游设置为 127.0.0.1#1053，验证 domestic real-ip、foreign fake-ip、services.googleapis.cn fake-ip 和境外DNS通道。保持 Q3000 的大陆 IP 分流规则不变。所有敏感密钥、订阅和节点凭据从备份恢复，不要输出到日志或文章。

二十一、最终总结 ​

方案 B 最容易被误解为“所有流量都经过 Mihomo”。准确说法是：

text
所有 DNS 查询都经过 Mihomo 分类
但不是所有真实业务流量都经过 Mihomo

国内服务：

text
DNS → R4S dnsmasq → Mihomo → 国内 DNS → 真实大陆 IP
业务流量 → Q3000 → CodexCNDirect → WAN1

国外服务：

text
DNS → R4S dnsmasq → Mihomo → Fake-IP
业务流量 → Q3000 → CodexR4S → R4S/Nikki/Mihomo → 代理节点

特殊服务：

text
services.googleapis.cn → YAML 第一条规则强制 Fake-IP → Google 策略组

境外 DNS：

text
8.8.8.8 / 1.1.1.1 DoH → 境外DNS通道 → 跨地区自动切换

整套方案真正稳定的原因，不是某一份域名名单足够长，而是每层职责都很清楚：

  • Mihomo 负责 DNS 分类、Fake-IP 映射和代理规则。
  • Q3000 负责根据大陆 IP 数据库选择真实道路。
  • dnsmasq 负责为全网客户端提供统一 DNS 入口。
  • Nikki 负责持久配置和 Mihomo 生命周期。
  • 境外DNS通道负责降低单一地区或节点故障对国外解析的影响。

理解这五层之后，遇到问题就可以准确判断它发生在“域名解析、IP 选路、透明接管、代理规则还是节点连接”，不再把所有故障都笼统归结为“网络慢”或“节点不行”。

内容由 WordPress 管理，静态页面由 VitePress 生成

Sirenyan Notes