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

订阅地址、节点链接与配置文件

同样叫“订阅”，实际交付的内容可能完全不同：一条 HTTPS 地址、几行以 ss:// 开头的节点链接，或一份含有 proxies: 的 YAML 文件。判断能否导入 Clash，关键不是链接长短、文件后缀，而是客户端取得的响应内容，以及当前内核能否理解其中的字段。

订阅地址是获取内容的入口，订阅格式是入口返回的数据结构，代理协议则是节点与服务端通信的方式。这三者不能混用。把文件名从 nodes.txt 改成 config.yaml 不会改变格式；把一段文本做 Base64 编码，也不会让客户端获得新的协议支持。

• 订阅地址：通常是带有账户令牌的 HTTPS URL，用于定期拉取更新，返回内容由服务端决定。
• 节点分享链接：以协议相关的 URI 表示一个节点，例如 ss://、vmess://、trojan://。不同协议的字段编码方式并不相同。
• 完整配置：除节点外，还可能定义策略组、规则、DNS、监听端口及外部资源。

Base64 订阅：编码后的节点链接集合

常见的通用订阅会先把多个节点分享链接按行排列，再对整段文本做 Base64 编码。解码后看到的是一组 URI，而不是 Clash 可以直接加载的完整配置。也有服务直接返回未编码的链接列表，或返回 JSON 等其他结构，不能只靠“看起来像一长串字母”下结论。

Base64 不提供加密保护

例如 aGVsbG8= 解码后就是 hello。Base64 只是把字节转换成便于文本传输的表示形式，不要求密钥。订阅中的密码、UUID、服务器地址即使被编码，拿到内容的人仍可能还原它们。

标准 Base64 常见字符包括字母、数字、+、/，末尾可能有 =；URL 安全变体会使用 -、_，部分实现省略填充。解码失败也可能是变体或换行处理问题，不应立即认定订阅已经失效。

外层解码之后，单条链接还要单独解析

传统 vmess:// 分享链接常把 JSON 放进 Base64 载荷；ss:// 则有自己的用户信息编码及插件参数约定。外层订阅解码和单个协议链接解析是两步操作，不能把同一个“解码”按钮反复执行来代替协议解析器。

Clash YAML：节点、策略组与规则的组合

YAML 是一种数据表示语言，并不是 Clash 专属格式。只有满足当前内核配置结构的 YAML 才能作为配置使用。一个语法正确、内容却是普通文档的 YAML 文件，仍然不能当作 Clash 配置导入。

一个仅供理解结构的配置

下面的例子使用混合端口 7890，只包含直连策略，没有远程代理节点，不能用于验证代理服务是否可用。它展示的是列表、缩进、策略组引用与兜底规则的关系。7890 是此例的取值，不代表所有客户端都使用该端口。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxies: []

proxy-groups:
  - name: "出口选择"
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,出口选择

YAML 缩进应使用空格，不能用 Tab 代替层级缩进。包含 #、冒号等特殊字符的密码建议加引号；节点名也应保持一致。上例若把规则目标改成不存在的“代理出口”，即使缩进全部正确，配置验证仍可能失败。

还要区分完整配置与节点提供器资源。常见的 YAML 节点资源只有顶层 proxies:，它适合被 proxy-providers 引用，却不等于已经安排好分流规则的完整配置。部分客户端能自动补齐策略组，部分不会，不能依赖相同的导入结果。

格式兼容与内核兼容是两道检查

Clash 客户端负责界面、订阅管理和系统集成，内核负责连接、解析与规则执行。Clash Meta 后续以 mihomo 名称继续发展，但“支持 Clash 配置”并不意味着各代内核支持完全相同的字段。

例如，包含 VLESS、Hysteria2 或 TUIC 等节点的配置，需要核对目标内核及其具体版本的支持范围。把这些节点转换成 YAML，不会使较早的 Clash 内核获得对应协议实现。即使协议名称受支持，Reality、传输层或 TLS 参数也可能存在版本要求。

1. 先查输入格式：导入入口接受订阅 URL、完整配置文件，还是单条节点分享链接？“从剪贴板导入”也不必然支持所有 URI。
2. 再查内核类型：在客户端的“关于”或内核管理页面确认实际运行的内核，不只看应用名称。
3. 最后查字段：记录配置验证的完整报错，定位到节点类型、传输参数或资源引用，避免反复重新安装客户端。

