查看 2026-05-29 15 分钟 进阶 4 步

Loyalsoldier Clash 规则集配置教程:从 rule-provider 声明到规则命中(2026)

Loyalsoldier 规则集把域名和 IP 按直连、代理、广告拦截分好类,你只需在 Clash/Mihomo 配置里声明 rule-provider 并引用,不用自己写几千条规则。本文给出 2026 年验证过的完整 YAML 配置示例、六组规则集选择决策,以及下载失败和 rule-provider not found 两类错误的排查路径。

·

在 Clash/Mihomo YAML 的 rule-providers 段声明 Loyalsoldier 规则集 URL 和更新间隔,再在 rules 段用 RULE-SET 类型引用即可。proxy.txt 走代理、direct.txt 直连、reject.txt 拦截广告,apple.txt 和 google.txt 单独处理对应服务,cncidr.txt 让国内 IP 直连。不需要自己维护几千条规则。
操作步骤速查
  1. 在 YAML 配置里声明 rule-providers

    打开你的 Clash/Mihomo 配置文件(通常是 YAML 格式),在顶层添加 rule-providers 段。每个 provider 声明四个必填字段:type(固定 http)、behavior(domain 或 ipcidr,按文件内容类型选)、url(规则文件的完整下载地址)、interval(更新间隔,单位秒)。可选 path 字段指定本地缓存路径(如 ./ruleset/proxy.yaml),不填则用默认路径。把你要用的规则集逐个声明,名称用英文简写方便后续引用。

    预期结果:配置文件保存后,客户端日志中应出现类似 'Rule provider proxy updated' 的信息。如果客户端提供「规则」或「Providers」面板,里面应列出你刚声明的规则集名称和最后更新时间。

    初学者最容易漏掉的是 behavior 字段。如果 behavior 不写,Clash 默认按 classical 处理,domain 类型的规则集会解析失败。域名文件(proxy.txt、direct.txt 等)用 domain,IP 段文件(cncidr.txt)用 ipcidr。

  2. 在 rules 段用 RULE-SET 引用规则集

    在 YAML 的 rules 段里,用 RULE-SET 类型引用你在 rule-providers 中声明的名称,后面跟目标策略组。格式为:`- RULE-SET,<provider名称>,<策略组>`。例如 `RULE-SET,proxy,Proxy` 表示匹配 proxy 规则集的流量走 Proxy 策略组。注意 rules 是顺序匹配的,把 reject 和 direct 放前面可以尽早处理广告拦截和直连流量,减少不必要的代理消耗。IP 类规则(telegramcidr、cncidr)记得加 no-resolve 后缀避免 DNS 解析。

    预期结果:重新加载配置后,使用 Clash 客户端的「连接」面板查看流量匹配日志。访问 google.com 应显示命中了 proxy 规则并走代理组,访问 baidu.com 应显示命中了 direct 规则并直连。

    RULE-SET 后面的 provider 名称必须和 rule-providers 段里声明的名称完全一致(区分大小写)。写错一个字母就会报 'rule-provider not found'。建议复制粘贴名称而不是手打。

  3. 设置规则集自动更新间隔

    在 rule-provider 的每个条目里设置 interval 字段(单位秒)。86400 表示每 24 小时更新一次,43200 表示每 12 小时。Loyalsoldier 仓库每 12 小时构建一次,interval 建议设 86400(每天一次),既能拿到较新的规则,也不会频繁请求浪费资源。如果你想手动触发更新,大多数客户端(Clash Verge Rev、Mihomo Party)在面板里提供「更新规则集」按钮。

    预期结果:规则集会按 interval 自动拉取最新版本。可在客户端日志中看到定时触发的更新记录。如果过了 interval 时间没更新,检查客户端是否在运行以及 DNS 能否解析规则文件域名。

    interval 不要设得太短(如 300 秒)。频繁更新除了浪费请求次数外,部分 CDN 可能对高频请求返回 429 限流,导致规则集暂时不可用,反而影响正常使用。

  4. 验证规则是否按预期命中

    打开 Clash 客户端的「连接」或「日志」面板,观察实时流量。访问几个测试域名:google.com(应命中 proxy 规则)、baidu.com(应命中 direct 规则)、doubleclick.net(应命中 reject 规则)。如果命中结果和预期不一致,回到 rules 段检查匹配顺序——是不是 direct 规则放在了 proxy 前面导致本该走代理的域名被直连了。也可以临时调高日志级别到 debug 查看具体是哪条规则命中了流量。

    预期结果:连接面板中,google.com 的 Rule 列显示 proxy,baidu.com 显示 direct。客户端日志中可以看到类似 'matched rule: RULE-SET,proxy' 的记录,确认规则集正常工作。

    如果所有连接都显示 MATCH,说明前面的 RULE-SET 一条都没命中。先检查 rule-providers 是否下载成功(看日志),再确认 rules 段里 RULE-SET 引用的名称和 rule-providers 声明名称一致。

