Clash YAML 订阅与 Base64 节点链接:格式差异与互相转换方法

先区分订阅地址、响应格式与配置文件

订阅地址只是获取内容的入口。一个以 https:// 开头的链接，可能返回完整 Clash 配置，也可能返回经过 Base64 编码的节点列表。地址中出现“clash”字样或文件名以 .yaml 结尾，都不能代替对响应正文的检查。

部分服务会根据请求参数、客户端标识或账户设置返回不同格式。因此，同一地址在浏览器与客户端里取得的内容可能不同。排查时应记录实际导入入口、响应正文类型和客户端使用的内核，而不是反复修改文件扩展名。

格式	可识别结构	通常包含什么	导入位置
完整 Clash YAML	`proxies:`、`proxy-groups:`、`rules:` 等字段	节点、策略组、规则及其他配置	配置文件或远程配置入口
节点提供器 YAML	主要是顶层 `proxies:` 列表	供主配置引用的节点集合	`proxy-providers` 对应资源
Base64 节点列表	解码后常见每行一个 URI	节点连接参数，通常没有分流规则	支持此格式的订阅入口或转换工具
单节点 URI	`ss://`、`trojan://` 等前缀	一条节点及其协议参数	支持该协议的节点导入入口

Clash YAML：节点之外还有策略组与规则

完整配置中的 proxies 定义连接参数，proxy-groups 定义选择方式，rules 定义流量去向。转换器如果只提取节点，就会丢失后两部分。DNS、监听端口与 TUN 设置也不属于单节点 URI 能完整表达的内容。

最小结构示例

下面展示一个常见 Trojan 节点如何放入主配置。域名和密码仅用于说明结构，不能用于实际连接。7890 是本地混合代理端口，443 是远端节点端口，两者不能互换。

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

proxies:
  - name: "demo-trojan"
    type: trojan
    server: edge.example.com
    port: 443
    password: "demo-password"
    sni: edge.example.com
    udp: true

proxy-groups:
  - name: "手动选择"
    type: select
    proxies:
      - "demo-trojan"
      - DIRECT

rules:
  - MATCH,手动选择

这里的 MATCH,手动选择 是兜底规则，不代表一套按地区或域名分类的分流方案。策略组选中 DIRECT 时，匹配该组的连接会直接访问；选中示例节点时，才会尝试通过该节点建立连接。

name 是引用标识。节点改名后，策略组中使用旧名称的条目也需要同步修改。
server 是连接目标，sni 是 TLS 握手使用的服务器名称；二者在实际部署中不一定相同。
udp: true 允许该节点参与相应 UDP 转发，但不能据此推断服务端或当前接入方式已经支持所有 UDP 流量。

Base64：解码只还原文本，不生成 Clash 字段

Base64 是编码方式，不是代理协议，也不是加密。它可以把多行节点链接包装成一段文本，但不会自动补充策略组、DNS 或规则。把一段 Base64 解码后另存为 config.yaml，如果内容仍是 URI 列表，Clash 配置解析器依然无法把它当作 YAML 主配置使用。

按两层内容判断

先查看外层正文。若直接出现 proxies: 等结构，应先按 YAML 检查，不要强行解码。
若正文是一段疑似编码文本，使用本地工具解码，再确认结果是否为可读文本。
若解码结果每行以 ss:// 或 trojan:// 等开头，它通常是节点列表，还需要协议解析与字段映射。
若结果是 HTML 错误页、登录提示或 JSON 报错，应先处理订阅访问问题，不能继续当作节点转换。

例如，aGVsbG8= 解码为 hello，这只能证明编码能够还原，不能证明内容是有效订阅。标准 Base64 常用 +、/ 和末尾的 =；URL 安全变体会使用 -、_，某些实现还会省略补齐字符。解码器需要按实际变体处理，不能任意替换节点原文。

还要区分外层订阅编码与节点内部编码。例如，某些 Shadowsocks URI 的用户信息部分本身也使用 Base64。外层解码得到 ss:// 之后，仍需按对应 URI 规范解析，不能把整条 URI 再机械地解码一次。

单节点 URI 到 YAML：逐项映射连接参数

以下 URI 与前面的 Trojan 示例描述相同的基本连接信息。它没有携带“手动选择”策略组，也没有携带 MATCH 规则。末尾的片段用于节点名称；真实名称若包含空格、中文或特殊符号，应由导出器按 URI 规则编码。

trojan://[email protected]:443?security=tls&sni=edge.example.com#demo-trojan

URI 部分	YAML 对应字段	检查点
`trojan://`	`type: trojan`	目标内核必须支持该协议
`demo-password`	`password`	按规范处理百分号编码，保留原始凭据含义
`edge.example.com`	`server`	不要用 SNI 值随意覆盖连接地址
`:443`	`port: 443`	写成整数，取值为 1 至 65535
`sni=edge.example.com`	`sni`	确认与服务端证书和部署要求匹配
`#demo-trojan`	`name`	解码名称后检查重复项与策略组引用

不同协议不能套用同一张映射表

Shadowsocks 通常需要 cipher 与 password；VMess 常见 UUID、传输层与 TLS 参数；VLESS、Hysteria2 等还涉及目标内核支持范围。原版 Clash 与 Clash Meta（mihomo）的协议能力并不相同，转换目标应明确到内核，而不是只写“Clash 通用”。

