Clash Verge Rev 完整使用指南：从界面认识到进阶配置的全流程详解

装好 Clash Verge Rev 之后，真正的重点才刚开始。这个客户端的功能密度很高，界面上七大类菜单（代理、订阅、连接、规则、日志、测试、设置）里藏着不少有意思的能力，其中 Merge 混合配置和 JavaScript 脚本是它区别于同类软件的核心竞争力。

这篇指南会从界面讲起，一路覆盖到进阶配置与性能调优，目标是让你在读完之后能独立完成从「刚装好」到「按自己想法精细控制」的全过程。

目录

1. 界面布局与核心概念
2. 四种代理模式的本质区别
3. 配置文件生命周期管理
4. Merge 混合配置机制
5. TUN 模式详解
6. 规则系统编写
7. 日志与诊断
8. 性能优化
9. 多设备协同
10. 进阶：脚本处理配置

一、界面布局与核心概念

主界面结构

打开软件后，左侧是垂直导航栏，右侧是内容区。整体结构大致如下：

┌──────────┬──────────────────────────────┐
│  代理     │                              │
│  订阅     │                              │
│  连接     │      内容展示区               │
│  规则     │                              │
│  日志     │                              │
│  测试     │                              │
│  设置     │                              │
├──────────┴──────────────────────────────┤
│  系统代理开关    当前节点    实时速率       │
└─────────────────────────────────────────┘

底部状态栏是日常使用中最常看的地方：左边是全局代理开关，中间显示当前出站节点，右边是实时上下行速率。

三个必须先理解的概念

很多新手的困惑其实源于混淆了这三个层次：

它们的从属关系是：订阅拉取内容 → 生成配置 → 配置里包含节点。理解了这条链路，界面上很多操作就自然说得通了。

另一个容易混淆的是代理组（Proxy Group）。它是节点的容器，负责按策略（自动测速、故障转移、手动选择等）从中挑一个出站。节点本身不会直接被使用，必须归属于某个代理组。

二、四种代理模式的本质区别

这是最核心也最容易搞混的一节。「代理」页面顶部通常有几种模式可选，它们的工作原理完全不同。

全局模式（Global）

所有流量都走代理，不做任何判断。

应用程序 → 客户端 → 代理节点 → 目标网站
（全部流量，无例外）

优点：最简单，行为可预测。 缺点：访问国内服务也会绕一圈，速度慢且浪费流量。 适用：排查问题、或确实需要全局走代理的场景。

规则模式（Rule）

按规则列表逐条匹配，决定每笔流量的去向。这是日常使用的推荐模式。

应用程序 → 客户端 → 匹配规则？
                   ├─ 命中直连规则 → 直接连接
                   ├─ 命中代理规则 → 代理节点
                   └─ 未命中 → 走兜底规则

规则是从上往下匹配的，命中第一条就不再继续。因此规则顺序非常重要，一条宽泛的规则放在顶部会让后面所有规则失效。

适用：绝大多数场景，兼顾国内直连与需要代理的访问。

直连模式（Direct）

关闭代理，所有流量直连。

适用：临时需要完全排除客户端影响时（比如排查网络问题是否为客户端所致）。

脚本模式（Script）

用 JavaScript 自定义判断逻辑，复杂度最高但自由度也最高。属于进阶功能，多数用户用不到。

各模式对比

实践建议：日常长期挂「规则模式」。只有当你怀疑某个网站没走代理、想验证是配置问题还是节点问题时，才临时切到「全局」测试——这是最有效的判断方法。

三、配置文件生命周期管理

导入配置的三种方式

方式一：URL 导入（最常用）

在「配置」页粘贴订阅链接，点击导入。适合长期订阅，可设置自动更新。

方式二：本地文件导入

选择本地 YAML 文件。适合一次性使用或自己编写的配置。注意本地文件不会自动更新。

方式三：拖拽

直接把 YAML 文件拖进窗口，效果同方式二。

自动更新的设置

对于 URL 订阅，建议配置自动更新：

更新过于频繁（如每小时）会显著增加被订阅方限制的概率，不建议这么做。

多配置并存的管理策略

如果你有多个来源，这里有两条路线：

