Custom Rules Tutorial

Custom Rules Tutorial

欢迎来到 Clash Verge Rev 自定义规则（Custom Rules）教程。

很多用户第一次打开 Clash Verge Rev 时，都会把注意力放在节点数量、延迟测速或者 TUN 模式上，却很少有人真正去了解 Rule（规则） 是如何工作的。

实际上，无论你使用的是 Shadowsocks、Trojan、VMess、VLESS Reality、WireGuard 还是 Hysteria2，真正决定流量走向的，并不是协议本身，而是 Mihomo 内核中的规则系统。

很多人会发现，同样的订阅、同样的节点，在两台电脑上的使用体验却完全不同。有的人访问国内网站速度很快，海外网站切换流畅；而有的人却遇到国内网站绕路、国外网站无法打开，甚至 AI 工具、游戏平台、开发工具都出现连接异常。

造成这些差异的原因，很多时候并不是节点，而是规则配置。

学习自定义规则，并不是为了让配置文件变得更复杂，而是为了让网络行为更加符合自己的使用习惯。你可以决定哪些网站直接连接、哪些服务始终通过代理、哪些应用使用指定节点，甚至不同的软件走不同的出口线路。

对于长期使用 Clash Verge Rev 的用户来说，规则并不是高级玩法，而是日常配置中最值得投入时间学习的一部分。

---

为什么要学习自定义规则？

很多人第一次接触 Clash Verge Rev 时，只需要完成三件事：

• 安装软件。
• 导入订阅。
• 选择一个节点。

整个过程不到几分钟，软件就已经可以正常使用。

这也是为什么不少用户会认为："规则不是已经内置了吗？我为什么还要学习？"

事实上，大多数订阅提供的规则，目标都是满足"大多数人"的需求，而不是你的需求。

举一个简单的例子。

假设你每天都会使用以下服务：

• GitHub
• Microsoft Copilot
• ChatGPT
• Google Drive
• Apple iCloud
• Steam
• Telegram

与此同时，你还需要访问大量国内网站，例如：

• Bilibili
• 微信
• 支付宝
• 淘宝
• 京东

如果完全依赖默认规则，有些网站可能会被错误分流，有些流量可能绕到海外节点，还有一些服务可能因为 DNS 解析方式不同而出现连接异常。

这些问题并不会直接提示错误，而是表现为：

• 网页打开很慢。
• 登录偶尔失败。
• 图片加载不完整。
• 软件更新异常。
• 下载速度忽快忽慢。
• 视频缓冲时间变长。

很多用户会误以为是节点质量不好，于是不断更换节点。

事实上，真正需要调整的，可能只是几条规则。

---

什么是 Rule？

简单来说，Rule 就是一套"判断条件"。

每当电脑发起一个网络请求时，Mihomo 都会按照规则逐条检查，然后决定这次请求应该如何处理。

例如：

• 是否直接连接？
• 是否经过代理？
• 是否拒绝访问？
• 是否交给某个代理组？
• 是否走指定节点？

整个过程几乎在瞬间完成，因此用户通常感觉不到规则正在工作。

可以把它想象成高速公路收费站。

每一辆车到达收费站后，工作人员都会查看车辆信息，然后决定：

• 走哪条车道。
• 是否需要检查。
• 是否允许通行。
• 最终驶向哪个方向。

Rule 的作用也是如此。

它不会改变数据内容，而是决定数据应该走哪一条路。

---

一次网络请求是怎样完成匹配的？

假设你打开浏览器，访问：

https://github.com

浏览器首先会发起域名解析请求。

随后，Mihomo 会接收到这次网络请求，并开始按照配置文件中的规则逐条匹配。

例如：

DOMAIN,github.com,PROXY
DOMAIN-SUFFIX,githubusercontent.com,PROXY
GEOSITE,CN,DIRECT
MATCH,PROXY

Mihomo 会从第一条开始检查：

第一条是否匹配？

如果匹配成功，立即结束。

如果没有命中，则继续检查第二条。

仍然没有命中，再继续检查第三条。

直到找到第一条符合条件的规则。

一旦命中，后面的规则将不会继续执行。

这也是为什么规则顺序远比规则数量更重要。

很多新手喜欢不断添加规则，希望配置越来越完善。

实际上，如果顺序错误，再多的规则也不会生效。

---

为什么规则顺序比节点更重要？

很多人认为：

节点决定速度。

其实这句话只说对了一半。

节点决定的是网络出口。

规则决定的是：

"这次请求到底会不会使用这个节点。"

举个例子。

如果 GitHub 被错误匹配到 DIRECT，那么无论你的代理节点速度有多快，GitHub 都不会经过代理。

相反，如果国内视频网站被错误匹配到 PROXY，那么即使节点性能很好，也会因为绕路导致访问速度下降。

因此，一个合理的规则配置，往往比不断切换节点更能提升整体体验。

很多用户在更换节点后觉得"速度变快了"，实际上只是因为新的节点使用了不同的规则配置，而不是节点本身更优秀。

---

默认规则真的够用吗？

