Clash 订阅链接格式科普:YAML 配置、Base64 节点列表与格式互转

先看订阅返回的内容，不只看链接后缀

订阅链接是客户端获取内容的地址，地址本身不等于配置格式。同一个以 https:// 开头的 URL，可能返回可直接载入的 Clash YAML，也可能返回一整段 Base64 文本；有些地址打开后甚至是登录页面或错误提示。客户端导入失败时，先区分“链接无法访问”和“返回内容不是该导入入口支持的格式”，比反复更换订阅名称有效。

日常遇到的内容主要有三类：完整 YAML 配置、编码后的节点列表，以及 ss:// 等单节点分享链接。它们能提供的信息范围不同，不能仅凭“里面都有节点”就当作同一种配置。尤其是代理组和规则：节点列表描述可连接的代理，完整配置还决定流量如何选择这些代理。

完整 YAML：节点之外还有选路设置

Clash 配置文件常用 .yaml 或 .yml 扩展名。文件中的 proxies 定义节点，proxy-groups 定义手动选择或自动测试等策略组，rules 决定规则模式下的匹配结果。mixed-port 这类字段则设置本地监听端口。YAML 依靠缩进表达层级，列表项前的连字符和字段所在层级都会影响解析。

下面是一个展示结构的最小片段。127.0.0.1:1080 仅代表本机已经存在的 SOCKS5 上游；没有相应服务时，这段示例不会产生可用的外部连接。7890 是此示例配置的本地混合端口，不表示所有客户端都固定使用这个端口。

mixed-port: 7890
mode: rule

proxies:
  - name: 本地演示
    type: socks5
    server: 127.0.0.1
    port: 1080

proxy-groups:
  - name: 手动选择
    type: select
    proxies:
      - 本地演示
      - DIRECT

rules:
  - MATCH,手动选择

在规则模式下，示例里的 MATCH 将未被其他规则匹配的连接交给“手动选择”组；如果组内选中 DIRECT，这些连接就直连。导入真实配置后，要检查客户端显示的策略组和规则数量，而不只是看节点列表是否出现。配置中若使用 proxy-providers，还应确认提供者地址能更新，并确认当前客户端及其内核支持配置中使用的字段。

“YAML”只说明文件语法，不保证内容一定是完整运行配置。例如仅含 proxies: 的 YAML 节点清单，可能适合被某个代理提供者引用，却未必能作为独立配置完成分流。反过来，一份包含 DNS、规则和策略组的完整配置，即使文件名没有 .yaml 后缀，只要客户端按 YAML 读取且内容有效，仍可能正常载入。

Base64 节点列表：先解码，再判断协议

Base64 是文本编码方式，不是代理协议。常见的 Base64 订阅会把多条分享链接按行排列，再把整份文本编码成一段字符。解码后应检查每一行的协议前缀及参数，而不是把编码后的长串直接粘进 config.yaml。把编码文本放到 proxies: 下，也不会自动生成 YAML 节点对象。

这种列表通常能传递服务器、端口、认证参数及节点名称，却不负责提供 Clash 的 proxy-groups、rules 或本地 mixed-port 设置。如果客户端有专门的“节点订阅”入口，它可能自行把列表解析成节点并放进已有配置；如果客户端只有“导入配置”入口，就需要取得适用的 Clash 配置，或在本地转换后补齐策略组与规则。具体入口名称以正在使用的客户端界面为准。

• 开头是 proxies:：优先按 YAML 检查缩进、字段和目标内核兼容性。
• 内容是一整段编码字符：先确认它确实是 Base64 文本，再查看解码后的逐行内容；不要根据 URL 的文件名猜测。
• 解码后出现多行 ss:// 等链接：这是节点列表，不是现成的分流配置。
• 返回 HTML 或登录提示：先处理订阅访问、登录状态或 URL 过期问题；改文件扩展名不能改变返回内容。

还有一种容易混淆的情况：单条分享链接内部也可能编码了部分参数，但它仍只描述一个节点，不能因为出现 Base64 字符就认定它是“Base64 订阅”。判断时先看最外层：拿到的是一份编码后的多行列表，还是一条带协议前缀的分享链接。

单节点链接：可以分享连接，不能代替完整订阅

