选型对比 约 8 分钟阅读

Clash 订阅格式科普:YAML、Base64 与通用格式如何相互转换

介绍常见订阅格式的结构差异与客户端兼容情况,说明什么时候需要格式转换、转换的基本原理,以及自建转换服务时的注意事项。

订阅链接背后到底是什么

一条订阅链接本质上是一个可被客户端定期请求的 HTTP(S) 地址,服务器返回的内容才是真正的配置数据。不同厂商、不同面板生成的订阅内容格式并不统一,常见的有三类:Clash 专用的 YAML 结构、以 Base64 编码打包的通用节点列表、以及部分客户端自定义的 JSON 或纯文本格式。客户端在拉取订阅后会先判断返回内容的类型,再按对应的解析规则把节点信息、分流规则写入本地配置,这一步失败往往就是订阅"导入了但用不了"的根源。

判断格式类型不能只看链接后缀,很多订阅地址并不带 .yaml 或类似标记,真正起作用的是响应头的 Content-Type 与响应体的实际内容。客户端解析器通常会先尝试按 YAML 解析,失败后再尝试 Base64 解码,如果两者都不匹配才会报格式错误,这也是为什么同一条订阅在不同客户端里表现不同——解析器的容错顺序和支持范围不完全一致。

YAML 格式:Clash 原生配置结构

Clash 与 Clash Meta(mihomo 内核)原生识别的配置就是 YAML 文本,顶层通常包含 proxies(节点列表)、proxy-groups(策略组)、rules(分流规则)等字段。这种格式的优势是信息完整、可读性强,策略组的分组逻辑、规则的匹配顺序都能直接体现在文本里,进阶用户可以直接打开配置文件做局部修改。

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,github.com,自动选择
  - MATCH,DIRECT

需要注意的是,YAML 对缩进和冒号后的空格非常敏感,手工编辑时哪怕多一个空格或漏一个冒号都会导致整份配置解析失败。如果订阅商提供的是 YAML 直链,通常不需要用户手动处理,客户端会整段拉取并覆盖或合并到本地配置,只有自建节点、手工拼接规则时才需要留意语法细节。

Base64 与通用订阅格式的兼容逻辑

Base64 格式最早是为了兼容早期客户端与在线分享场景而流行起来的:服务器把每个节点信息拼成一条 协议://参数 形式的链接(例如 ss://、vmess://、trojan:// 开头),再把所有链接按行拼接后整体做 Base64 编码,输出为一段没有换行的字符串。客户端拉取后先做 Base64 解码,还原出一行一个节点的文本,再逐行解析协议类型和参数,最终生成内部可用的节点列表。

这种格式的好处是通用性强,几乎所有主流客户端(不限于 Clash 系)都认识这套编码规则,同一条订阅可以喂给不同软件使用,适合面板同时对接多种客户端的场景。但它的局限也很明显:Base64 通用格式里不包含策略组、分流规则这类结构化信息,客户端拿到节点后只能按自己内置的默认分组逻辑处理,规则的精细程度天然弱于 YAML 原生订阅。部分客户端在导入通用格式后,规则集合是本地预置的静态模板,更新订阅只会替换节点,不会改变分流逻辑。

格式类型典型内容规则信息兼容范围
YAML(Clash 原生)节点+策略组+规则完整,可自定义Clash / Clash Meta 系客户端
Base64 通用仅节点列表依赖客户端本地模板绝大多数主流客户端
自定义 JSON因面板而异部分包含分组逻辑特定面板配套客户端

什么时候需要做格式转换

大多数情况下用户不需要手动转换,直接把订阅链接粘贴进客户端的订阅管理界面即可,客户端会自动识别格式并完成解析。真正需要转换的场景集中在以下几种:

  • 面板只提供通用 Base64 订阅,但用户希望在 Clash 里使用自定义的分流规则和多层策略组,这时需要把节点信息转换成 YAML 结构并补齐 rules 字段。
  • 手里已有一批零散的协议链接(ss://、vmess:// 等),需要合并成一条可被客户端识别的订阅地址,方便统一管理和自动更新。
  • 从其他客户端迁移到 Clash 系客户端,原订阅是专有格式,需要转换为 YAML 才能保留原有的分组习惯。

转换的基本原理并不复杂:先解析原始订阅还原出结构化的节点参数(服务器地址、端口、加密方式、密码或密钥等),再按目标格式的语法重新拼装。对 YAML 目标格式而言,还需要额外生成策略组和规则,这部分逻辑通常由转换脚本按预设模板填充,而不是从原订阅里"提取"出来的,因为通用格式本身就不携带这些信息。

注意

转换后的订阅本质是一份新生成的配置,节点参数是否准确取决于转换脚本对各协议字段的解析是否完整。遇到部分节点转换后无法连接,优先检查转换环节是否丢失了某个必需参数,再排查节点本身是否有效。

自建转换服务的注意事项

有能力和需求的用户可以自行部署开源的订阅转换服务,把 Base64 通用订阅转成带自定义规则的 YAML 配置,再生成新的订阅链接供客户端拉取。自建转换服务时有几点值得留意:

  1. 规则模板要按需维护。转换服务生成的策略组和分流规则来自本地模板文件,模板过时会导致新增的域名分类无法命中,需要定期更新维护。
  2. 转换环节要控制访问权限。转换服务通常需要经手原始订阅内容,如果部署在公共可访问的地址上,建议加上访问口令或限制来源,避免订阅信息被无关方获取。
  3. 输出订阅的更新频率要和原订阅对齐。转换服务一般是被动触发或定时拉取原订阅再生成新链接,如果定时任务间隔设置过长,客户端拿到的节点信息会滞后于面板端的实际变化。
  4. 协议字段的解析要覆盖全面。不同协议(Shadowsocks、VMess、Trojan、Hysteria 等)的参数结构差异较大,转换脚本如果只覆盖了常见字段,遇到带插件参数或特殊传输层配置的节点容易解析出错。

对普通用户来说,如果客户端本身已经能正常识别订阅格式,不需要额外引入转换环节;转换更多是面板运营方或有特定规则需求的进阶用户会用到的手段,日常使用优先确认客户端和订阅格式是否本身就兼容,再考虑是否需要转换。

下载Clash