Clash Verge Rev Merge 混合配置实战：多订阅管理与规则分离的优雅方案

如果你同时使用多个订阅源，或者希望自己维护一份精心打磨的分流规则，那么 Merge（混合配置）会彻底改变你的使用方式。这是 Clash Verge Rev 相对同类客户端最具差异化的能力之一。

这篇教程会把 Merge 的工作原理讲透，并给出三种可以直接照抄的完整配置。

一、Merge 到底解决什么问题

没有 Merge 时的日常

假设你有这样的配置需求：

• 主用订阅 A，提供大部分节点
• 备用订阅 B，作为补充
• 自己维护了一份规则文件，经过几周调优已经很好用

按传统做法，你需要：

1. 分别下载 A、B 两个订阅的 YAML
2. 手工拼接两者的 proxies 段落
3. 删除重复的代理组定义
4. 把自己的规则追加到 rules 末尾
5. 保存为单一配置文件并导入

然后每次 A 或 B 更新，以上五步重来一遍。

如果有自动化脚本，情况会好一点——但脚本本身要维护，遇到上游结构变动还得改。

Merge 的做法

Merge 把这件事变成了一次配置，长期自动：

订阅 A ──┐
订阅 B ──┼──→ [Merge 引擎] ──→ 运行时合成的最终配置
本地规则 ─┘

每个来源保持独立。A 更新了？不影响 B，也不影响你的规则文件。你改了规则？不需要重新拼接任何东西。

效率对比

这张表里最关键的一行是「订阅更新后」——手工合并的维护成本会随着时间不断累积，而 Merge 是一次性投入。

二、工作原理

合并的时机

Merge 发生在配置加载时，而不是修改磁盘文件。这意味着：

• 你的原始文件始终保持干净独立
• 每次重新加载都会重新合成
• 合成结果不会写回源文件

合并的顺序规则

后加入的源会覆盖先加入的同名内容。 这是最核心的规律。

举个具体例子：

源 1（订阅 A）：   port: 7890
源 2（本地规则）： port: 7891
                    ↓
合并结果：          port: 7891   ← 后者胜出

因此，你在做配置时必须清楚自己想让谁说了算。通常我们希望：

订阅（提供节点，可能带默认规则）
  ↓ 被覆盖
本地文件（提供我们想要的设置与规则）

所以本地文件应该排在 Merge 链的最后。

字段合并的差异

不同类型的字段，合并行为不完全一样：

尤其注意 rules 是追加而非覆盖 —— 这意味着你要小心规则顺序：上游规则会排在前面，你的规则排在后面，而规则是命中即停的。

三、场景一：多订阅合并

适用情况

你有两个及以上订阅源，希望节点汇总使用。

配置步骤

1. 打开「配置」页
2. 找到 Merge 区域，启用
3. 依次添加订阅 A、订阅 B（都以 URL 形式）
4. 保存并重新加载配置

注意事项

• 节点重名问题 — 若两个源有同名节点，通常需要 manual 处理，否则可能出现意外覆盖
• 代理组冲突 — 两个源若都定义了同名代理组（如都叫 PROXY），后者的定义会整体替换前者
• 更新频率 — 每个源可以单独设置，建议统一为 24 小时

验证是否生效

加载完成后：

1. 进入「代理」页，检查节点总数是否约等于两源之和
2. 若数量异常少，说明存在大面积重名或被代理组过滤

四、场景二：规则与节点分离（最推荐）

这是我认为最值得推荐的用法，也是最能体现 Merge 价值的地方。

核心思路

┌─────────────────┐
│  订阅（纯节点）    │  ← 只关心节点的增减，不关心规则
└────────┬────────┘
         │ Merge
┌────────┴────────┐
│  本地规则文件     │  ← 你精心维护的规则、DNS、端口等设置
└─────────────────┘

好处：订阅更新时，你的规则完全不受影响。哪怕换了一个新的订阅源，也只需要换 URL，规则文件一行不用改。

本地规则文件示例

创建一个 my-rules.yaml，内容大致如下：

# ===== 基础设置 =====
port: 7890
socks-port: 7891
allow-lan: false
mode: rule
log-level: info

# ===== DNS 配置 =====
dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
  fallback:
    - https://1.1.1.1/dns-query
    - https://dns.google/dns-query

# ===== 规则部分 =====
rules:
  # 本地与内网一律直连，必须放在最前
  - DOMAIN-SUFFIX,localhost,DIRECT
  - IP-CIDR,127.0.0.0/8,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT
  - IP-CIDR,10.0.0.0/8,DIRECT
  - IP-CIDR,172.16.0.0/12,DIRECT

  # 国内常见服务直连
  - GEOIP,CN,DIRECT
  - DOMAIN-SUFFIX,cn,DIRECT

  # 兜底走代理
  - MATCH,PROXY

配置顺序

在 Merge 链中：

第 1 层：订阅 URL（提供 proxies 与 proxy-groups）
第 2 层：my-rules.yaml（提供 DNS、端口、rules）

切记本地文件放最后，否则它的设置会被订阅覆盖。

为什么这个方案好用

长期使用的维护成本差距非常大。

五、场景三：多层覆盖做精细控制

进阶用法是建立三层结构：

第 1 层：订阅 URL          → 节点来源
第 2 层：base.yaml        → 通用设置（DNS、端口、plus-box 等）
第 3 层：device.yaml      → 本机专属（端口微调、网卡名、路径）

为什么需要第 3 层？ 当你多台设备共享配置时，有些字段必须因机而异：

• 某台机器的 7890 端口已被占用
• Linux 和 Windows 的网卡名不同
• 不同设备的配置路径不同

把这些放进 device.yaml，前两层就可以放心共享。

device.yaml 示例

# 本机专属覆盖
port: 7892              # 这台机器的端口被占用了
mixed-port: 7893
external-controller: 127.0.0.1:9097

文件很短，但解决了共享配置的最后一公里问题。

六、常见故障排查

七、与其他方案的取舍

Merge vs 单文件

如果你只有一个订阅且从不自定义规则，单文件足够。但只要符合以下任一条件，就值得上 Merge：

• 两个及以上订阅
• 想自定义规则
• 多台设备共享配置

Merge vs 外部生成工具

市面上有第三方工具能把多个订阅合成一个链接。它们和 Merge 的区别是：

从隐私角度考虑，Merge 更优 —— 你的订阅链接和配置内容不需要经过第三方服务器。这一点对于在意数据流向的用户来说很重要。

八、实践建议清单

配置 Merge 时建议遵循：

• 本地文件放在 Merge 链的最后，确保设置不被覆盖
• 每个 Merge 源都有明确的职责，不重复配置同一字段
• 修改后记得手动重新加载配置
• 首次配置完成后先备份一份，再继续微调
• 用日志验证关键规则是否按预期命中
• 多设备场景下，把机器相关的字段单独抽到最上层

小结

Merge 的学习成本大概在半小时左右，但它能省下的长期维护时间是这个数字的好几倍。

建议的进阶路径：

1. 先掌握场景二（规则与节点分离）—— 收益最高，配置最简单
2. 熟悉后再加入多个订阅源
3. 多设备用户再引入第三层的设备专属文件

不必一开始就把三层结构搭齐。从最实用的那层开始，遇到问题再往上加，这样每一步都能实际感受到收益。

如果配置过程中遇到了具体问题，《Clash Verge Rev 故障排查手册》按症状分类整理了解决方案；想了解规则本身怎么写，《规则分流配置详解》里有完整的语法说明。