ss://、vmess://、trojan:// 等前缀表示不同协议的分享链接。一条链接通常对应一个节点。即使客户端能从剪贴板识别并导入它，也不会凭这一条链接推断该节点应该进入哪个策略组、哪些域名应走直连，以及 DNS 应如何设置。手动添加节点后，还需要检查它是否被当前配置的策略组引用。

协议前缀能帮助判断类型，但不能单独保证兼容。原版 Clash 与 Clash Meta（mihomo）的协议和配置字段支持范围不同；例如遇到 vless:// 链接时，不应假定原版 Clash 可以直接使用。即使使用 mihomo，也要核对实际内核版本、协议参数和客户端的导入能力。客户端“不识别分享链接”和“内核不支持转换后的节点字段”是两个不同环节，排查时应分别记录报错。

格式互转：保住字段，再补选路逻辑

转换不是简单地把 .txt 改名为 .yaml。从节点列表转为 Clash 配置时，转换过程至少要把每条链接映射为对应的 proxies 对象；之后还要决定策略组名称、节点归属和 rules 的去向。从完整 YAML 导出为节点列表则是反方向的缩减：代理组、规则、DNS 设置和本地端口通常不会跟着单节点链接一起保存。

转换前核对四组信息

1. 协议字段：核对服务器、端口、认证方式，以及协议需要的传输和 TLS 参数。一个字段缺失，就可能出现“节点已显示但连接失败”。
2. 节点名称：转换后检查名称是否重复。策略组通过名称引用节点时，重名或改名可能让原有选择不再对应预期节点。
3. 分组与规则：确认转换产物是否实际包含 proxy-groups 和 rules。若只生成 proxies，应把它当作节点清单，而不是完整配置。
4. 目标内核：按准备运行的 Clash 或 mihomo 选择输出格式。转换工具能生成字段，不代表当前内核一定能解析或使用这些字段。

需要定期更新时，还要分清“转换一次的文件”和“会随订阅更新的配置”。把某次订阅内容复制进本地 YAML，只保存了当时的节点快照。上游后来调整节点或凭据，这份本地文件不会自动跟随。若使用客户端的 URL 配置更新功能，应检查更新后配置是否仍保留预期的组和规则；若使用代理提供者，则检查提供者的更新结果以及引用它的策略组。

排查转换结果可以分三步：先看 YAML 能否被客户端载入，再看策略组是否列出预期节点，最后在规则模式下用实际连接验证选路。载入成功只说明配置通过了当前客户端的解析，不等于节点参数、上游服务和规则结果都正确。测试前记录当前选中的组成员，测试后再对照连接日志，能避免把选错 DIRECT 当作订阅故障。

导入失败时，按内容、解析、连接逐层检查

第一层：内容有没有取到

在客户端的“配置”页面使用 URL 导入时，先核对地址是否完整、账号是否仍有访问权限，以及更新操作是否给出网络错误。能够在浏览器打开页面，不代表客户端请求会得到相同的配置内容：登录页、重定向后的提示页或过期说明都不是 YAML。诊断时看返回内容的开头，并避免在截图中露出订阅 URL 的令牌。

第二层：内容能否按预期格式解析

若提示 YAML 错误，检查缩进是否混入制表符、冒号后是否缺少空格，以及列表项是否处在正确层级。若导入后只有节点、没有规则与策略组，回到源内容确认它是否本来就是节点列表。若提示未知协议或字段，记录客户端版本与内核名称，再对照订阅的目标格式；不要通过反复重命名文件解决内核兼容问题。

第三层：节点和选路能否工作

看到节点后，先确认它进入了当前策略组，再检查规则模式下的命中结果。系统代理通常接管使用系统代理设置的应用；需要接管其他流量时，部分客户端提供 TUN 模式，但 TUN 权限、DNS 和路由设置属于另一层配置，不能靠转换订阅格式自动补齐。若节点连通而应用流量仍未经过预期策略组，应分别检查客户端模式、系统代理或 TUN 状态，以及实际命中的规则。

选择格式的原则很直接：需要开箱载入分流设置，优先取得与当前内核匹配的完整 YAML；只需要把一批节点加入已有配置，使用客户端支持的节点列表或代理提供者入口；只分享一个连接参数，则使用对应协议的单节点链接。先确认内容类型，再选择导入入口，最后核对组、规则和连接结果，能把格式问题与网络问题分开处理。