WebSocket 的路径、Host 请求头，以及 gRPC 的服务名，属于实际连接参数。以 WebSocket 为例，mihomo 配置常见 network: ws、ws-opts.path 和 ws-opts.headers.Host。如果转换只保留服务器、端口与密码，节点可以出现在列表里，却可能无法完成握手。

互相转换：先确定要保留节点还是整份配置

Base64 或 URI 列表转 Clash YAML

备份来源。保存订阅原文和当前可用配置。含令牌的订阅地址属于敏感凭据，不放入截图、公开日志或问题附件。
确认输出目标。选择工具实际提供的 Clash 或 mihomo 目标，并核对节点协议是否在该目标的支持范围内。
还原并解析节点。外层有 Base64 才解码；对每条 URI 分别识别协议、地址、凭据、TLS 与传输参数。
决定输出形态。只替换现有配置的节点时，生成节点列表或提供器资源；需要独立导入时，生成带策略组和规则的主配置。
检查模板改动。转换模板可能加入 DNS、规则提供器或 TUN 字段。逐项查看，不把这些新增内容误认为订阅原始设置。

客户端的“从链接导入”不一定兼容所有响应格式。有的入口要求完整 YAML，有的允许导入节点 URI，还有的会调用额外的转换服务。应按当前客户端的入口说明选择；仅修改链接名称并不能改变其响应正文。

Clash YAML 转 URI 或 Base64

从 proxies 中提取实际节点。如果主配置只引用 proxy-providers，需要取得对应提供器资源，不能把提供器的 URL 当作节点地址。
按每种协议的 URI 规范序列化连接参数。目标客户端不支持的字段要明确记录，不能静默丢弃。
一行放一条 URI。只有接收方要求 Base64 订阅时，才对整份列表按约定编码。
在接收方重新导入，核对节点数量与关键字段，再做连接测试。

这种反向转换通常有损。proxy-groups、rules、dns、tun 和本地监听端口不会因导出节点 URI 而一起迁移。即使节点连接成功，访问行为也可能与原配置不同，需要在接收端另外建立分流策略。

转换后检查：从语法到实际流量

“导入成功”只说明某个入口接受了文件，不代表字段全部保留，也不代表所有出站都可连接。建议按以下顺序验证，先排除结构问题，再定位网络问题。

第一步：使用目标内核检查配置

已经安装 mihomo 命令行内核时，可以在配置所在目录执行下面的检查。命令用于读取并测试配置，不是启动长期代理服务；如果配置依赖相对路径资源，需要同时准备对应文件，并留意检查输出中的资源加载错误。

mihomo -t -f ./config.yaml

重点查看 YAML 缩进、重复节点名、策略组引用和不支持的协议字段。字符串密码建议保留引号，避免 # 被当作注释或某些值被按其他 YAML 类型解释。不要使用制表符代替缩进空格。

第二步：逐项比对，而不是只看节点名称

数量：原始列表有多少条，转换后有多少条；被过滤或去重的项目应有明确原因。
连接：比对 server、port、凭据、加密方式和 TLS 参数。
传输：核对 WebSocket 路径、Host、gRPC 服务名等协议相关选项。
引用：确认策略组指向现有节点，规则指向现有组；组名中的空格与大小写也要一致。
本地入口：本例应用应连接本机 127.0.0.1:7890，不是远端节点的 443 端口。

第三步：分开验证 TCP、DNS 与 UDP

先选定一个节点，使用明确配置了代理的应用访问 HTTPS 页面，再看连接日志中的出站与报错。延迟测试通过只说明测试请求在当时完成，不能证明视频、游戏或所有目标站点都可用。遇到域名解析失败，应检查 DNS 配置；遇到 TLS 握手错误，应核对 SNI、系统时间与证书，而不是直接关闭证书验证。

如果 HTTP 代理访问正常，但游戏仍然直连，问题可能在流量接入方式。转换节点格式不会自动打开 TUN，也不会自动让全部应用流量经过代理。需要全局接管或 UDP 转发时，应另外检查 TUN、路由及客户端权限；这些属于运行配置，不是 Base64 编码层的问题。

常见问题与格式选择

为什么转换服务返回成功，客户端却提示没有可用节点？

先查看输出正文是否真有 proxies 列表，再检查是否被筛选规则清空、协议是否被目标内核支持，以及策略组是否引用了转换前的旧名称。HTTP 请求成功不等于转换结果有效；返回的也可能是服务错误说明。

把配置转成 Base64 后，分流规则还能保留吗？

编码任意文本当然可以保留其字节，但接收端必须知道解码后是什么。常见“Base64 订阅”约定的是节点 URI 列表，不是编码后的完整 YAML。把整份 YAML 编码，并不会让只识别 URI 列表的客户端理解其中的分流规则。

转换后还能自动更新吗？

本地导出的文件是当时的快照，不会自行同步。远程转换地址能否更新，取决于它是否每次重新获取来源、如何缓存，以及客户端的更新行为。通过 proxy-providers 更新节点时，主配置里的策略组和规则仍由主配置维护。

订阅转换应该放在本地还是在线服务？

优先使用订阅提供方直接提供的目标格式，减少中间环节。必须转换时，本地工具便于控制凭据流向。使用在线服务意味着向该服务提交订阅地址或节点参数；即使地址经过 Base64 编码，接收方仍可还原，应先确认信任关系。

选择标准可以归纳为两条：需要一起迁移节点、策略组和分流规则时，优先使用目标内核支持的完整 YAML；只需要交换节点时，使用接收方支持的 URI 或节点列表。更多字段含义可查阅配置参考，客户端选择可查看选型指南。