Clash proxy-providers 与 rule-providers 怎么选？附 YAML 和排错清单
简答：proxy-providers 保存代理节点，由 proxy-groups 的 use 引用；rule-providers 保存域名、IP 或路由规则，由 rules 的 RULE-SET 引用。
定义：在支持这些字段的 Clash 兼容内核中，proxy-providers 是外部代理节点集合，rule-providers 是外部路由规则集合。
先看结论：两类 Provider 到底怎么区分
如果你正在配置 Clash 或兼容内核，先记住一句话：proxy-providers 是节点仓库，rule-providers 是规则仓库。前者解决“节点从哪里来”，后者解决“哪些流量匹配后走什么策略”。
本文示例按当前官方 mihomo 配置文档组织，主要用于理解 Clash 兼容配置的字段关系。不同客户端可能内置不同内核，字段支持、图形化入口、缓存位置和订阅解析能力需以具体客户端文档为准。本文更新于 2026 年 11 月 4 日。
| 比较维度 | proxy-providers | rule-providers |
|---|---|---|
| 保存什么 | 代理节点、服务器、端口和协议参数 | 域名、IP 网段或路由规则 |
| 主要被谁引用 | proxy-groups | rules |
| 引用字段 | use | RULE-SET |
| 常见来源类型 | http、file、inline | http、file、inline |
| 重点检查内容 | 节点对象是否能被解析 | behavior 是否匹配规则内容，format 是否正确 |
| 能否直接互换 | 不能直接当规则集使用 | 不能直接当节点订阅使用 |
官方文档将两者都定义为 provider，但它们承载的数据不同：代理提供器读取代理配置集合，规则提供器读取规则集合。mihomo proxy-providers 文档、mihomo rule-providers 文档
proxy-providers：节点集合如何进入策略组
proxy-providers 的完整链路是：远程订阅或本地节点文件 → proxy-providers → proxy-groups → rules。仅定义 provider 不会自动生成一个可选择的策略组，策略组还需要通过 use 引用 provider 名称。
下面是一份用于理解字段关系的最小 YAML。它使用 inline 写入一个示例节点，因此可以直接检查结构；示例节点的服务器和认证信息是占位内容，能否连接需替换为真实节点并以实际服务为准。
mode: rule
log-level: info
proxy-providers:
demo-nodes:
type: inline
payload:
- name: "Demo-Node"
type: ss
server: example.com
port: 443
cipher: chacha20-ietf-poly1305
password: "replace-me"
proxy-groups:
- name: Proxy
type: select
use:
- demo-nodes
rules:
- "MATCH,Proxy"
这段配置中，demo-nodes 是提供器名称，必须与策略组的 use 项完全一致；节点加载后会进入名为 Proxy 的策略组。官方文档还支持 http、file 和 inline 三种 provider 类型，并说明 url 用于远程来源、path 用于本地缓存或文件路径、interval 用于更新间隔。查看 proxy-providers 字段说明
如果使用远程订阅，应将 type 改为 http 并补充 url；如果使用本地节点文件，应改为 file 并核对 path。代理文件通常应能解析出节点名称、节点类型、服务器和端口等字段。查看代理提供器内容格式
rule-providers：规则集合如何影响路由
rule-providers 的完整链路是：规则文件 → rule-providers → rules 中的 RULE-SET → 策略名称。它本身只定义规则来源，真正决定匹配后走向的，是 rules 中的 RULE-SET,提供器名称,策略名称。
下面是一份使用内联域名规则的最小 YAML。它展示了规则提供器、规则引用和最终策略之间的关系：
mode: rule
log-level: info
proxy-providers:
demo-nodes:
type: inline
payload:
- name: "Demo-Node"
type: ss
server: example.com
port: 443
cipher: chacha20-ietf-poly1305
password: "replace-me"
proxy-groups:
- name: Proxy
type: select
use:
- demo-nodes
rule-providers:
work-sites:
type: inline
behavior: domain
format: yaml
payload:
- "example.com"
- ".example.org"
rules:
- "RULE-SET,work-sites,Proxy"
- "MATCH,DIRECT"
这里的 work-sites 必须同时出现在 rule-providers 的名称和 RULE-SET 引用中。匹配到规则集合中的域名后，流量会交给名为 Proxy 的策略组；没有匹配到的流量继续执行下一条 MATCH,DIRECT。
behavior 要根据文件内容选择：domain 用于域名或域名通配内容，ipcidr 用于 IP 网段，classical 用于包含完整规则类型和参数的列表。format 用于说明内容格式，官方文档列出的选项包括 yaml、text 和 mrs；其中具体支持仍需核对目标内核。查看 rule-providers 字段说明、查看 domain、ipcidr、classical 内容示例
节点订阅、节点文件和规则文件怎么判断
不要只看链接名称、文件扩展名或是否使用 type: http。判断依据应是返回内容：它最终是要出现在节点列表中，还是要参与规则匹配。
| 拿到的内容 | 应考虑的位置 | 核对方法 |
|---|---|---|
| 包含节点名称、协议、服务器和端口 | proxy-providers | 确认能解析为代理节点集合 |
| 完整代理订阅或节点 URI 列表 | proxy-providers | 确认目标内核支持该订阅载荷 |
| 一行一个域名或域名通配符 | rule-providers，通常为 domain | 确认内容符合域名规则格式 |
| 一行一个 IPv4 或 IPv6 网段 | rule-providers，通常为 ipcidr | 确认每行都是合法 CIDR |
| 带有 DOMAIN、IP-CIDR 等规则类型 | rule-providers，通常为 classical | 确认每条规则的动作由 RULE-SET 统一指定 |
官方代理提供器内容示例包括带 proxies: 的 YAML 节点集合，也说明部分 URI 或 base64 内容有不同载荷写法；因此，完整订阅不能因为“也是一个 URL”就直接放入 rule-providers。查看代理提供器支持的内容形式
规则提供器中的 classical 内容可以包含完整路由规则，但官方内容说明不包括再次嵌套的 rule-set 或 sub-rule；如果规则文件只是域名列表，不应误填为 classical。查看规则内容限制
加载失败时，按最小闭环排查
- 先验证 YAML 层级。
proxy-providers、rule-providers、proxy-groups和rules都应位于配置文件顶层，缩进错误会导致整个配置无法解析。 - 再核对引用名称。策略组的
use必须引用 proxy-provider 名称；RULE-SET的第二段必须引用 rule-provider 名称。名称、大小写、连字符和下划线都要保持一致。 - 检查来源类型。
http通常需要url；file需要检查path是否存在；inline需要检查payload是否写在正确层级。 - 检查内容与用途。proxy-provider 应解析出代理节点；rule-provider 应解析出符合
behavior的规则内容。两者内容放反时，即使 URL 可以访问，也可能加载失败或得到空集合。 - 检查规则格式。规则列表应逐项写成字符串，例如
rules: - "DOMAIN-SUFFIX,example.org,Proxy" - "MATCH,DIRECT"，不要把逗号错误拆成多个 YAML 数组元素。 - 最后再检查策略组。如果 proxy-provider 已加载但策略组为空，检查
use名称和filter；如果规则已加载但没有效果，检查RULE-SET名称、规则顺序以及最终策略名称是否存在。
建议先只保留一个 provider、一个策略组和一条规则，确认最小配置能够加载，再逐步加入远程更新、健康检查、筛选器和多个规则集。这样能区分字段错误、内容格式错误和远程来源异常。
如果你的客户端不是直接运行 mihomo，而是使用其他 Clash 兼容内核，以上 YAML 只能作为字段关系示例；behavior、format、inline 以及订阅解析能力是否可用，必须以该客户端和内核的实际文档为准。官方规则路由文档明确说明，RULE-SET 需要对应的 rule-provider 配置。查看 RULE-SET 路由规则说明
常见问题
Clash 配置文件中 proxy-providers 和 rule-providers 有什么区别？
proxy-providers 管理节点集合，供策略组通过 use 引用；rule-providers 管理规则集合，供 rules 通过 RULE-SET 引用。它们虽然都可以使用 http、file 或 inline，但载荷结构不同，不能直接互换。
完整订阅链接应该放 proxy-providers 还是 rule-providers？
如果返回的是代理节点、协议参数和服务器信息，应优先检查是否适合作为 proxy-provider；如果返回的是域名、IP 网段或路由规则，才考虑 rule-provider。最终还要核对目标客户端的订阅解析能力，不能仅凭链接后缀判断。
rule-providers 的 behavior 怎么选？
域名或域名通配列表通常对应 domain，IP 网段列表通常对应 ipcidr，带有完整规则类型的列表通常对应 classical。不同客户端和内核的兼容性可能不同，使用前应查看目标内核文档。
proxy-providers 加载成功但策略组为空怎么办？
先检查策略组是否通过 use 引用了正确名称，再检查筛选条件是否过滤掉所有节点，最后确认远程或本地内容确实解析出了代理节点。提供器加载成功不等于策略组一定已经正确引用。
proxy-providers 和 rule-providers 可以使用同一个 URL 吗？
只有当该地址根据请求方式或参数返回符合对应格式的不同内容时才可能成立。普通节点订阅不能直接当规则集，普通规则文件也不能直接当节点集合，仍需按实际返回内容核验。
常见问题
Clash 配置文件中 proxy-providers 和 rule-providers 有什么区别？
proxy-providers 管节点集合，由 proxy-groups 的 use 引用；rule-providers 管规则集合，由 rules 的 RULE-SET 引用。两者数据结构不同，不能直接互换。
完整订阅链接应该放 proxy-providers 还是 rule-providers？
返回节点列表、协议和服务器信息时，先考虑 proxy-providers；返回域名、IP 网段或路由规则时，才考虑 rule-providers，最终以实际内容和客户端支持情况为准。
rule-providers 的 behavior 怎么选？
域名列表通常选 domain，IP 网段列表通常选 ipcidr，带完整规则类型的列表通常选 classical；具体兼容性需按目标内核文档核对。
proxy-providers 加载成功但策略组为空怎么办？
先检查 proxy-groups 是否用 use 引用了正确的 provider 名称，再检查 filter 是否筛掉全部节点，最后确认来源文件确实解析出了代理节点。