答案取决于你的使用场景。

如果只是偶尔浏览网页，默认规则通常已经可以满足需求。

但如果你经常使用：

• GitHub
• Docker Hub
• VS Code
• JetBrains IDE
• Cursor
• Microsoft Copilot
• ChatGPT
• Claude
• Gemini
• OpenAI API
• Steam
• Epic Games
• Battle.net

你很快就会发现，不同服务对于网络环境有不同要求。

有些适合代理。

有些适合直连。

有些需要根据地区动态选择线路。

有些甚至需要单独指定节点。

这些都是默认规则很难完全覆盖的。

因此，自定义规则真正解决的不是"能不能访问"，而是"如何访问得更合理、更稳定、更高效"。

---

自定义规则并不是越多越好

这是很多用户都会踩到的一个误区。

刚开始学习规则时，很容易认为：

"规则越详细越专业。"

于是不断添加新的规则。

几个月之后，配置文件可能已经达到几千甚至上万行。

但真正起作用的，可能只有其中一小部分。

规则数量增加意味着：

• 匹配逻辑更复杂。
• 后期维护更困难。
• 排查问题耗时更长。
• 更容易出现重复规则。

一个好的规则配置，并不是规则最多，而是结构清晰、命中准确、易于维护。

很多长期维护配置的用户，都会定期整理规则，删除已经没有意义的内容，让配置保持简洁。

这也是后续章节会重点介绍的内容。

---

本系列教程会学到什么？

这不是一篇只介绍几个 YAML 语法的教程。

接下来的内容，我们会结合 Clash Verge Rev 与 Mihomo 的实际使用场景，逐步介绍：

• Rule 的完整匹配流程。
• 为什么规则顺序如此重要。
• DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD 的区别。
• GEOIP 与 GEOSITE 的实际应用。
• Rule Provider 与 RULE-SET 的维护方式。
• 如何为 GitHub、Google、Steam、Microsoft、Apple、Telegram 等服务编写更合理的规则。
• 如何根据自己的网络环境持续优化配置，而不是频繁更换节点。

希望读完这个系列之后，你不仅知道"规则怎么写"，更能够理解"为什么要这样写"，并建立起一套适合自己的规则体系。

---

下一步阅读

完成本篇内容后，建议继续阅读下一章节：

➡ Understanding-Rule-Matching

在下一篇中，我们将深入介绍 Mihomo 是如何逐条匹配规则的，包括规则执行流程、命中机制、为什么第一条规则如此重要，以及很多用户容易忽略的几个匹配细节。这些基础知识将帮助你更容易理解后续所有规则配置内容。

Part 2：理解 Rule Mode 与规则匹配顺序

在上一部分中，我们已经知道，每一次网络请求都会经过 Mihomo 的规则系统。

这一节，我们不急着编写规则，而是先理解一个更重要的问题：

规则到底是按照什么顺序工作的？

很多用户配置了几十条甚至上百条规则，却发现修改了一条规则没有任何变化，或者明明添加了新规则，却始终没有生效。

这些问题，大多数都不是规则写错了，而是没有理解 Mihomo 的匹配机制。

如果把这一部分理解透彻，后面学习任何规则类型都会轻松很多。

---

Rule Mode 是什么？

打开 Clash Verge Rev 后，在代理模式中通常可以看到几个选项：

• Rule
• Global
• Direct

不少新用户看到这些名称时会有些困惑。

实际上，这三个模式决定的是 Mihomo 如何处理所有网络请求。

其中，最推荐长期使用的就是 Rule 模式。

因为它能够根据不同网站、不同应用以及不同网络请求，自动选择最合适的处理方式。

对于大多数用户来说，这也是最符合日常使用习惯的模式。

---

Global 模式意味着什么？

Global（全局代理）非常容易理解。

开启之后，几乎所有网络请求都会经过代理节点。

不管访问的是：

• GitHub
• Google
• YouTube
• 微信
• 淘宝
• 银行网站
• Windows 更新

都会走同一个代理出口。

它最大的优点就是：

配置简单。

无需考虑任何规则。

但是，它也存在明显的问题。

例如：

国内视频网站可能绕到海外节点。

软件下载速度可能变慢。

公司内网可能无法访问。

打印机、NAS 等局域网设备也可能受到影响。

因此，Global 更适合临时测试，而不是长期使用。

---

Direct 模式意味着什么？

Direct 与 Global 正好相反。

所有请求都会直接连接。

不会经过任何代理节点。

这种模式通常用于：

• 测试本地网络。
• 检查代理是否导致问题。
• 临时关闭代理。

如果需要访问依赖代理的服务，Direct 模式通常无法满足需求。

因此，它更多是一种排查工具，而不是日常工作模式。

---

为什么推荐 Rule 模式？

Rule 可以理解为：

自动驾驶。

你不需要每次访问网站时都手动切换代理。

Mihomo 会根据规则自动判断：

这次请求应该：

• DIRECT
• PROXY
• REJECT
• 还是交给某个代理组

例如：

访问 github.com
↓
规则判断
↓
PROXY

