2026-05-08 订阅管理 预计阅读 7 分钟

Clash 订阅格式详解:YAML 配置、Base64 链接与格式互转方法

Clash 生态里流传的订阅链接看起来五花八门,本质上只分三类:完整 YAML 配置、Base64 编码的节点列表、以及各协议自带的分享链接聚合。搞清楚它们的结构差异,才能在换客户端或换订阅转换工具时不丢字段。

订阅格式为什么会不一样

Clash 最早只认一种格式:一份完整的 YAML 配置文件,里面同时包含节点信息(proxies)、策略组(proxy-groups)和分流规则(rules)。这份文件既是节点清单,也是行为说明书,客户端下载后可以直接加载运行。

但节点提供方并不总想维护一份完整规则集——大部分订阅服务商更倾向于只发布节点本身,把规则组织的工作留给用户或客户端自带的预设。这就衍生出了另外两种更轻量的格式:Base64 编码的节点列表和通用分享链接聚合。三种格式服务的场景不同,没有绝对的"更好",但混用时容易出现字段丢失或客户端读不懂的问题。

完整 YAML 配置:字段结构与适用场景

YAML 格式的订阅本质上就是一份可以直接跑起来的 config.yaml,mihomo(Clash Meta 内核)在原有字段基础上扩展了不少新语法,但顶层结构基本保持一致:

config.yaml(节选)
mixed-port: 7890
mode: rule
log-level: info
dns:
  enable: true
  nameserver:
    - 223.5.5.5
proxies:
  - name: "hk-01"
    type: ss
    server: example.com
    port: 443
    cipher: aes-256-gcm
    password: "your-password"
proxy-groups:
  - name: "自动选择"
    type: url-test
    proxies:
      - hk-01
    url: "http://www.gstatic.com/generate_204"
    interval: 300
rules:
  - DOMAIN-SUFFIX,google.com,自动选择
  - GEOIP,CN,DIRECT
  - MATCH,自动选择

这种格式的优势是"开箱即用":规则、策略组、DNS 策略全部由订阅方维护,用户导入后不需要额外配置。缺点也很明显——一旦客户端要合并多个订阅,或者想在原有规则基础上加自定义分流,处理起来会比纯节点列表麻烦一些,因为要做字段级的合并而不是简单拼接。

另外要注意,mihomo 内核新增的字段(比如 smart 策略组类型、sniffer 域名嗅探配置)在原版 Clash 内核里会被直接忽略或报错,所以下载 YAML 订阅前最好确认客户端用的是哪种内核。

Base64 节点列表与通用分享链接的区别

如果订阅链接返回的内容不是可读的 YAML,而是一长串看不出规律的字符,大概率是 Base64 编码的节点列表。这类订阅每一行对应一个节点,格式通常是 协议://编码后的连接参数,常见协议前缀有 ss://、vmess://、trojan://、ssr:// 等,整份订阅再对这些行统一做一次 Base64 编码。

解码后的节点列表(节选)
ss://[email protected]:443#hk-01
vmess://eyJ2IjoiMiIsInBzIjoic2ctMDIi...
trojan://[email protected]:443?sni=example.net#sg-02

这种格式只描述"节点是什么",不包含任何分流规则或策略组信息。客户端订阅解析器负责把每一行还原成节点对象,再套用客户端本地或订阅转换服务提供的规则模板。它的好处是通用性强,几乎所有支持代理协议的客户端(不限于 Clash)都能解析;缺点是脱离了转换工具,单纯把这类链接丢进不支持自动转换的 Clash 客户端,大概率什么都加载不出来,因为 Clash 原生只认 YAML。

所谓"通用分享链接聚合",其实就是上面这种 Base64 节点列表的另一种叫法,常见于机场服务商的"订阅链接"页面,和纯 YAML 订阅在 URL 层面往往看不出区别,只能靠内容判断。

客户端之间迁移:互转方法与工具选择

换客户端或者换设备时,最常见的诉求是把 Base64 节点列表转换成一份完整可用的 YAML 配置,或者反过来提取 YAML 里的节点信息用在别的软件上。常见思路有三种:

  1. 客户端自带转换:多数 Clash 客户端(包括支持 mihomo 内核的版本)在添加订阅时会自动识别 Base64 节点列表,内部转换成 YAML 结构并套用默认规则模板,用户不需要手动处理,这是最省心的方式。
  2. 订阅转换服务:把原始订阅链接和一份规则模板一起提交给转换服务,由服务端拉取节点、套用规则、拼装出完整 YAML,再返回一个新的订阅地址。这种方式适合需要自定义策略组、想合并多个订阅源的场景。
  3. 本地脚本转换:对节点数量不多、想完全自主控制规则的用户,也可以手动解码 Base64 内容,把还原出的节点参数逐个填进 YAML 的 proxies 字段,规则和策略组自己编写。这种方式最繁琐,但不依赖任何第三方服务。

选择哪种方式,主要看订阅来源是否稳定、规则是否需要频繁调整。如果只是临时切换客户端测试,优先用客户端自带的自动识别;如果打算长期维护一份跨客户端通用的订阅,订阅转换服务更省心。

转换中常见的字段丢失与规避方法

格式互转最容易出问题的地方,往往不是节点本身连不上,而是一些"看起来无所谓"的字段被转换工具默默丢弃了。以下几类字段尤其容易在互转中消失:

  • TLS 相关参数:比如 skip-cert-verify、sni、alpn,部分简化版转换工具默认不解析这些字段,导致原本正常的节点转换后握手失败。
  • 传输层扩展:VMess/Trojan 节点常带的 ws-opts、grpc-opts 等传输配置,如果转换工具只按最基础的协议模板解析,这部分会被整段忽略。
  • 策略组引用关系:如果原订阅的规则里引用了某个自定义策略组名称,转换后节点名称或分组名称发生变化,规则会匹配不到对应的组,进而全部落到默认策略。
  • DNS 与 TUN 相关配置:纯节点列表本身不带这些字段,转换服务补全时用的是自己的默认模板,和用户原本习惯的 DNS 策略可能不一致,需要转换后手动核对。

互转之后先不要直接删除旧订阅。建议先在新客户端里试跑几个小时,确认延迟测速、规则分流、TUN 模式(如果用到)都正常,再清理旧的订阅记录,避免转换有遗漏时无法回退。

另外,不同订阅转换服务对协议的支持程度也不一样,尤其是较新的协议或混淆参数,建议转换后打开生成的 YAML 文件,抽查几个节点的字段是否完整,而不是只看节点数量对不对。

三种格式对照小结

格式内容范围典型场景直接导入 Clash
完整 YAML 配置节点 + 策略组 + 规则订阅方统一维护规则支持
Base64 节点列表仅节点参数机场/多协议聚合订阅需客户端自动转换
通用分享链接单条或多条节点参数手动添加单个节点需转换或手动填写

整体来看,只要弄清楚订阅内容到底属于哪一类,再选择匹配的导入或转换方式,大部分"订阅导入后没有节点"或者"规则不生效"的问题都能提前避免。格式互转不是玄学,核心就是确认字段有没有被完整保留下来。

下载Clash