Clash 订阅格式详解：YAML 配置、Base64 链接与 SIP008 的转换方法

先判断订阅返回什么，再决定是否转换

“订阅链接”只说明客户端通过一个地址获取内容，并不代表内容一定是 Clash 配置。同一个 HTTPS 地址，可能返回完整 YAML、Base64 编码的节点列表、SIP008 JSON，甚至登录页面。导入失败时，先看响应正文，比反复更换文件扩展名有效。

还要区分三个层次：订阅 URL 是获取入口；YAML、JSON、Base64 是内容结构或编码方式；Shadowsocks、Trojan、VLESS 等是节点使用的代理协议。把 Base64 解码，并不会把 Shadowsocks 节点变成另一种协议，也不会自动生成规则分流。

内容类型	识别线索	导入 Clash 的处理
完整 YAML	常见 `proxies:`、`proxy-groups:`、`rules:`	检查目标内核兼容性后作为配置导入
节点型 YAML	主要包含 `proxies:`，缺少策略组与规则	作为节点来源使用，或补齐配置结构
Base64 节点订阅	编码文本；解码后常见多行 `ss://` 等链接	解析节点，再生成 YAML 配置
SIP008 JSON	常见 `version` 与 `servers` 字段	将 Shadowsocks 服务器字段映射为节点
HTML 或错误 JSON	登录提示、访问拒绝、额度错误	先修复订阅访问，不能靠转换解决

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

Clash 系列内核以 YAML 表达运行配置。节点负责连接远端服务器；策略组把多个节点组织成手动选择、自动测速或故障切换入口；规则按顺序匹配连接目标，将流量交给指定策略。监听端口、DNS 与 TUN 则属于本机网络接入设置。

完整配置不等于节点列表

proxies 中有节点，不代表流量已经会使用它们。若规则最终仍是 MATCH,DIRECT，未被前面规则命中的连接就会直连。若规则引用了不存在的策略组，配置可能无法加载。订阅转换需要同时处理节点名称和策略引用，不能只拼接几段文字。

下面是一份用于理解结构的直连示例，不含远端代理节点。监听端口设为 7890，只允许本机访问；全部流量交给“出口选择”，而组内仅有 DIRECT。它不能用于验证远端节点是否可用。

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

proxies: []

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

rules:
  - MATCH,出口选择

YAML 语法与内核支持是两次检查

缩进使用空格，不用 Tab。同一层级保持一致，示例采用两个空格。
节点名称、密码及含特殊符号的字符串建议加引号，避免被解释为其他类型。
YAML 能被解析，只代表语法成立；协议类型、传输参数和策略组选项仍须由目标内核支持。
传统 Clash 与 Clash Meta（现名 mihomo）的支持范围不同。包含 VLESS、Hysteria2 等节点时，应核对目标内核文档，不能仅凭客户端名称判断兼容性。

Base64 订阅：解码只恢复文本，不生成规则

常见的 Base64 订阅会先把多条分享链接按行排列，再对整段文本编码。解码后可能看到 ss://、trojan://、vmess:// 或 vless://。这些链接各有自己的字段规则，转换器需要逐条识别。

还可能存在内外两层编码：外层是订阅列表的 Base64，内层是单个分享链接携带的编码数据。例如部分 Shadowsocks 链接会对认证信息编码，常见 VMess 分享链接则使用 Base64 承载 JSON。只解开外层后，节点信息未必已经全部可读。

在本机检查订阅内容

将订阅响应保存为 subscription.txt 后，可在本机解码。下面命令适用于常见的标准 Base64 文本；输出文件含节点凭据，应放在私人目录内，不要上传公开仓库。

# Linux：GNU coreutils
base64 --decode subscription.txt > nodes.txt

# macOS
base64 -D -i subscription.txt -o nodes.txt

如果工具提示编码无效，先检查下载到的是否为 HTML，以及是否使用了 URL 安全字符、缺少填充或含额外包装。不要把所有错误都归为“订阅坏了”。某些转换器能兼容这些变体，但具体能力取决于实现。

SIP008：Shadowsocks 服务器的 JSON 订阅

SIP008 是 Shadowsocks 生态中的一种订阅约定，不是通用代理协议，也不是 Clash 配置。其 JSON 使用服务器数组描述节点，常见字段有服务器地址、端口、加密方法和密码。标准结构可以携带多个 Shadowsocks 服务器，但不会因此获得 Clash 的策略组或分流规则。

下面使用保留示例域名展示字段关系，密码也仅用于说明结构，不对应可连接的服务。实际转换应保留服务方给出的原始认证值。

{
  "version": 1,
  "servers": [
    {
      "id": "80a3cf64-dcec-4ca9-bd7b-b69b9763ca15",
      "remarks": "SS 示例节点",
      "server": "edge.example.com",
      "server_port": 443,
      "password": "demo-password-not-for-use",
      "method": "aes-128-gcm"
    }
  ]
}

SIP008 到 Clash 的字段映射

remarks 通常用作 Clash 节点的 name；重名时需要去重，并同步调整策略组引用。
server 保留为服务器地址，server_port 映射为 port。
method 映射为 cipher，password 保留为认证密码，并设置 type: ss。
若源数据包含 plugin 与 plugin_opts，需核对目标内核支持的插件及参数格式，不能直接原样复制为 Clash 字段。

部分服务端返回的是自定义 JSON 或旧式数组，并不完全符合上述结构。转换工具即使标注“支持 SIP008”，也未必兼容所有变体。出现“没有可用节点”时，应检查响应顶层结构与必填字段，而不是反复尝试同一组导入操作。