路线 A（传统）：手工把所有来源合并成一个 YAML，反复维护 路线 B（推荐）：使用 Merge 机制，见下一节

四、Merge 混合配置机制

这是 Clash Verge Rev 的标志性功能，也是它相对同类软件最大的优势之一。

它解决什么问题

假设你有这样的需求：

• 主用 A 源的节点
• 备用 B 源的节点
• 自己维护了一份精心打磨的分流规则

传统做法下，每次 A 源更新，你得重新手工把三者拼在一起。而 Merge 的思路不同：

┌─────────────┐
│  A 源（节点）  │──┐
├─────────────┤  ├─→ Merge 引擎 → 最终生效配置
│  B 源（节点）  │──┤
├─────────────┤  │
│  本地规则文件  │──┘
└─────────────┘

每个来源独立存在、独立更新，由 Merge 在运行时合成最终配置。你的规则文件再也不需要动。

基本使用

1. 进入「配置」页
2. 找到 Merge 区域，启用
3. 按顺序添加参与合并的配置源
4. 保存后重新加载配置

顺序很重要：后添加的会覆盖前面的同名内容。因此通常把「本地规则」放最后，确保它不会被上游覆盖。

典型应用场景

注意事项

• Merge 是深合并，同名字段会被后者覆盖，数组类型要注意是否会整体替换
• 若上游配置结构异常，Merge 可能失败，此时应检查日志中的具体报错
• 改动 Merge 后需要重新加载配置才生效

详细的实操案例见《Merge 混合配置实战教程》。

五、TUN 模式详解

它解决什么问题

系统代理是通过修改操作系统的代理设置实现的，只有遵循这个设置的程序才会走代理。以下情况走不了：

• 大部分游戏客户端
• 命令行工具（部分需单独配置）
• 某些使用自有网络栈的应用
• UDP 流量（某些场景）

TUN 模式的思路截然不同：它在系统中创建一张虚拟网卡，然后从网卡层面接管流量。

【系统代理】                    【TUN 模式】
应用 → 询问系统代理 → 走代理     应用 → 虚拟网卡 → 客户端接管 → 走代理
     （不遵守的会绕过去）              （无法绕过，全部接管）

如何开启

在「代理」页找到 TUN 模式开关。首次开启动会请求管理员/root 权限，因为创建虚拟网卡需要系统级权限。

Windows 上会短暂弹出 UAC 窗口，macOS 和 Linux 上需要输入密码。

两种工作方式的取舍

建议：日常使用场景下不必一直开着 TUN。它是个按需工具，需要时打开即可，不必默认常开。

六、规则系统编写

规则的五种类型

Clash 的规则支持多种匹配维度：

语法统一为：规则类型,匹配值,目标代理组

匹配顺序至关重要

规则是从上往下、命中即停的。因此：

✓ 正确顺序：
  1. DOMAIN-SUFFIX,specific.service.com,PROXY   （特例放前面）
  2. DOMAIN-SUFFIX,service.com,DIRECT           （宽泛规则放后面）

✗ 错误顺序：
  1. DOMAIN-SUFFIX,service.com,DIRECT           （宽泛规则先命中）
  2. DOMAIN-SUFFIX,specific.service.com,PROXY   （永远不会执行）

一份基础的自定义规则

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

  # 特定服务走代理
  - DOMAIN-SUFFIX,github.com,PROXY
  - DOMAIN-KEYWORD,wikipedia,PROXY

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

  # 兜底规则：未命中的全部走代理
  - MATCH,PROXY

最后那条 MATCH 是兜底，必须写在最后。它相当于「其余情况」的默认处理。

进程规则与 TUN 的配合

PROCESS-NAME 这类基于进程的规则只在 TUN 模式下可用，因为系统代理模式下，客户端拿不到发起请求的进程信息。

这使得「指定某款游戏直连、其余走代理」这类需求只能在 TUN 模式下实现。

七、日志与诊断

日志级别

在「日志」页可以调整级别：

排查问题时建议先切到 debug，问题定位后再切回 info——长期开 debug 会持续产生磁盘写入。

从日志读什么

一条典型的连接日志包含这些信息：

[INFO] [TCP] 192.168.1.100:51234 --> example.com:443
       match(DOMAIN-SUFFIX,example.com) using PROXY[节点名称]

