本文是《Q3000 + R4S 分流终极指南：同一套大陆 IP 分流下的两种 DNS 方案》的续篇。上一篇文章对比了方案 A 与方案 B；本文只讲后来正式投入使用的方案 B：客户端网关仍为 Q3000，DNS 仍指向 R4S，但所有 DNS 查询统一交给 Mihomo 分类。本文记录最终结构、完整请求路径、关键 YAML、境外 DNS 通道、切换步骤、验收方法、故障边界和重装恢复。
一、为什么单独写这篇续篇
上一篇文章完成时，方案 A 已经稳定运行，方案 B 还只是经过配置验证、尚未正式切换。因此上一篇文章给出的阶段性建议是“生产继续使用方案 A”。
后续实际测试发生了变化：
方案 B 已正式切换并持续运行
淘宝、微信等国内应用正常
Google、YouTube、TikTok 等国外服务正常
ssh.cloud.google.com 长连接正常
Google Play 可以正常下载并完成安装
services.googleapis.cn 特例已由 YAML 统一处理
境外 DNS 已增加跨地区专用通道
旧的四千多条 dnsmasq 代理域名和自定义插件已移除
所以这篇文章不是推翻上一篇，而是把上一篇中的“候选方案 B”补全为一套已经落地、可以备份和重装恢复的正式方案。
二、先给出最终结论
当前网络的固定结构如下：
客户端地址：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 出口。
三、五个组件分别负责什么
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 先用四千多个域名分类
客户端 DNS 查询
↓
R4S dnsmasq
├─ 命中约四千多个代理域名 → Mihomo DNS
├─ 命中自定义插件域名 → Mihomo DNS
└─ 其余域名 → 国内普通 DNS
这种方式的优点是普通国内 DNS 不依赖 Mihomo；缺点是分类逻辑分散在自动域名表、更新脚本、自定义插件和 YAML 多处。
方案 B：dnsmasq 不再分类，全部交给 Mihomo
客户端 DNS 查询
↓
R4S dnsmasq
↓ 所有域名
127.0.0.1:1053
↓
Mihomo DNS 按 YAML 统一分类
因此方案 B 中已经不再需要：
/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 直接出网
名称：CodexCNDirect
来源：192.168.10.100-192.168.10.200
目标：CN4-A01～CN4-A08
出口：WAN1
优先级：高于下一条兜底规则
规则 2：其他地址交给 R4S
名称：CodexR4S
来源：192.168.10.100-192.168.10.200
目标：任意
下一跳：192.168.10.3
优先级：低于 CodexCNDirect
八个 CN4 分组只是大陆 IPv4 数据库。真正触发分流的是 CodexCNDirect 对这些分组的引用，而不是导入 IP 数据后自动发生魔法。
“被引用次数 1”表示有一条规则正在使用该分组，不表示访问次数。访问淘宝一万次，它仍然是 1。
这里还有两个不能省略的前提：
- Q3000 的 DHCP 固定地址和动态地址池必须落在这两条规则声明的来源范围内；超出
192.168.10.100-192.168.10.200的客户端不会自动套用这套分流，需要同步扩大来源范围或增加规则。 - R4S 自身地址
192.168.10.3不能包含在CodexR4S的来源范围内。Mihomo 建立到代理节点的连接时，来源是 R4S；排除它以后，Q3000 才会把该连接直接从 WAN1 发出，而不会再次送回 R4S 形成循环。
六、方案 B 的核心 DNS 配置
下面是当前实测配置中与方案 B 有关的部分。节点、订阅、控制密钥等私密内容不在本文展示。
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
default-nameserver:
- 223.5.5.5
- 119.29.29.29
它负责最基础的启动解析，例如先解析其他 DoH 服务器自身的域名。这里使用可在大陆直连的纯 IP DNS，避免 Mihomo 刚启动时需要“先解析 DNS 服务器，才能使用 DNS 服务器”的循环。
2. proxy-server-nameserver
proxy-server-nameserver:
- https://dns.alidns.com/dns-query
- https://doh.pub/dns-query
它专门解析代理节点服务器的域名。
假设订阅中的节点地址是：
sg-node.example.com
Mihomo 必须先知道这个节点域名对应的真实 IP，才能连上节点。这里使用阿里和腾讯的国内 DoH，即使全部代理节点当前都不可用，Mihomo 仍然可以查到各节点服务器的 IP，并在节点恢复后重新连接。
3. direct-nameserver
它用于直连流量需要重新解析域名时的国内 DNS。国内服务不需要绕到 Google DNS 或 Cloudflare DNS 查询。
4. nameserver-policy
它按域名规则集选择上游：
命中 cn_domain → 阿里 / 腾讯 DNS
命中 geolocation-!cn → Google / Cloudflare DNS，并经过境外DNS通道
5. nameserver
它是没有被更具体策略选中的默认业务 DNS。在本方案中使用 Google 和 Cloudflare DoH，并明确绑定“境外DNS通道”。
所以它们不是“一个覆盖另一个”的单一优先级列表，而是：
启动解析 → default-nameserver
代理节点域名 → proxy-server-nameserver
直连重解析 → direct-nameserver
已知域名分类 → nameserver-policy
其余普通查询 → nameserver
八、fake-ip-filter-mode: rule 为什么关键
旧配置常见的是：
fake-ip-filter-mode: blacklist
在 blacklist 模式下，fake-ip-filter 更像“不使用 Fake-IP 的例外名单”。这不适合本方案，因为我们需要明确表达四种结果：国内真实 IP、国外 Fake-IP、兼容性域名真实 IP、特殊国外服务强制 Fake-IP。
规则模式会从上到下判断，第一条命中即停止：
- DOMAIN,services.googleapis.cn,fake-ip
Google Play 特例优先返回 Fake-IP。
- RULE-SET,fakeipfilter_domain,real-ip
局域网发现、时间同步和部分不兼容 Fake-IP 的域名返回真实 IP。
- RULE-SET,cn_domain,real-ip
已知国内域名返回真实 IP，让 Q3000 可以命中大陆 IP 库。
- RULE-SET,geolocation-!cn,fake-ip
已知国外域名返回 Fake-IP，使 Q3000 稳定地把后续业务连接交给 R4S。
- MATCH,real-ip
无法确定的新域名保守地返回真实 IP，最后由 Q3000 的大陆 IP 库判断走 WAN1 还是 R4S。
必须再次强调：
fake-ip-filter只决定 DNS 回答是真实 IP 还是 Fake-IP，不直接等于DIRECT或PROXY。真正的业务连接到达 R4S 后，还要由 YAML 的正式rules:再判断一次。
九、国内服务的完整闭环
下面以手机打开淘宝为例，把 DNS 阶段和真实流量阶段完整分开。
第一阶段：查询淘宝的 IP
淘宝 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）
第二阶段：真正访问淘宝
淘宝 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
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
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 之前：
fake-ip-filter:
- DOMAIN,services.googleapis.cn,fake-ip
- RULE-SET,fakeipfilter_domain,real-ip
- RULE-SET,cn_domain,real-ip
完整闭环如下：
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通道”
国外域名会使用：
https://8.8.8.8/dns-query
https://1.1.1.1/dns-query
在大陆网络中，不能假设它们始终可以稳定直连。若它们跟随普通“默认代理”，DNS 能否工作就会依赖默认策略当时选中的单一地区或节点。
因此单独建立一个只服务于境外 DNS 的跨地区组：
proxy-groups:
- name: 境外DNS通道
type: fallback
url: https://www.gstatic.com/generate_204
interval: 60
lazy: false
proxies:
- 新加坡-故转
- 香港-故转
- 日本-故转
- 台湾-故转
- 美国-故转
然后把境外 DoH 明确绑定到它：
- https://8.8.8.8/dns-query#境外DNS通道
- https://1.1.1.1/dns-query#境外DNS通道
它的运行逻辑是：
每 60 秒主动检测候选通道
↓
优先使用列表中第一个健康地区
↓
当前地区失效
↓
自动切换到下一个健康地区
健康检查使用 Google 的 generate_204，因为这个组的任务就是访问境外 DNS。国内连通性测试只能证明节点“能联网”，不能充分证明它可以稳定访问 Google 或 Cloudflare DNS。
这个组不放 DIRECT 作为最后候选。原因是大陆直连 8.8.8.8 或 1.1.1.1 并不是可靠兜底，反而会让故障表现变得随机。
但也要理解它的边界：
- 一个地区故障：自动换其他地区。
- 一个节点故障：对应地区组可以继续选择其他健康节点。
- 所有代理地区全部故障：境外 DNS 仍会失败。
- Mihomo 进程停止：国内外 DNS 都会失败，因为 dnsmasq 的唯一上游就是 Mihomo。
“境外DNS通道”提高的是代理节点局部故障时的可用性，不是让完全不可用的节点恢复工作。
十三、为什么不会形成 DNS 死循环
常见担心是：
访问 Google DNS 需要代理
代理节点域名又需要 DNS
DNS 还没工作，节点就无法连接
本方案用不同 DNS 角色拆开了这个循环：
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. 完整备份
至少保存：
/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 的持久配置，例如：
/etc/nikki/profiles/nikki_optimized_config.yaml
不要只修改：
/etc/nikki/run/config.yaml
运行配置由 Nikki 生成，重启或重新应用后可能被覆盖。
把本文第六节的 DNS 片段合并到现有唯一的 dns: 段中。不能在文件底部再增加第二个 dns:。
同时确保规则集存在：
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 内核检查候选文件：
/usr/bin/mihomo -t -d /etc/nikki/run -f /tmp/scheme-b-candidate.yaml
看到类似下面的结果才可以继续：
configuration file ... test is successful
4. 应用 YAML 并重启 Nikki
建议先准备 5～10 分钟自动回滚，再原子替换持久 YAML，最后只重启 Nikki。
确认：
/etc/init.d/nikki status
应返回：
running
5. 让 dnsmasq 全部转给 Mihomo
LuCI 路径：
网络 → DHCP/DNS → 转发 → DNS 转发
只保留：
127.0.0.1#1053
对应的 UCI 操作为：
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 上执行：
nslookup taobao.com 127.0.0.1
nslookup google.com 127.0.0.1
nslookup services.googleapis.cn 127.0.0.1
预期结果：
taobao.com → 真实大陆 IP
google.com → 198.18.x.x
services.googleapis.cn → 198.18.x.x
建议再测试：
baidu.com → 真实大陆 IP
youtube.com → 198.18.x.x
2. 境外 DNS 通道
在 Zashboard 的“代理”页面检查：
境外DNS通道
类型：Fallback
状态：Alive
当前：某个健康地区组
在“连接”页面检查 8.8.8.8 和 1.1.1.1，代理链应包含：
当前节点 → 地区手动/自动组 → 地区故转组 → 境外DNS通道
3. 应用验收
□ 淘宝首页、搜索、图片和视频正常
□ 微信消息、朋友圈图片和小程序正常
□ 国内银行及生活服务 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 等本机代理。
浏览器 → 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 正常，某个代理节点故障
国内 DNS → 阿里 / 腾讯 DNS → 正常
国内真实流量 → Q3000 WAN1 → 正常
境外 DNS → 境外DNS通道自动切换地区
全部代理节点故障，但 Mihomo 仍在运行
国内 DNS → 仍可由国内上游解析
国内真实流量 → 仍可由 Q3000 WAN1 直连
境外 DNS / 国外代理访问 → 失败
代理节点域名 → 仍可由 proxy-server-nameserver 解析
Mihomo 进程停止
dnsmasq 仍监听 192.168.10.3:53
但唯一上游 127.0.0.1:1053 不可用
国内外新域名都无法解析
已有缓存和既有长连接可能暂时继续工作
R4S 断电或网线断开
客户端 DNS 固定为 192.168.10.3，所以新域名都无法解析。这个物理故障不属于 DNS 规则能够解决的范围。
因此方案 B 的真实取舍是：
配置集中、覆盖完整、重装简单，但 Mihomo 成为全网 DNS 的关键服务。
十八、备份、回退与重装恢复
方案 B 的最小恢复清单
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 时需要恢复
旧 Nikki YAML
旧 /etc/config/dhcp
四千多条 dnsmasq 代理域名文件
自定义域名例外文件
自动更新脚本与 cron 任务
域名分流 LuCI 插件
最可靠的做法不是现场凭记忆重建，而是提前准备一键备份、一键应用和一键回退脚本，并在执行网络修改前设置定时自动回滚。
十九、日常维护建议
每月检查
□ 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 或订阅后检查
□ 节点域名仍能被 proxy-server-nameserver 解析
□ 地区组名称没有改变
□ 境外DNS通道引用的五个地区组仍存在
□ 应用专用规则没有被更宽泛规则提前截获
□ Nikki 混入设置没有覆盖 YAML 中的 DNS 配置
大陆 IPv4 库
当前八个 CN4 分组是保存在 Q3000 内部的地址数据，访问时不依赖外部脚本。但一次性导入的快照不会自动跟随地址分配变化，长期使用应增加定期同步、差异检查和自动备份。
二十、可直接交给 Codex 的提示词
1. 切换方案 B
请先完整备份 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. 诊断国内应用变慢
请保持现有 Q3000 + R4S 方案 B 不变，分别检查 DNS 阶段和真实业务流量阶段。确认目标国内域名是否命中 cn_domain 并返回真实大陆 IP，Q3000 是否命中 CodexCNDirect，真实流量是否从 WAN1 直出。不要只根据 Zashboard 是否出现连接判断，也不要未经验证修改节点或全局 DNS。
3. 诊断国外服务打不开
请检查该服务实际使用的主域名、子域名、CNAME 和 CDN 域名；确认 DNS 返回 Fake-IP 还是实际 IP，Q3000 是否把连接送到 R4S，Mihomo 的正式 rules 命中了哪个规则集和策略组，境外DNS通道是否健康。对比 PC Clash 与 R4S 使用同一节点时的 DNS、QUIC、IPv6、MTU 和代理链，不要先假设是节点问题。
4. 重装后恢复
请在全新 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”。准确说法是：
所有 DNS 查询都经过 Mihomo 分类
但不是所有真实业务流量都经过 Mihomo
国内服务：
DNS → R4S dnsmasq → Mihomo → 国内 DNS → 真实大陆 IP
业务流量 → Q3000 → CodexCNDirect → WAN1
国外服务：
DNS → R4S dnsmasq → Mihomo → Fake-IP
业务流量 → Q3000 → CodexR4S → R4S/Nikki/Mihomo → 代理节点
特殊服务：
services.googleapis.cn → YAML 第一条规则强制 Fake-IP → Google 策略组
境外 DNS：
8.8.8.8 / 1.1.1.1 DoH → 境外DNS通道 → 跨地区自动切换
整套方案真正稳定的原因，不是某一份域名名单足够长，而是每层职责都很清楚：
- Mihomo 负责 DNS 分类、Fake-IP 映射和代理规则。
- Q3000 负责根据大陆 IP 数据库选择真实道路。
- dnsmasq 负责为全网客户端提供统一 DNS 入口。
- Nikki 负责持久配置和 Mihomo 生命周期。
- 境外DNS通道负责降低单一地区或节点故障对国外解析的影响。
理解这五层之后，遇到问题就可以准确判断它发生在“域名解析、IP 选路、透明接管、代理规则还是节点连接”，不再把所有故障都笼统归结为“网络慢”或“节点不行”。