以 Clash for Android 的常见界面为例，远程配置通常从「配置」→「＋」→「从 URL 导入」添加；导入后还需要选中配置并启动服务。其他客户端可能把同类入口放在「配置」或「订阅」页面，按钮名称随版本变化，应以当前界面为准。若只有单条节点链接，不要默认把它粘进“配置 URL”栏就能完成导入。

订阅转换：解析节点，再生成目标配置

订阅转换不是把 Base64 文本换个后缀。转换器一般先获取源内容，识别并解析每个节点，建立内部表示，然后按目标格式生成节点字段。若目标是完整 Clash 配置，还可能套用规则模板、创建策略组、设置 DNS，或添加自动测速配置。

哪些内容可以转换，哪些会丢失

• 通常可以映射：目标内核支持时，服务器地址、端口、密码或 UUID，以及有明确对应关系的 TLS 和传输参数。
• 可能无法保留：目标格式不支持的插件选项、协议特有参数、客户端私有扩展，以及来源不明确的证书设置。
• 需要重新设计：规则、DNS、策略组嵌套和测试策略。节点链接本身通常没有足够信息还原这些设置。

反过来，把完整 YAML 导出为通用节点链接，也往往只保留节点。原有的分流规则、DNS 和策略组选择逻辑不会自动装进每条 URI。因而“YAML → 链接列表 → YAML”不保证得到原配置，不能把这种往返转换当作备份方式。

在线转换的凭据边界

如果把订阅 URL 交给在线转换服务，转换服务通常需要访问源订阅，也就能够接触地址中的令牌和返回的节点凭据。即使浏览器访问转换页面使用 HTTPS，也只是保护传输链路，并不阻止服务端读取这些数据。

优先使用服务方提供的 Clash 或 mihomo 专用订阅；确需转换时，选择了解其运行方式的工具，条件允许可在本地处理。分享转换结果前也要检查完整 URL，因为源订阅可能嵌在查询参数中。发生误发时，应在服务方后台重置订阅令牌，并确认是否还需更换节点认证信息。

导入失败：按响应、解析、连接逐层排查

“订阅导入成功”和“节点连接成功”是不同阶段。排查时先保留原始配置，不要同时修改 DNS、规则、端口和 TUN。每次只变动一个环节，更容易判断问题来自哪里。

HTTP 200 只说明请求得到响应，不保证正文就是配置；Content-Type 也只能作为辅助线索。浏览器能打开而客户端拉取失败时，还可能涉及重定向、证书信任、请求标识或网络路径差异。不要把浏览器会话 Cookie 当作通用修复方案，也不要为排错关闭证书验证。

更新后失效，先看修改保存在哪里

远程配置更新通常会重新下载内容。直接编辑下载文件，可能在下一次更新时被覆盖。若只是补充个人规则，应优先使用客户端明确支持的覆写、合并或扩展功能，并确认处理顺序；这些能力属于客户端功能，菜单和语法并不统一。

还应检查策略组是否引用了被改名或过滤掉的节点，以及外部节点资源是否成功更新。远程配置本身下载成功，不等于它引用的所有资源也已成功获取。

订阅导入前的选择清单

1. 已有 Clash 或 mihomo 专用订阅：优先直接导入，先确认它与当前内核匹配，减少转换链路。
2. 只有通用 Base64 订阅：查看客户端是否内置节点解析或转换能力；若没有，再选择合适的转换工具。
3. 只有一条分享链接：寻找明确支持该协议的节点导入入口；需要完整配置时，还要补充策略组和规则。
4. 拿到 YAML 文件：先判断是完整配置还是节点资源，再验证语法、引用关系与内核支持。
5. 准备替换正在使用的配置：保留可用版本，新配置验证通过后再切换，确认节点数量、策略组和规则行为。

格式判断解决的是“数据能否被读懂”，内核兼容解决的是“协议能否被执行”，连接日志才进一步说明“服务是否可达”。把这三步分开，通常就能避免在订阅转换、客户端设置和网络故障之间来回试错。具体的初次启动流程可查看本站使用指南，协议与配置字段可结合协议参考核对。