订阅转换步骤：从原始响应到完整 YAML

优先选择源站提供的目标格式

若订阅管理页面已经提供 Clash 或 mihomo 专用入口，优先使用对应入口。这通常能减少中间转换环节，并保留服务方配置的节点参数。同一订阅地址有时会根据请求参数或 User-Agent 返回不同格式，因此浏览器里看到的结果不一定与客户端拉取结果相同。

需要转换时，按五步处理

确定目标内核。先在客户端的关于或内核信息页面确认使用传统 Clash 还是 mihomo。界面路径随客户端变化，以实际显示为准，不用外壳名称代替内核名称。
识别源格式。查看响应开头与结构，区分 YAML、Base64、SIP008 和错误页面。保留原始文件作为对照，不直接覆盖现用配置。
选择转换运行位置。优先使用可信的本机工具或自行部署的服务。网页表单不等于本地处理；若表单把订阅地址提交给后端，后端就能访问订阅内容。
选择输出模板。确认输出是完整配置，还是只含节点的 provider 文件。检查策略组、规则与 DNS 设置是否符合需求，不要盲目套用面向其他内核的模板。
保存、校验、试运行。将输出另存为 YAML 文件，通过目标内核测试后再导入客户端。先保留旧配置，确认访问与更新都正常后再切换日常使用。

转换器里的“Clash”与“Clash Meta”目标选项可能代表不同的序列化能力。选择传统目标，可能丢弃新协议或传输参数；选择 mihomo 目标，也不能让传统内核读懂新增字段。输出格式必须与实际运行内核配套。

导入前检查：字段保留、配置测试与真实连接

“成功生成文件”不等于“成功连接”。检查应分三层：先查语法与配置引用，再查节点握手，最后查规则命中与目标网站访问。这样可以区分解析错误、认证错误和分流错误。

使用目标内核测试配置

已安装 mihomo 命令行程序时，可对转换结果执行配置测试。命令中的 converted.yaml 是本机保存的输出文件名；若不在当前目录，应使用实际文件路径。

mihomo -t -f ./converted.yaml

配置测试可能需要读取外部 provider 或规则资源，运行环境也会影响结果。测试通过只说明此次校验没有发现阻止加载的问题，不代表服务器认证成功，也不代表所有站点都能访问。

逐项核对容易丢失的参数

地址与端口：检查 server、port 是否完整，端口 443 也不自动代表启用了 TLS。
认证字段：核对密码、UUID、加密方法等协议必需信息，留意转义和 URL 解码是否正确。
TLS 与传输：核对 SNI、证书校验、ALPN、WebSocket 路径及 Host 等字段；不要用关闭证书验证来掩盖参数错误。
节点引用：策略组引用的名称必须存在，重命名节点后应同步处理引用。
本机监听：示例中的 7890 是本地代理端口，不是远端服务器端口。已有进程占用时，需协调修改客户端与应用代理设置。

导入后先手动选择一个节点，再观察连接日志中的目标、命中规则和出口策略。若日志显示 DIRECT，应先检查规则是否把流量交给代理组。若已命中节点却握手失败，再检查协议参数和服务器连通性。

持续更新：完整配置与 proxy-providers 分开管理

一次性转换并保存为本地 YAML，通常只得到当时的快照。服务方新增节点、轮换密码或删除线路后，本地文件不会自行同步。只有配置了有效的远程更新链路，客户端或内核才有机会获取新内容。

常见方案有两种：让客户端定期更新完整远程配置；或者由主配置保留策略组与规则，通过 proxy-providers 更新节点。后一种适合希望固定本地分流逻辑的用户，但需要正确配置 provider、策略组的 use 引用以及更新周期。

不要把任意订阅地址直接当作 provider

普通 YAML 节点 provider 通常需要返回以 proxies: 组织的节点内容。完整配置、Base64 列表和 SIP008 JSON 不能不加判断地互换。mihomo 的具体 provider 能力随内核实现而异，使用其他格式前应核对文档与测试结果。

例如将更新间隔设为 3600 秒，含义是按一小时周期尝试更新，并不保证每次请求成功。地址失效、网络不可达或转换服务故障时，仍须查看更新日志与本地缓存。不要仅凭定时器已经启用就判断节点是最新状态。

常见问题：导入报错、节点缺失与凭据保护

提示 YAML 解析失败，先查哪里？

先看文件开头是否是 HTML、JSON 错误或未解码文本，再根据错误行号检查缩进、引号和冒号。网络请求返回 HTTP 200 也可能携带登录页面，状态码本身不能证明拿到了配置。

转换后节点数量减少，是否属于正常过滤？

不能直接认定正常。先查地区或名称筛选条件，再查目标格式是否支持全部协议，最后查重名去重、插件参数和解析失败日志。节点减少可能是明确筛选，也可能是转换能力不足，应对照源数据确认。

一条节点链接能否直接作为订阅？

单条分享链接通常只描述一个节点，不包含远程更新机制。部分客户端支持添加单节点，但这不等同于导入完整配置。若要使用规则分流，仍需把该节点接入策略组和规则。

订阅地址已经发给第三方，如何处理？

在服务方后台重置或撤销原订阅令牌，更新客户端保存的地址，并删除公开记录中的敏感内容。仅删除本地转换文件无法撤销已经泄露的访问权限；节点密码是否也需要轮换，应根据服务方的凭据机制判断。

实际操作可归纳为四项：确认输入格式，选择匹配内核的输出，测试最终生效配置，保护订阅凭据。先把这四项做实，再调整规则模板与更新方式，排错范围会更明确。