Karing Clash配置中节点存在却没有进入策略组？理解提供者与组引用

先把三个层次分开

proxies通常定义当前配置中的静态节点；proxy-providers声明节点集合来源，可以从远程或本地读取；proxy-groups组织节点或其他组，决定流量使用哪个选项。提供者名称、节点名称、策略组名称分别承担不同的引用角色。

Clash生态有不同实现，Mihomo的扩展字段也不意味着其他客户端都会支持。参考配置格式对照确认来源，再核对使用中的Karing版本文档。文件名以.yaml结尾，只能提供格式线索，不能证明所有字段都能被完整保留。

节点集合不会凭空成为组内选项

在Mihomo的常见结构中，组的proxies列表引用具体节点或其他策略组；use引用提供者名称。将提供者名误写进节点引用，或者把名称拼写得不一致，都可能让组无法得到预期成员。导入时发生转换，也可能改变原配置中的组织方式。

proxy-providers:
  demo-source:
    type: http
    url: "https://example.invalid/nodes.yaml"
    path: ./demo-source.yaml
    interval: 3600
proxy-groups:
  - name: demo-select
    type: select
    use:
      - demo-source

这是非真实来源的片段示例，不能直接用于连接；也不代表Karing承诺支持这里的全部字段。先确认提供者成功读取，再检查demo-select是否正确引用demo-source。不要为了试错直接删除已有分组。

选择策略与数据来源分别检查

select表示手动选择的通用组类型；url-test通常根据探测结果选择候选项；提供者中的health-check则负责相应的健康检查。探测设置、实现和支持范围可能不同，探测结果也不能代替实际业务连接验证。

如果节点列表完整但组内为空，应优先检查过滤条件、组引用和解析提示。若节点在组内却不能连接，再检查该节点的连接状态。节点与分组关系指南把这两类问题分开说明，避免把分组错误直接等同于线路失效。

沿着来源 → 分组 → 规则逐层核对

1. 保留一份原始配置，记录来源与更新前的名称。
2. 确认提供者内容是节点集合，而非登录页面或错误文本。
3. 逐字核对提供者名、节点名和策略组名，留意大小写与更新后的改名。
4. 检查组成员列表、use引用与过滤条件，不要把两个字段的角色混用。
5. 确认规则指向仍存在的组，并通过脱敏日志观察实际命中。

rules决定流量目标；rule-providers提供规则集合，与节点提供者的用途不同。组间引用还应避免形成循环。分组正确以后，可继续查看规则优先级与兜底策略。配置能解析、引用能成立、连接能建立，需要分别验收。