解读顺序：

1. 协议与方向 — TCP/UDP，来源地址与端口
2. 匹配到的规则 — 说明它命中了哪条规则
3. 使用的出站 — 最终走的是代理还是直连，以及具体节点

如果某网站访问异常，先看它命中了什么规则，这是最快的定位方式——通常问题出在「本以为会走代理，结果命中了直连规则」。

连接面板

「连接」页展示当前所有活跃连接。便于：

• 确认某个应用是否真的走代理
• 观察实时速率异常
• 手动终止可疑连接

八、性能优化

内存占用

基于 Tauri 架构，正常运行时的内存占用通常在 80–150 MB 区间。若明显高于这个水平：

1. 检查是否开启了 debug 日志
2. 检查订阅节点数量是否过多（几千个节点会显著增加开销）
3. 重启释放可能的内存碎片

CPU 占用

正常情况下 CPU 占用极低。持续高占用通常源于：

• 频繁测速 — 缩短自动测速间隔
• 节点数量过大 — 节点越多，健康检查和规则匹配开销越大
• 日志级别过高 — 见上一节

启动速度

若启动变慢，常见原因是配置体积膨胀。可以尝试：

• 用 Merge 拆分过大的配置文件
• 检查是否存在大量无用节点
• 清理旧的配置备份

建议的性能相关设置

九、多设备协同

配置文件共享

配置目录本质是一组 YAML 文件，可以用任意同步方式在设备间共享：

跨设备的字段差异

同步时要注意，不同设备上有几个字段通常需要单独调整：

• 监听端口 — 避免与其他软件冲突
• 网卡名称 — TUN 模式下各 system 网卡名不同
• 路径相关配置 — 外部 UI、配置文件路径

建议把这些字段放在 Merge 链的最上层，由每台设备单独覆盖。

移动端搭配

桌面端获益于完整的 Merge 和脚本能力，而移动端则可以用同一份订阅链接，这样节点列表天然保持一致。真正的差异只在规则复杂度上——移动端通常依赖服务商提供的默认规则。

十、进阶：脚本处理配置

这是最灵活也最复杂的一块。

脚本能做什么

JavaScript 脚本可以在配置加载的特定阶段执行，常见用途：

• 节点重命名 — 把杂乱的 香港 01 节点 [1.0x] 规范化
• 节点过滤 — 剔除含特定关键词或负载过高的节点
• 自动分组 — 按地区、按倍率自动归入不同代理组
• 注入自定义规则 — 动态插入规则段

一个简单的示例

// main 函数会在配置加载时被调用
function main(config) {
  // 只保留名称中不含「测试」的节点
  config.proxies = config.proxies.filter(p => !p.name.includes('测试'));

  // 统一去除名称里的多余后缀
  config.proxies.forEach(p => {
    p.name = p.name.replace(/\s*\[.*?\]\s*/g, '').trim();
  });

  return config;
}

这段代码做了两件事：过滤掉含「测试」的节点，并清理名称中的方括号内容。

使用建议

1. 先备份再修改 — 脚本出错会导致配置加载失败
2. 小步验证 — 一次只加一个逻辑，确认生效后再加下一条
3. 注意性能 — 节点数量大时，复杂循环会拖慢加载
4. 语法要严谨 — 建议在外部编辑器里写好再粘贴进来

小结

回顾整条路径，从装好到用得顺，关键节点其实就四处：

1. 理解三层结构 — 订阅 → 配置 → 节点，理清楚之后界面操作都会变得自然
2. 选对代理模式 — 日常用规则模式，全局模式只作排查用
3. 善用 Merge — 多订阅用户的效率提升点，一次配置长期受益
4. 会看日志 — 任何异常先在日志里找「命中了哪条规则」，能解决大部分问题

至于 TUN 和脚本，属于按需使用的进阶工具，不必一开始就上手。等你遇到系统代理解决不了的场景时，再回来翻这两节也不迟。

想了解更具体的 Merge 实操案例，可以继续看本站的《Merge 混合配置实战教程》；如果遇到了具体问题，《Clash Verge Rev 故障排查手册》里有按症状分类的解决方案。