Loyalsoldier 规则集把域名和 IP 按类别分好——直连、代理、广告拦截、Apple 服务、Google 服务等。你只需要在 Clash/Mihomo 的 YAML 配置里声明 rule-providers 然后引用,不用自己维护几千条域名规则。规则集每 12 小时自动构建,客户端按你设定的 interval 定时拉取,始终保持规则更新。

但这不意味着你把 YAML 贴进去就完事了。behavior 选错、provider 名称写错一个字母、rules 顺序排反,规则集都不会按你预期工作。本文从 YAML 配置字段讲起,再到选哪组规则集、更新机制、两种最常见的报错排查,每一步都给出可对照检查的配置代码和排查命令。

手动维护几千条规则和引一个 rule-provider 有什么区别

直接写规则的方式是这样:在 Clash YAML 的 rules 段一条条列出域名。

rules:
  - DOMAIN-SUFFIX,google.com,Proxy
  - DOMAIN-SUFFIX,youtube.com,Proxy
  - DOMAIN-SUFFIX,twitter.com,Proxy
  - DOMAIN-SUFFIX,baidu.com,DIRECT
  - DOMAIN-SUFFIX,taobao.com,DIRECT
  # ... 后面还有上千条

问题很明显:每次有新域名要加、旧域名失效要删,都得手动改 YAML。一个不注意就把直连域名塞进了代理组,或者漏掉了广告域名。

rule-provider 换了一种方式。规则内容不在你的 YAML 里维护,而是从一个远程 URL 下载。Loyalsoldier 仓库的 GitHub Actions 每 12 小时自动从 V2Fly domain-list-community 拉取原始域名分类数据,重新构建规则文件。你的 YAML 只需要声明从哪里下载、下载后叫什么名字、多久更新一次,然后在 rules 段用 RULE-SET 引用这个名字。

rule-providers:
  proxy:
    type: http
    behavior: domain
    url: "https://cdn.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/proxy.txt"
    interval: 86400

rules:
  - RULE-SET,proxy,Proxy

这五行配置等于你自己手写 proxy.txt 里的五千多条 DOMAIN-SUFFIX 规则。规则内容由 Loyalsoldier 维护,你只需要知道引用哪个名字。

六组规则集分别管什么流量

Loyalsoldier/clash-rules 仓库里有十几组规则文件,日常配置不需要全引。下面按使用场景把核心规则集分成六组,先看表格再决定引哪几组。

规则集文件behavior覆盖内容没有它会怎样
代理规则proxy.txtdomainGoogle、YouTube、Twitter、GitHub、Telegram(域名部分)等海外平台域名走代理的域名需要自己一条条写,漏掉的会直连失败
直连规则direct.txtdomain百度、淘宝、B站、微信、高德等国内服务域名国内网站误走代理,慢且浪费流量
广告拦截reject.txtdomain广告投放域名、跟踪器、已知恶意域名客户端层面不过滤广告,依赖浏览器插件
Apple 服务apple.txt + icloud.txtdomainApp Store、iCloud、Apple Music、iMessage 等服务域名Apple 服务可能因走代理而触发风控验证
Google 服务google.txtdomainGoogle 搜索、Gmail、Google Drive、YouTube 等 Google 全系服务域名Google 流量混在 proxy 里也可以工作,但单独分组可以配合策略组做更精细的路由
IP 段规则cncidr.txt + telegramcidr.txtipcidr中国大陆 IP 段、Telegram 服务器 IP 段国内 IP 走代理浪费线路资源;Telegram IP 可能因 DNS 解析不准确而误判

