🧱 规则集的设计原则
一个维护良好的规则集应遵循以下四个核心原则:
- 单一职责: 每个规则文件只负责一类流量(如广告拦截、国内直连、国外代理),避免一个文件包含所有规则。
- 可组合: 通过
RULE-SET和proxy-providers组合不同来源的规则,而非复制粘贴。 - 可版本化: 所有规则文件纳入 Git 管理,每次变更都有记录,方便回滚和协作。
- 可测试: 有办法验证规则是否按预期工作,而不是“凭感觉”判断。
这些原则源自软件工程,虽然 Clash 配置只是 YAML,但同样适用。当你把规则集当成代码库来维护时,规模增长也不再可怕。
📦 模块化基石:rule-providers
Clash 的 rule-providers 允许你从外部 URL 或本地文件加载规则集,并在主配置中使用 RULE-SET 引用。这是实现规则模块化的核心机制。
基本用法
rule-providers:
reject:
type: http
behavior: domain
url: "https://cdn.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/reject.txt"
path: ./rulesets/reject.yaml
interval: 86400
rules:
- RULE-SET,reject,REJECT
- RULE-SET,proxy,PROXY
- MATCH,DIRECT这样,广告拦截规则独立于主配置,更新间隔可自定义。如果你的规则源使用 domain 行为,则每行一个域名;若为 ipcidr 行为,则每行一个 IP 段。
如果你需要混合多个来源,可以定义多个 rule-providers,然后在规则部分自由组合。这类似于软件开发中的“依赖管理”。
🧹 去重与精简:从千行到百行
手动维护规则时,很容易出现重复条目。例如,多个规则集可能都包含 google.com,或者同一域名在不同规则中反复出现。去重不仅减少文件大小,还能提升匹配效率。
使用脚本去重
以下 Python 脚本可帮助你合并多个规则文件并去除重复域名:
import yaml
def merge_and_dedup(*files):
domains = set()
for file in files:
with open(file) as f:
for line in f:
line = line.strip()
if line and not line.startswith('#'):
domains.add(line)
return sorted(domains)
# 使用示例
merged = merge_and_dedup('reject.txt', 'proxy.txt')
with open('merged.yaml', 'w') as f:
f.write('\n'.join(merged))将脚本集成到 CI 流程中,即可在每次更新时自动生成精简后的规则文件。
利用 GEOIP 减少 IP 规则
与其列出数百条 IP-CIDR 规则,不如使用 GEOIP,CN,DIRECT。它通过内置的 GeoLite2 数据库匹配国内 IP,既精准又高效。对于极少数的特殊情况,再用精确 IP 规则覆盖。
更多规则优化技巧可参阅 《如何编写高效的自定义代理规则》。
🤖 自动化更新:GitHub Actions 实践
规则需要定期更新才能跟上 CDN 调整和域名新增。手动下载然后提交不仅繁琐,还容易遗忘。利用 GitHub Actions 可以实现完全自动化:
示例 Workflow
name: Update Rule Sets
on:
schedule:
- cron: '0 4 * * *' # 每天 UTC 4:00 运行
workflow_dispatch:
jobs:
update:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Download rules
run: |
curl -o rulesets/reject.txt https://cdn.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/reject.txt
curl -o rulesets/proxy.txt https://cdn.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/proxy.txt
- name: Commit and push if changed
run: |
git config user.name "bot"
git config user.email "bot@example.com"
git add rulesets/
git diff --staged --quiet || git commit -m "Auto-update rule sets"
git push将此文件保存在 .github/workflows/update-rules.yml,仓库就会每天自动拉取最新规则并提交。你的 Clash 客户端只要配置 rule-providers 指向该仓库的 raw 文件,就能获得持续更新。
结合 《大型配置文件管理指南》 中的模块化思路,你可以打造一个完全自动化的配置体系。
✅ 测试与验证:确保规则正确性
如何知道新规则是否生效?以下几种方法可以帮你验证:
- Clash 日志 debug 模式: 设置
log-level: debug,查看每个请求匹配的规则。 - curl 搭配代理: 使用
curl -x http://127.0.0.1:7890 https://www.example.com -v观察连接过程和返回头。 - 在线域名检查: 编写脚本批量解析规则文件中的域名,确认它们仍可解析。
- 回归测试: 维护一份“应该被代理的域名列表”和“应该直连的域名列表”,每次更新规则后自动测试这些域名的路由是否正确。
对于大型规则集,回归测试尤其重要。你可以用 Python 调用 Clash API 的 GET /rules 来模拟匹配,验证关键域名。如果配合 TUN 模式 使用,还需确认 DNS 劫持正确,避免泄漏。
📄 开箱即用的规则集模板
以下是一套推荐的最小化规则集结构,可以直接用于你的项目:
rule-providers:
reject:
type: http
behavior: domain
url: "https://raw.githubusercontent.com/yourname/rules/main/reject.txt"
interval: 86400
proxy:
type: http
behavior: domain
url: "https://raw.githubusercontent.com/yourname/rules/main/proxy.txt"
interval: 86400
rules:
- RULE-SET,reject,REJECT
- DOMAIN-SUFFIX,cn,DIRECT
- DOMAIN-KEYWORD,alipay,DIRECT
- GEOIP,CN,DIRECT
- RULE-SET,proxy,PROXY
- MATCH,PROXY你可以在此基础上根据自己的需求添加自定义规则。注意 RULE-SET 的顺序:先 REJECT,再 DIRECT,最后 PROXY,符合性能最优原则。更多策略组与规则的组合案例可参考 《策略组完全解析》。
🔧 规则未生效?常见排障
rule-provider 相关错误。
proxy-groups 中引用的组名与 RULE-SET 后的组名完全一致。
interval 控制,可手动触发更新(API 调用 PUT /providers/proxies/ 或在客户端界面操作)。如果急需生效,可重启客户端或发送 SIGHUP 信号。
如果订阅链接也出现问题,可结合 《订阅失败终极排查手册》 一并排查。
🏁 总结:规则即代码
构建可维护的规则集不仅是一次性的配置工作,更是一种长期的工程实践。当你将规则视为代码,用 Git 管理、用 CI 更新、用测试验证时,代理客户端的体验将变得高度可控和可信赖。
本文涵盖的原则和工具链与 大型配置文件管理、自定义规则编写 等文章紧密互补。建议按需阅读,逐步将你的 Clash 配置打造成一套精致的自动化流水线。