一、rule-providers 解决什么问题
不少教程会让你把成百上千行分流规则直接写进主配置，时间一长YAML 臃肿、合并订阅时也容易被覆盖。rule-providers 的作用，是把「某一类规则片段」当成独立资源：既可以指向远程 URL由内核按周期抓取，也可以指向本地文件离线维护。对 Clash Meta / Mihomo 用户来说，这是把规则生态「模块化」的标准做法。
它和订阅节点不是一回事：proxy-providers 管的是(outbound)节点列表；rule-providers 管的是「这一条连接该不该走哪个策略组」的条件集合。若你只调整了订阅却仍然觉得分流怪异，多半要在规则集是否加载成功、RULE-SET 顺序是否合理上找原因，而不是反复换节点。本站讨论订阅空亡的文章会从 Provider 缓存角度切入；本文专注规则集字段与更新策略，与讨论 GeoIP 命中逻辑的专文互补——那边讲的是 GeoIP 行怎么写，这里讲的是「整包第三方列表」如何接入。
| 能力 | 说明 |
|---|---|
| 远程 HTTP(S) | 填写 url，内核下载文本后在本地 path 落盘缓存；可用 interval 控制自动更新节奏。 |
| 本地 file | 不走网络，适合自建清单或内网分发；仍建议保留清晰 path，便于多端同步与备份。 |
| rules 侧引用 | 使用 RULE-SET、或配合行为的 GEOSITE/GEOIP 类 Provider（名称与内核文档一致），把片段接入分流链表。 |
二、在 YAML 顶层声明 rule-providers
在完整的配置树里，rule-providers 与 proxies、proxy-groups、rules 同级，占据顶层键。每一个子键（例如 google、cn_site）就是你之后在 RULE-SET 里要写的那段逻辑名称：务必使用英文字母、数字与下划线等稳妥命名，避免空格与 YAML 特殊符号。
最常见的远程条目包含：type: http、behavior（决定解析语义）、url、path、interval。若你手头已有厂商发行的规则文本文件，可改用 type: file 并指向本地路径。合并多条订阅时，注意键名冲突：后载入的同名将覆盖前者。
# Example only — replace URLs, paths, and policy group names with yours.
rule-providers:
example-domain:
type: http
behavior: domain
url: "https://example.com/rules/domain.txt"
path: ./ruleset/example-domain.yaml
interval: 86400
rules:
- RULE-SET,example-domain,DIRECT
- MATCH,PROXY三、path 与 interval：缓存路径与自动更新
path：缓存写到哪里
path 通常表示「下载后的规则文本落在磁盘上的相对路径」，基准目录依客户端实现而定：多数桌面图形客户端会以配置目录或应用数据目录为根；如果你是裸内核配合 systemd 或 LaunchAgent，往往相对于配置文件的目录解析。路径写法务必与实际操作系统分隔符习惯一致，并确认进程对该目录有写权限——否则会表现为规则集永远空白或反复报错。
interval：自动更新间隔（秒）
interval 只对需要联网拉取的条目有意义：单位为秒。例如一天更新一次可写 86400。过短的自动更新会增加请求次数，既消耗流量，也可能触发某些托管商的限速；过长则规则陈旧，出现「别人的分流脚本已修但你这边仍旧」的体验落差。若你暂时不希望定时后台拉取，可根据内核与客户端支持情况改为更长间隔或结合手动更新按钮触发。
首次加载与失败时的行为
第一次启动或清空缓存后，内核需要先完成下载才会展开RULE-SET。若 DNS、TLS 或区域网络阻断导致下载失败，连接日志里常有明确的 fetch 报错。此时保留上一份path缓存尤为重要——多数客户端会继续使用旧文件兜底，直到下一次成功刷新。
四、在 rules 里用 RULE-SET 引用
仅有 rule-providers 声明不会让流量动起来——必须在 rules: 数组里插入对应的RULE-SET 行，格式一般为：RULE-SET,<provider_name>,<policy>，其中 <policy> 多为某个 proxy-groups 名称或 DIRECT/REJECT。Clash Meta 仍然遵循自上而下的匹配顺序：写在前的规则优先命中。
实操时常见的两条线与GeoIP类教程相呼应：一条是先放过局域网与明确直连域名，再挂上第三方 RULE-SET（例如广告拦截或流媒体分流），最后用 MATCH 兜底；另一条是让特定的 geosite 片段落在某一策略组前，避免被过宽的域名后缀规则抢走。若你发现境外站异常但RULE-SET明明存在，先用日志确认是不是更早的一条规则已经匹配离开。
需要核对中国大陆直连或GeoIP兜底写法时，可对照本站 GeoIP 与 DIRECT 分流专文；它与本文的差别在于：那边拆解 GEOIP 行与本站 DNS/TUN 交叉影响，本文拆解远程规则集的接入与更新字段。
五、behavior 与格式：domain / classical / ip
behavior 告诉内核如何解释远程文件：domain 多用于域名列表；ip 多用于 IP/CIDR 段；classical 则兼容更接近手写规则的条目集合（具体能力与内核版本相关）。若 behavior 与文件真实内容不一致，轻则匹配率极低，重则解析报错。
部分托管仓库同时提供 .yaml、.text、.mrs 等不同封装；是否可直接引用取决于Mihomo版本与字段组合（例如是否启用特定解码）。当你不确定时，优先遵循规则发行方在 README 里给出的示例配置，再把示例里的名称映射到自己的策略组。
如果你在钻研YAML结构与代理链或多跳出口，可延伸阅读 relay 代理链排查；那条线聚焦出站拓扑，与本文入站匹配数据源是正交话题。
六、运维习惯：失败回退与客户端差异
在生产环境里，建议把自动更新安排在设备长时间在线、网络稳定的时段；笔记本电脑频繁休眠可能让定时更新落空，这时手动点一次「更新外部资源」往往最直接。Android端还要额外留意省电策略是否冻结后台网络——这与订阅拉取失败同源，可参考本站 安卓 Meta 订阅与规则排查里关于后台限制的段落。
当订阅合并逻辑把你的手写段顶掉时，会出现「界面里看得到 provider，实际生效却是旧文件」的错觉。解决办法是理清本地覆写与远端订阅的优先级，或在图形界面锁定片段。若你发现规则集时而生效时而失效，也可以在日志里搜索下载关键词，确认是不是间歇性 TLS或DNS 解析失败；DNS 栈本身可参考 nameserver 与 fallback 分步设置。
整体而言，一份健康的 Meta 配置要做到三件事：节点列表可用、DNS不乱、规则数据源可更新且顺序合理。rule-providers承担的就是第三件事里的「外部数据源」角色。
七、常见问题
rule-providers 里的 path 是相对谁的？
一般为配置文件所在目录或客户端约定的配置目录下的相对路径；不同图形客户端会把缓存统一到应用数据目录。路径写错会导致无法写入缓存或反复下载失败，应以你所用Clash Meta发行版的文档为准。
interval 设为多少合适？
interval 单位为秒。常用远程规则集一天更新一次可设为 86400；更新过频可能增加流量与被源站限制的风险，过稀则规则滞后。可按规则维护频率与网络条件折中。
RULE-SET 写了但不生效怎么办？
先确认 rule-providers 名称与 RULE-SET 第一个字段完全一致；再检查 rules 顺序是否被更靠前的 MATCH 或其它规则截断；最后确认该规则集已成功下载或本地文件可读，behavior 与规则内容类型匹配。
rule-providers 和 proxy-providers 有什么区别？
proxy-providers 管理远程节点列表；rule-providers 管理远程分流规则片段。二者都在配置顶层声明，但引用的语法与下游字段不同，不可混用。订阅空亡更多指向前者缓存问题，可在 订阅节点与 Provider 缓存一文对照。
八、小结
给 Clash Meta / Mihomo 加远程规则集时，记住三条主线：在顶层写好 rule-providers（type、behavior、url/path、interval），让内核能把文件稳定落到本地；在 rules 里用 RULE-SET 按正确顺序接上策略组；最后用日志验证下载与命中是否符合预期，并与 DNS、订阅合并策略统筹考虑。
市面上不少「一键脚本」要么把规则写死在巨大单文件里难以审计，要么更新链路不透明，出问题只能整体回滚。Clash系把分流规则拆成可缓存、可定时刷新的rule-providers后，你能逐项替换列表、比对差异，也不会因为换一个订阅就把手写直连段冲掉——这正是 Meta 内核在规则生态上的实用优势。
若你希望使用维护活跃、跨平台一致的客户端来承载这套配置，可从本站获取安装包后导入现有 YAML，按本文检查path与自动更新是否在你的系统上落地正常。