日常使用最多见的组合是:proxy + direct + reject + cncidr。Apple 用户加 apple 和 icloud。Google 规则集不是必须的(proxy.txt 已经包含了 Google 域名),但如果你有一个专门处理 Google 流量的策略组(比如只想让 Google 走某一个特定节点),单独引 google.txt 会更方便。

注意 apple.txt 和 icloud.txt 是互补关系。apple.txt 包含 App Store、Apple Music 等服务域名,icloud.txt 只覆盖 iCloud 同步相关的子域名。如果你不用 iCloud 同步功能(比如只在 iPhone 上用 App Store),不引 icloud.txt 也没问题。

YAML 配置怎么写——完整的 rule-providers 段

下面是一份可直接参考的配置。每行的用途在注释里做了说明。

rule-providers:
  # 广告拦截 —— 建议放 rules 段最前面,尽早拦截
  reject:
    type: http
    behavior: domain
    url: "https://cdn.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/reject.txt"
    path: ./ruleset/reject.yaml
    interval: 86400

  # 局域网 / 私有 IP —— 直连
  private:
    type: http
    behavior: domain
    url: "https://cdn.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/private.txt"
    path: ./ruleset/private.yaml
    interval: 86400

  # Apple 服务 —— 走 Apple 策略组(通常是直连或低延迟节点)
  apple:
    type: http
    behavior: domain
    url: "https://cdn.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/apple.txt"
    path: ./ruleset/apple.yaml
    interval: 86400

  # iCloud 专用 —— 直连,避免同步被代理中断
  icloud:
    type: http
    behavior: domain
    url: "https://cdn.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/icloud.txt"
    path: ./ruleset/icloud.yaml
    interval: 86400

  # Google 服务 —— 走 Google 策略组
  google:
    type: http
    behavior: domain
    url: "https://cdn.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/google.txt"
    path: ./ruleset/google.yaml
    interval: 86400

  # 海外域名 —— 走代理
  proxy:
    type: http
    behavior: domain
    url: "https://cdn.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/proxy.txt"
    path: ./ruleset/proxy.yaml
    interval: 86400

  # 国内域名 —— 直连
  direct:
    type: http
    behavior: domain
    url: "https://cdn.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/direct.txt"
    path: ./ruleset/direct.yaml
    interval: 86400

  # Telegram IP 段 —— 走 Telegram 策略组,no-resolve
  telegramcidr:
    type: http
    behavior: ipcidr
    url: "https://cdn.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/telegramcidr.txt"
    path: ./ruleset/telegramcidr.yaml
    interval: 86400

  # 中国大陆 IP 段 —— 直连
  cncidr:
    type: http
    behavior: ipcidr
    url: "https://cdn.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/cncidr.txt"
    path: ./ruleset/cncidr.yaml
    interval: 86400

rules:
  # 自定义单条规则放最前面 —— 下面的例子让海外 B 站和 Steam 社区走代理
  - DOMAIN-SUFFIX,bilibili.tv,Proxy
  - DOMAIN-SUFFIX,steamcommunity.com,Proxy

  # 然后引用规则集 —— 按拦截 > 直连 > 服务分组 > 代理的顺序
  - RULE-SET,reject,REJECT
  - RULE-SET,private,DIRECT
  - RULE-SET,icloud,DIRECT
  - RULE-SET,apple,Apple
  - RULE-SET,google,Google
  - RULE-SET,proxy,Proxy
  - RULE-SET,direct,DIRECT
  - RULE-SET,telegramcidr,Telegram,no-resolve
  - RULE-SET,cncidr,DIRECT,no-resolve

  # 最后兜底
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

