订阅与选型 预计阅读 10 分钟

Clash 订阅格式科普:Base64 节点列表、YAML 配置与分享链接的区别

讲清常见订阅返回的几种格式,哪些能被 mihomo 直接识别,哪些需要转换,以及自建转换时需要注意的规则与分组问题。

订阅地址与订阅内容：先区分入口和数据

Clash 订阅地址通常是一条 HTTPS 链接。它提供的是获取配置的入口，并不代表返回内容一定符合 Clash 或 mihomo 的配置要求。同一服务可能分别提供通用节点订阅、Clash 配置和其他客户端格式；部分服务还会根据请求参数或客户端的 User-Agent 返回不同内容。

判断格式时，应看客户端下载到的响应正文，而不是只看地址后缀。没有 .yaml 后缀的链接也可能返回完整 YAML；带有该后缀的地址也可能因为登录过期而返回 HTML 页面。HTTP 状态码为 200，只能说明服务器返回了响应，不能证明配置有效。

三种常见格式：分享链接、Base64 列表与 YAML

格式 识别方式 通常包含什么 用于 Clash 的处理方式
节点分享链接 以 ss://、vmess://、vless://、trojan:// 等开头 单个节点的协议、地址、认证信息及部分传输参数 由支持该协议的客户端导入功能或转换工具解析
Base64 节点列表 正文通常是一长段编码文本，解码后常为逐行分享链接 多个节点，通常不含 Clash 分组和规则 先解码并解析节点，再生成适用的配置或提供器文件
完整 Clash YAML 存在 proxies、proxy-groups、rules 等顶层字段 节点、策略组、分流规则及可选的 DNS 等设置 字段和协议受当前内核支持时，可作为配置加载
代理提供器 YAML 核心内容是顶层 proxies 列表 供主配置引用的节点集合 通过主配置中的 proxy-providers 加载，再由策略组引用

分享链接不等于完整代理规则

一条分享链接可以描述一个节点，却通常不描述“哪些域名直连”“哪个策略组负责最终匹配”。例如，TLS、SNI、WebSocket 路径属于节点连接参数；DOMAIN-SUFFIX、GEOIP 和 MATCH 属于 Clash 分流配置。两者处于不同层次，不能靠节点链接自动推导出完整规则。

不同协议的链接编码方式也不同。vmess:// 的常见形式会编码一段 JSON；ss:// 存在不同的历史表达方式；vless:// 则常通过查询参数携带传输设置。把所有链接都按同一种 Base64 结构拆开，容易遗漏或误读字段。

Base64 是编码，不是加密

“Base64 订阅”通常是把多行节点链接整体编码后返回。解码只负责还原文本，不会补充策略组，也不会把不支持的协议变成受支持的协议。部分内容还会使用 URL 安全字符或省略末尾填充符，因此不能只凭“是否以等号结尾”判断它是不是 Base64。

节点密码和订阅凭据可能直接包含在编码内容里。公开粘贴原始订阅、解码结果或完整二维码，都可能暴露同一套访问凭据。排查时应使用本地文本工具，并在分享截图前遮盖认证字段。

mihomo 能直接加载什么，哪些情况需要转换

mihomo 是 Clash Meta 后续使用的项目名称。对配置文件入口而言，最明确的输入是符合其配置结构的 YAML。完整配置需要有可用的出口和匹配逻辑；代理提供器文件则服务于主配置中的 proxy-providers，不能仅凭文件也是 YAML 就视为完整配置。

  • 服务提供 Clash Meta 或 mihomo 配置：优先使用这一格式，同时检查客户端内核是否支持订阅中的具体协议和字段。
  • 服务只提供 Base64 或逐行 URI：先确认图形客户端是否支持该导入方式；不支持时，再用可信转换工具输出目标格式。
  • 正在使用代理提供器：以当前 mihomo 版本支持的提供器格式为准。不同版本对其他载荷格式的支持可能有差异，顶层 proxies 的 YAML 便于明确检查节点字段。
  • 出现 unsupported proxy type：核对实际运行的内核、节点类型和客户端发行说明。文件转换成功不代表运行内核已经支持该协议。

也不要把 TUN 当作格式兼容开关。TUN 模式负责通过虚拟网卡接管流量，订阅解析发生在配置加载阶段。遇到 YAML 解析错误、节点字段不受支持或策略组引用缺失时，开启 TUN 不会解决这些问题。

完整 YAML 与节点提供器：两个文件的职责

下面是一份用于理解结构的 mihomo 配置。它只提供直连，不含远程代理节点，也不需要填写账户信息。7890 是本示例的混合代理端口；若本机已被占用，应改用空闲端口，并同步修改使用它的应用设置。

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

proxies: []

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

rules:
  - MATCH,出口选择

proxies 保存显式定义的节点，proxy-groups 组织可选择的出口，rules 决定连接交给哪个出口。规则中的 出口选择 必须与策略组名称一致。只有节点列表而没有预期的策略组和分流规则，不能还原一份完整配置的行为。

提供器文件由主配置引用

若希望更新节点时保留自己的规则，可以把节点集合与主配置分开。下面片段使用本地文件提供器，路径为 ./providers/nodes.yaml；它需要与主配置的其他部分合并使用，不能当作完整配置直接覆盖现有文件。