再例如：

访问 bilibili.com
↓
规则判断
↓
DIRECT

整个过程完全自动完成。

这也是 Clash Verge Rev 最大的优势之一。

---

一条请求到底经历了什么？

假设浏览器访问：

https://github.com

浏览器首先发起网络请求。

随后，这个请求会交给 Mihomo。

接下来，Mihomo 会从配置文件第一条 Rule 开始。

例如：

DOMAIN,github.com,PROXY
DOMAIN-SUFFIX,githubusercontent.com,PROXY
DOMAIN-SUFFIX,google.com,PROXY
GEOSITE,CN,DIRECT
MATCH,PROXY

它不会随机寻找。

也不会寻找"最合适"的一条。

而是严格按照顺序：

第一条

↓

第二条

↓

第三条

↓

第四条

……

直到找到第一条匹配成功的规则。

找到之后：

立即停止。

后面的规则不会继续检查。

很多用户第一次知道这一点时都会觉得意外。

因为大家习惯认为：

"配置里后面的规则会覆盖前面的规则。"

实际上并不是。

Mihomo 永远采用：

First Match Wins（第一条命中即停止）

这也是规则设计最核心的原则。

---

为什么规则顺序这么重要？

举个非常简单的例子。

下面两种写法，看起来几乎一样。

第一种：

DOMAIN,github.com,PROXY
MATCH,DIRECT

访问 GitHub：

第一条命中。

GitHub 使用代理。

没有问题。

但是如果写成：

MATCH,DIRECT
DOMAIN,github.com,PROXY

结果完全不同。

因为：

第一条 MATCH 已经匹配所有请求。

GitHub 根本不会继续检查第二条。

因此：

所有网站都会 DIRECT。

GitHub 规则永远不会执行。

很多新用户就是因为把 MATCH 放到了中间。

结果导致：

后面几十条规则全部失效。

---

MATCH 为什么一定放最后？

MATCH 可以理解为：

"兜底规则。"

它表示：

如果前面所有规则都没有匹配成功。

那么：

就执行这一条。

例如：

MATCH,PROXY

意思就是：

前面都没有命中。

最后全部代理。

如果写成：

MATCH,DIRECT

则表示：

没有命中的全部直连。

因此：

MATCH 永远应该放在最后。

否则：

后面的所有规则都会失去意义。

这是很多配置文件都会遵守的一条基本原则。

---

DIRECT 到底意味着什么？

很多人认为：

DIRECT 就是不经过 Clash。

其实并不是。

请求仍然会经过 Mihomo。

只是：

最终直接连接目标服务器。

例如：

DOMAIN,bilibili.com,DIRECT

当访问 Bilibili 时：

请求依然经过规则匹配。

只是最终不会使用代理。

因此：

DIRECT 并不代表关闭 Clash。

只是告诉 Mihomo：

"这条流量直接放行。"

---

PROXY 又意味着什么？

PROXY 并不是一个固定节点。

它通常代表：

代理组。

例如：

DOMAIN,github.com,PROXY

真正连接时：

可能进入：

🚀 节点选择

也可能进入：

🌍 Proxy

或者：

♻️ 自动选择

因此：

PROXY 更像一个入口。

真正出口是谁。

由代理组决定。

---

为什么很多规则没有生效？

这是 Wiki 中最常见的问题之一。

通常不是 Rule 写错。

而是以下几种情况：

第一：

前面已经命中。

第二：

MATCH 放太早。

第三：

Rule Mode 没开启。

第四：

配置没有重新加载。

第五：

DNS 导致域名没有正确匹配。

第六：

使用了错误的 Rule 类型。

这些问题后面都会逐步介绍。

---

一个好的规则应该是什么样？

很多新用户喜欢：

想到一个网站。

就增加一条 Rule。

久而久之：

配置越来越长。

实际上：

一个好的 Rule 配置应该具有几个特点：

• 顺序清晰。
• 分类明确。
• 尽量避免重复。
• 容易维护。
• 能够快速定位问题。
• 不依赖大量无效规则。

随着后面学习 GEOIP、GEOSITE、RULE-SET 等内容，你会发现：

优秀的规则配置，并不是数量最多。

而是结构最合理。

---

本章小结

这一章最重要的内容只有一句话：

Mihomo 永远按照从上到下的顺序检查规则，命中第一条后立即停止，不会继续匹配后续规则。

理解这一点之后，你会发现很多曾经看起来"莫名其妙"的问题，其实都有明确原因。

后续学习 DOMAIN、GEOIP、RULE-SET 或 Process Rules 时，也能够更容易判断为什么某条规则没有生效。

---

下一步阅读

下一篇将进入最常用、也是最容易混淆的三种规则类型：

➡ DOMAIN-vs-DOMAIN-SUFFIX-vs-DOMAIN-KEYWORD

我们将结合 GitHub、Google、Microsoft、Apple、Steam 等真实案例，详细解释三者的匹配范围、性能差异、适用场景以及常见误区，帮助你学会在实际配置中做出更合理的选择，而不是机械地复制网上的规则。