几个容易写错的地方:

  1. type 始终用 http。即使文件托管在 GitHub Release(不是纯 HTTP 服务),Clash/Mihomo 的 rule-provider 也只用 http 类型下载文本文件,不涉及 Clash 代理协议本身。
  2. path 用相对路径时注意工作目录。Clash Verge Rev 和 Mihomo Party 的工作目录通常是 ~/.config/clash-verge-rev/ 或 ~/.config/mihomo/,所以 path: ./ruleset/proxy.yaml 最终写到这些目录下的 ruleset 子目录。如果不写 path,规则集会缓存到默认位置。
  3. IP 相关规则(cncidr、telegramcidr)的 rules 行要加 no-resolve。因为 IP-CIDR 匹配不需要先做 DNS 解析,加上 no-resolve 可以避免纯 IP 规则触发不必要的 DNS 请求。

interval 设多久合适,更新失败会不会影响正常使用

Loyalsoldier 仓库每 12 小时通过 GitHub Actions 重新构建规则集。客户端按 interval(单位秒)拉取远程文件。

interval: 86400(每 24 小时一次)对大多数用户是合适的。一天拉一次,隔一次构建周期,拿到的规则最多比最新版晚 12 小时——域名分类数据不会在几小时内剧烈变化。

几个不建议的做法:

  • 不建议把 interval 设成 300 或 600 秒。除了浪费 CDN 请求外,部分 CDN(尤其是 jsDelivr 的免费层)对高频请求有限流策略,返回 429 后客户端会把规则集标记为下载失败。此时 Clash 会继续使用本地缓存的旧版本——不会因为一次更新失败就让规则集不可用。
  • 不建议设成 0 或完全不更新。规则集会一直停留在首次下载的版本,后续新增或修正的域名不会自动同步。时间长了可能出现本该直连的域名走代理、或新出现的广告域名未被拦截的情况。

更新失败时 Clash/Mihomo 的处理策略是:沿用本地缓存的最后一份有效版本。所以你不会因为 CDN 暂时不可用而导致所有规则失效。如果客户端重启后连缓存也没有(首次下载就失败),那一组 RULE-SET 规则会静默跳过,流量继续往下匹配到 MATCH 兜底规则。

“rule-provider not found” 是哪里写错了

这个报错在 Clash/Mihomo 日志里很常见,原因几乎总是名称不一致。下面按概率从高到低排。

第一:rules 段里的 RULE-SET 名称和 rule-providers 段里声明的名称不完全一致。

rule-providers:
  Proxy:      # 声明时叫 Proxy(大写 P)
    ...

rules:
  - RULE-SET,proxy,Proxy   # 引用时写成了 proxy(小写 p)—— 报错

Clash YAML 的 rule-provider 名称区分大小写。声明时叫 proxy,引用时也得是 proxy。建议所有 provider 名称统一用小写,避免混用大小写出错。

第二:rule-providers 段根本没有声明这个名称。

如果你只声明了 proxy、direct、reject 三个 provider,但 rules 里引用了 RULE-SET,apple,Apple,Clash 找不到 apple 这个 provider 就会报 not found。要么补上 apple 的 provider 声明,要么删掉对应的 RULE-SET 行。

第三:YAML 缩进错误导致 rule-providers 段没有被正确解析。

rule-providers:
proxy:          # 错误:proxy 应该缩进两个空格
    type: http

s 下的子项必须缩进(通常 2 个空格),不缩进的话 YAML 解析器不认为 proxy 是 rule-providers 的子键,日志里看不到报错但 provider 就是不存在。用 VS Code 或支持 YAML 语法高亮的编辑器检查缩进比肉眼找更快。

规则集文件下载失败怎么排查

如果日志里出现 rule provider download failed、timeout 或 404,按以下顺序排查。

浏览器先打开 URL 试试。 把 rule-provider 的 url 值完整复制到浏览器地址栏,看能不能返回文本内容。如果浏览器也打不开,问题在 URL 本身或 CDN;如果浏览器能打开但客户端不能,问题在客户端的 DNS 或代理设置。

换 CDN 地址。 Loyalsoldier 规则集从 GitHub Release 分支提供,原始 URL 是 GitHub Raw:

https://raw.githubusercontent.com/Loyalsoldier/clash-rules/release/proxy.txt

GitHub Raw 在国内某些网络下可能被 DNS 干扰或连接超时。三条备用 CDN:

CDNURL 模板国内可用性
jsDelivrhttps://cdn.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/proxy.txt有国内节点,稳定性中等
Fastly (jsdelivr)https://fastly.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/proxy.txt比 jsDelivr 主域名在国内稍快
ghproxy.nethttps://ghproxy.net/https://raw.githubusercontent.com/Loyalsoldier/clash-rules/release/proxy.txt反代,需要 GitHub Raw 源可达

不要同时混用多个 CDN 来源。选一个能稳定下载的,所有 rule-provider 的 url 统一用同一个 CDN。

检查客户端的 DNS 设置。 如果客户端自身的 DNS 没走代理,解析 cdn.jsdelivr.net 或 raw.githubusercontent.com 可能被干扰。在 Clash/Mihomo 配置里确认 DNS 段至少有一条走系统或公共 DNS 的规则,例如:

dns:
  enable: true
  nameserver:
    - 223.5.5.5   # 阿里 DNS
    - 119.29.29.29 # 腾讯 DNS

如果客户端 DNS 配置了 fake-ip 模式但 fallback 也没配好,规则文件下载可能在域名解析这一步就失败了。可以临时切到 redir-host 模式测试下载是否恢复正常。

如果换了 CDN、排查了 DNS 还是频繁超时,根源通常不在规则集本身,而是当前代理出站的稳定性不够。规则集下载走的是 HTTP 请求,和你日常访问海外网站走的是同一条通道。一条多格式测试订阅源可以同时承载规则更新和日常代理流量,不需要把规则下载和日常使用分开处理。

相关阅读

常见问题

Loyalsoldier 规则集和机场自带的规则有什么区别?
机场自带规则通常偏保守——只保证海外网站能访问,国内流量可能误走代理、广告不过滤。Loyalsoldier 规则按域名类别精细分类(proxy/direct/reject/apple/google 等),更新频率更高(每 12 小时),而且你可以直接在 YAML 里覆盖单条规则。保留机场的 proxies 和 proxy-groups,只替换 rule-providers 和 rules 两段,节点用机场的、规则用自己的。
多个规则集同时引用,匹配顺序怎么定?
Clash/Mihomo 按 rules 段从上到下匹配,命中即停。常见顺序是:reject 最先(拦截广告)→ direct 和国内 IP 其次(直连省流量)→ apple/google 等服务规则 → proxy 最后(兜底走代理)→ MATCH 最终兜底。如果你有自定义单条规则(DOMAIN/DOMAIN-SUFFIX 等),放在 RULE-SET 前面,单条规则优先于规则集。
规则集更新后会不会覆盖我的自定义规则?
不会。RULE-SET 引用的是远程规则集内容,但你 YAML 里直接用 DOMAIN / DOMAIN-SUFFIX / IP-CIDR 写的单条规则在 rules 段的上方,不依赖远程文件。自定义规则放前面(先匹配),RULE-SET 放后面(当兜底),两者互不干扰。规则集更新只影响 RULE-SET 行的匹配结果。
behavior: domain 和 behavior: ipcidr 用错了会怎样?
domain 行为匹配域名,ipcidr 行为匹配 IP 段。如果用 behavior: domain 引用 cncidr.txt(IP 段文件),Clash 解析时会报错或跳过该规则集,导致规则不生效。反过来用 behavior: ipcidr 引用 proxy.txt(域名列表)同理。选 behavior 的标准是看规则文件的内容格式:域名列表用 domain,IP 段用 ipcidr,混合内容(如 classical)用 classical。
国内访问 GitHub Raw 下载规则集太慢或超时怎么办?
把 rule-provider 的 url 从 raw.githubusercontent.com 换成 CDN 地址。jsDelivr 在国内有节点:`https://cdn.jsdelivr.net/gh/Loyalsoldier/clash-rules@release/proxy.txt`。如果 jsDelivr 也不稳定,用 ghproxy.net 反代:`https://ghproxy.net/https://raw.githubusercontent.com/Loyalsoldier/clash-rules/release/proxy.txt`。不要同时混用多个 CDN,选一个能稳定下载的即可。

来源与时间

本文最后查看时间:2026-05-29。操作路径会随客户端版本变化,遇到按钮名称不一致时,优先按同义菜单和官方文档查看。

看更多教程:教程库 · 看客户端:客户端目录 · 看下载入口:下载中心