proxy-providers:
  订阅节点:
    type: file
    path: ./providers/nodes.yaml

proxy-groups:
  - name: 节点选择
    type: select
    use:
      - 订阅节点
    proxies:
      - DIRECT

rules:
  - MATCH,节点选择

该本地文件的 YAML 顶层应有 proxies 列表，列表中填写当前内核支持的节点定义。相对路径按内核的工作目录解析，不一定等于在文件管理器中看到的配置文件所在目录；图形客户端还可能管理独立的数据目录，应以运行日志和客户端配置目录入口为准。

use 引用的是提供器名称，不是某个节点名称。更换节点列表后，只要提供器名称保持稳定，主配置中的策略组和规则就不必随每个节点名称逐一修改。使用 HTTP 提供器时，还要配置远程地址、缓存路径及更新间隔，并确认订阅格式适合该提供器入口。

订阅转换时，重点检查协议参数与策略组

转换工具通常做两件事：解析节点数据，再把结果套入目标配置。第二步可能引入工具预设的 DNS、规则、策略组和端口。因此，“节点数相同”不是转换正确的充分条件，还需要检查生成配置的具体行为。

  1. 核对目标类型。区分完整配置与节点提供器输出。准备通过 proxy-providers 加载时，应选择适合提供器的输出，而不是把完整主配置当节点文件使用。
  2. 核对关键连接参数。逐项检查服务器地址、端口、认证信息、TLS 开关、SNI、传输类型、WebSocket 路径及 Host。使用 REALITY 的节点还需要保留相应公钥和 short-id 等参数。
  3. 核对名称引用。规则目标、策略组成员、提供器名称必须对应。重命名节点后，静态列举该节点的策略组也要更新；重命名策略组后，规则目标同样要同步。
  4. 核对过滤结果。正则筛选可能因为节点名称变化而排除全部节点。先查看提供器中的实际节点数，再检查策略组是否筛选到了预期成员。
  5. 核对全局设置。查看转换模板是否改变 dns、tun、allow-lan 或控制接口。不要只检查 proxies 一节。

自建转换服务的访问边界

把原始订阅地址交给转换服务，意味着该服务能够读取订阅内容。自建时应限制访问来源、设置认证，并避免将完整请求地址记录到公开访问日志。若服务允许任意用户提交抓取地址，还应限制回环地址、内网地址及云环境元数据地址，防止转换接口被用作访问内部网络的入口。

嵌套订阅地址还涉及 URL 编码。原始地址中已有 &、? 或百分号时，直接拼接到转换接口查询字符串，可能把一个订阅拆成多个参数。使用工具提供的表单或规范的 URL 构造方式，不要靠手工替换几个字符处理整条链接。

导入失败排查：从响应正文到配置验证

第一步：确认拿到的不是网页

检查客户端的订阅更新日志。出现登录页、验证码页、访问拒绝提示或 HTML 标签时，应先解决订阅授权和服务响应问题。401、403 通常需要核对凭据或访问限制；429 应按服务提示降低请求频率，不要连续点击更新。

第二步：确认结构和字符

YAML 使用空格缩进，不应使用 Tab。列表项前的短横线、字段后的英文冒号和正确的层级都很重要。遇到带有冒号或井号的节点名称时，可以用引号包住名称，避免其被误解为结构或注释。不要通过简单删除报错行修复配置，因为下一条规则可能仍然引用已删除的对象。

第三步：使用实际运行的内核验证

独立运行 mihomo 时，可以使用配置测试参数检查文件。以下命令假设当前目录下已有名为 config.yaml 的配置，且 mihomo 已加入命令搜索路径：

mihomo -t -f ./config.yaml

测试能够发现配置解析和部分引用问题，但不等于远程节点可用。测试通过后，还要在客户端确认所选策略、查看连接日志，并进行实际请求。图形客户端可能对配置应用覆写，应检查最终生效配置，而不是只检查订阅下载前的模板。

更新后规则丢失：把节点更新与本地配置分开

完整订阅配置常会在更新时重新生成。直接在下载文件中修改 rules，下次更新就可能被远端内容覆盖。需要长期保留修改时，优先使用客户端提供的覆写或合并功能；也可以维护自己的主配置，让远程订阅只负责提供节点。

  • 只想导入后使用：选择服务明确提供的 mihomo 或 Clash Meta 完整配置，确认策略组和规则符合需求。
  • 需要固定本地分流：保留自有规则和策略组，通过提供器更新节点，或使用客户端支持的持久覆写入口。
  • 需要修改 DNS 或 TUN：在最终生效配置中检查这些字段，确认客户端是否另外接管它们，避免同时维护两套互相覆盖的设置。
  • 准备迁移客户端：同时备份订阅入口和本地覆写。仅复制订阅 URL，通常不会带走本地规则、界面中的节点选择或系统代理设置。

排查顺序可以固定为：确认返回格式，确认导入入口，检查内核能力，验证引用关系，最后测试连接。格式负责表达数据，策略组和规则负责分流，系统代理与 TUN 负责把流量送进内核。把这几层分开，才能判断该转换订阅、调整配置，还是处理网络连接。

需要继续了解配置字段，可查看进阶配置；分不清节点、策略组和规则时，可先查阅名词解释。订阅原始链接应保存在受控位置，诊断材料只保留与故障有关的字段。

下载Clash