一、订阅地址、编码与配置格式
“订阅链接”首先是一个获取内容的入口,并不是固定的文件格式。同一个 HTTPS 地址可能按请求参数或客户端标识返回不同内容:一组节点分享链接、一份 Clash YAML 配置,或者其他客户端专用的配置。地址末尾有没有 .yaml,都不足以判断它能否直接导入。
判断时需要分清三个层次:地址负责取回内容,Base64 负责把字节编码为文本,配置格式负责描述节点、策略组和规则。Base64 不是加密,也不是代理协议;将订阅解码,只能恢复原来的文本,不能凭空补出分流规则。
| 常见内容 | 识别线索 | 通常包含 | 导入取舍 |
|---|---|---|---|
| 节点 URI 列表 | 多行 ss://、vmess://、trojan:// 等链接 | 节点地址、凭据与部分传输参数 | 由客户端导入器或转换工具解析 |
| Base64 节点订阅 | 外层是一长段编码文本,解码后是 URI 列表 | 通常只有节点信息 | 不能直接当完整 YAML 使用 |
| Clash YAML 配置 | proxies、proxy-groups、rules 等键 | 节点、策略组、规则及可选运行参数 | 仍需核对内核兼容性 |
| 代理提供者文件 | 顶层主要是 proxies 列表 | 供 proxy-providers 引用的节点集合 | 通常需要主配置配合 |
| 其他客户端配置 | 专用分节或 JSON 结构 | 该客户端的节点及路由设置 | 不能仅修改扩展名后导入 |
二、Base64 节点链接能保留什么
典型的节点订阅会先把多条分享链接按行拼接,再对整段文本做 Base64 编码。个别协议的分享链接内部还会使用 Base64,因此可能存在外层订阅编码与内层协议编码两层结构。一次解码后看见 vmess:// 或 ss://,不代表节点参数已经全部展开。
分享链接中的常见字段
- 连接身份:服务器、端口、密码或 UUID,以及协议所需的加密方式。
- 传输信息:TLS、SNI、WebSocket 路径与 Host、gRPC 服务名等;是否存在取决于协议和分享格式。
- 显示信息:节点备注常在 URI 片段中,经百分号编码后保存。
例如,两个节点都连接 443 端口,一个使用普通 TLS,另一个还要求特定的 WebSocket 路径。转换器如果只留下服务器、端口和密码,第二个节点就可能握手失败。端口相同并不代表连接参数相同,443 也不能单独作为启用 TLS 的依据。
节点分享链接通常不包含完整的 DNS 策略、规则顺序、TUN 路由和自动策略组。把这类订阅转成 Clash 配置时,转换器往往会另外套用模板。因此,新配置中出现的“自动选择”“地区分组”可能来自模板,而不是原订阅。
安全查看内容
优先使用可信客户端的配置预览或本地编辑器检查响应。若需要解码,应使用本地工具并避免把完整内容写入公开终端记录。解码后得到的密码、UUID 和订阅令牌仍然是敏感信息,排查问题时只提供去除凭据的结构与错误行号。
三、完整 YAML 与节点提供者的边界
YAML 是数据表达方式,不代表文件必然完整。Clash 系列配置通常通过 proxies 定义节点,通过 proxy-groups 组织选择方式,再用 rules 决定连接去向。下面的教学配置展示三者的引用关系;示例域名和密码不能用于实际连接。
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
proxies:
- name: 示例节点
type: trojan
server: edge.example.com
port: 443
password: example-password
sni: edge.example.com
skip-cert-verify: false
proxy-groups:
- name: 手动选择
type: select
proxies:
- 示例节点
- DIRECT
rules:
- DOMAIN-SUFFIX,example.org,DIRECT
- MATCH,手动选择
这里的 7890 是本机 HTTP/SOCKS 混合代理监听端口,不是远端节点端口。最后一条 MATCH 将前面未命中的连接交给“手动选择”。如果转换时改变了组名,却没有同步修改规则引用,配置可能加载失败。
proxy-providers 需要主配置
代理提供者把节点更新与主配置拆开。对于 mihomo 的常规 YAML 提供者文件,顶层通常是 proxies:;主配置在 proxy-providers 中声明它,再由策略组的 use 引用。只有节点列表的文件,不等同于已经具备规则和策略组的主配置。
某些客户端可以为纯节点内容自动补充默认分组,但这是导入器的功能,不能据此推断所有客户端都支持。选择远程配置时,应先确认入口要求“完整配置”还是“节点提供者”。需要保留自定义规则时,可考虑主配置加提供者,或使用客户端支持的覆写机制,而不是反复手改会被订阅刷新覆盖的文件。
四、订阅转换时容易丢失的字段
转换通常经历“解析源内容 → 生成中间节点数据 → 按目标格式输出”。任何一个阶段不认识的字段,都可能被忽略、改名或替换为默认值。能生成 YAML 只说明输出了文本,不等于目标内核能够按原参数连接。
| 检查对象 | 常见变化 | 验证方法 |
|---|---|---|
| TLS 与传输参数 | SNI、ALPN、WS Host 或路径遗漏 | 逐项对照原始节点,不用关闭证书验证代替修正 |
| 新协议与扩展 | 转换器不能识别,或目标内核不支持 | 同时核对源解析器、输出目标与运行内核 |
| 策略组与规则 | 被目标模板重建,组名和顺序改变 | 检查规则目标是否存在,MATCH 是否位于预期位置 |
| DNS 与 TUN | 来源配置的运行设置未带入 | 检查最终生效配置,不只查看订阅原文 |
| 订阅附加信息 | 流量、到期时间等响应头信息未传递 | 区分面板显示信息与节点连接参数 |
Clash、Clash Premium 与 Clash Meta(现称 mihomo)的字段支持范围并不完全相同。转换器中的“Clash”目标也可能是兼容旧内核的输出;使用 mihomo 时,应选择明确支持所需协议和字段的输出目标。不能靠文件名包含 Meta 就判断兼容,也不宜仅凭图形客户端版本推断内核能力。
五、按顺序完成订阅转换与导入
- 优先选择原生输出。服务商若已提供适配当前内核的 Clash 或 mihomo 配置,先直接使用,减少中间解析步骤。不要对一份正常的 YAML 再套一层转换。
- 确认下载结果。检查返回的是节点文本、YAML,还是登录页、错误页。HTTP 返回成功并不保证响应就是配置;以
<!DOCTYPE html>开头的内容通常不能作为订阅加载。 - 选择可信转换环境。必须转换时,优先考虑本地运行的工具或可信服务商提供的转换入口。在线转换服务可能接触原始订阅令牌及节点凭据。
- 明确目标内核与模板。先确认所需协议能够输出,再选择规则模板;若只需要节点集合,应确认输出是否适用于代理提供者,而不是直接替换主配置。
- 使用新配置测试。保留现有可用配置,把转换结果作为独立配置导入。先查看配置检查结果,再启动内核;出现错误时依据日志定位,不直接覆盖唯一可用文件。
- 核对最终生效内容。客户端可能应用全局覆写、合并或脚本处理。应检查处理后的组名、规则、DNS 与端口,而不是只看下载到的原始 YAML。
转换 URL 中的源订阅地址通常需要作为参数编码。源地址本身若带有 & 或 #,直接拼接可能把令牌截断,或把部分内容变成另一个参数。应使用工具提供的输入框或标准 URL 编码功能,不要手工反复编码整条地址,也不要把生成地址贴到公共讨论区。
六、导入成功后的四项检查
1. 节点数量与关键参数
假设源订阅有 12 个节点,而转换结果只有 9 个,应先检查协议支持、地区筛选与去重设置。再抽查至少一个可用节点的服务器、远端端口、SNI 和传输参数。数量一致也不能证明字段完整,重命名还可能影响按名称筛选的规则。
2. 配置语法与引用
YAML 层级使用空格,不用 Tab。遇到 proxy not found 一类错误时,检查组内引用和规则目标;遇到解析错误时,从日志标出的行号及其上一行开始检查缩进、冒号和引号。节点名含特殊字符时,使用正确的 YAML 引号能减少歧义。
3. 延迟、实际请求与规则命中
延迟测试成功只表示该测试请求得到响应,不代表所有站点都能访问。先使用系统代理验证浏览器请求,再查看连接面板中的规则、策略组和最终节点。确认基础链路正常后,若需要接管不遵循系统代理的应用,再配置 TUN,避免把路由、DNS 与格式问题混在一起。
4. 订阅刷新是否覆盖修改
手动更新一次订阅,检查自定义规则是否仍在、节点提供者是否更新、策略组是否还能选中节点。HTTP 提供者的 interval: 3600 表示按秒设置更新间隔,即 1 小时;图形客户端的订阅刷新周期可能是另一套设置,不应把它与节点健康检查间隔混为一谈。
七、格式选型与常见问题
为什么 Base64 解码后仍无法直接导入?
解码只还原内容,不负责组装 Clash 配置。得到节点 URI 列表后,需要客户端支持分享链接导入,或转换成目标内核可读取的节点定义。把文本扩展名改成 .yaml 不会改变其内部结构。
其他客户端的 JSON 能直接转成 Clash 吗?
要看转换器是否支持那一种具体结构。比如 sing-box 的 JSON 不仅描述出站,还可能包含其自身的 DNS 和路由逻辑;即使节点参数能够转换,路由语义也未必能一对一迁移。应将节点迁移与规则重建分别检查,不能把“支持 JSON”理解成支持任意客户端配置。
长期使用选完整配置还是节点提供者?
希望按服务商预设规则直接使用时,原生完整配置更省步骤;需要长期维护自定义分流时,主配置配合节点提供者通常更便于隔离更新。只有 Base64 节点订阅时,再考虑一次明确目标的转换。无论采用哪种方式,都应保留原始入口,核对内核支持范围,并以实际连接和规则命中作为最终验证。