Clash 订阅格式一览:YAML、Base64 分享链接与 sing-box JSON 如何互转

先判断拿到的是哪一种订阅

结论先放在前面：Clash 或 Mihomo 通常需要 YAML 配置，sing-box 使用 JSON 配置，而一串看似乱码的订阅内容往往只是经过 Base64 编码的分享链接集合。三者表达的信息有交集，但不是改扩展名就能互换。

订阅链接只是获取内容的地址，不等于内容格式。服务器可以在同一个以 https:// 开头的地址后，根据客户端参数返回 Clash YAML、通用分享链接或 sing-box JSON。判断时应查看响应正文，而不是只看网址后缀。

用开头几个字符快速识别

看到的内容	大概率格式	下一步
`proxies:`、`proxy-groups:`	Clash 或 Mihomo YAML	直接导入兼容客户端，并检查配置字段
`dm1lc3M6Ly8`、连续字母数字与等号	Base64 编码文本	先解码，再检查是否为多行分享链接
`ss://`、`trojan://`、`vless://`	单条或多条 URI 分享链接	交给转换器生成目标配置
`{"log":`、`"outbounds"`	sing-box JSON	使用 sing-box 校验，不要直接导入 Clash
网页 HTML、登录提示或错误说明	订阅请求失败	检查地址、有效期和请求参数

先用文本方式读取，不要直接双击执行

可以用浏览器开发者工具的“网络”面板查看响应，也可以把内容保存为纯文本。命令行用户可使用 curl，并限制输出文件名，避免终端被长内容刷满。

curl -L --max-time 20 "https://sub.example.net/api/demo-token" -o subscription.txt
head -n 8 subscription.txt

-L 用于跟随重定向，--max-time 20 将整个请求限制在 20 秒内。若文件第一行出现 <!doctype html>，拿到的是网页而不是订阅配置，应先处理登录、地址失效或网关拦截问题。

YAML、Base64 与 sing-box JSON 的结构差异

格式转换的难点不在语法，而在模型。节点地址、端口和认证信息比较容易映射；策略组、规则集、DNS 行为、TUN 路由和脚本扩展则可能只存在于某一种内核中。转换器能改写结构，却不能自动理解每一条规则的真实意图。

Clash 与 Mihomo YAML

YAML 配置通常同时容纳节点、策略组和分流规则。Mihomo 是延续 Clash 配置生态的开源代理内核，支持较多协议与扩展字段。一个最小化示例如下：

mixed-port: 7890
mode: rule
allow-lan: false

proxies:
  - name: HK-01
    type: ss
    server: edge.example.net
    port: 8388
    cipher: aes-128-gcm
    password: demo-pass

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - HK-01
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.org,PROXY
  - MATCH,PROXY

mixed-port: 7890 表示 HTTP 与 SOCKS 请求共用 7890 端口。proxy-groups 定义可在客户端中选择的策略，rules 从上到下匹配流量。只有节点列表而没有策略组和规则时，部分客户端可以自动补全，另一些客户端会提示配置不可用。

Base64 分享链接集合

Base64 不是代理协议，也不是完整配置格式。它只是把字节编码成便于传输的文本。常见订阅将多行 ss://、trojan://、vmess:// 或 vless:// 链接拼接后，再对整体做一次 Base64 编码。

ss://[email protected]:8388#HK-01
trojan://[email protected]:443?security=tls#SG-01

这类内容通常只携带节点参数和显示名称，不包含 Clash 的完整规则。转换为 YAML 时，转换工具往往会按模板补充 proxy-groups、rules 和 DNS 设置，因此相同节点经过不同模板后，最终行为可能完全不同。

sing-box JSON

sing-box 使用 JSON 描述入站、出站、路由和 DNS。以 sing-box 1.12 配置结构为例，节点通常放在 outbounds 数组中，选择器也是一种出站对象：

{
  "log": {
    "level": "info"
  },
  "outbounds": [
    {
      "type": "shadowsocks",
      "tag": "hk-01",
      "server": "edge.example.net",
      "server_port": 8388,
      "method": "aes-128-gcm",
      "password": "demo-pass"
    },
    {
      "type": "selector",
      "tag": "proxy",
      "outbounds": [
        "hk-01"
      ]
    }
  ],
  "route": {
    "rules": [
      {
        "action": "route",
        "domain_suffix": [
          "example.org"
        ],
        "outbound": "proxy"
      }
    ],
    "final": "proxy"
  }
}

Clash 的 proxy-groups 与 sing-box 的 selector、urltest 可以做近似映射，但字段名和执行模型不同。Clash 的 MATCH 通常对应 sing-box 路由中的最终出站，而不是简单复制成一条同名规则。

先解码 Base64，再决定转换目标

不要看到长字符串就直接交给转换器。先在本机解码并检查前几行，可以确认内容是否完整，也能避免把错误页、压缩数据或二次编码内容误判为节点订阅。

Windows PowerShell 解码

$raw = (Get-Content .\subscription.txt -Raw).Trim()
$bytes = [Convert]::FromBase64String($raw)
[Text.Encoding]::UTF8.GetString($bytes) |
  Set-Content .\decoded.txt -Encoding utf8
Get-Content .\decoded.txt -TotalCount 8

若 FromBase64String 报格式错误，先检查文本中是否混入空格、网页标签或 URL 安全型字符。URL 安全型 Base64 可能使用短横线和下划线代替加号和斜杠，且末尾省略等号，需要由支持该变体的工具处理。

Linux 与 macOS 解码

# GNU/Linux
base64 -d subscription.txt > decoded.txt

# macOS
base64 -D subscription.txt > decoded.txt

sed -n '1,8p' decoded.txt

解码结果若仍是一整段 Base64，可能存在二次编码，但也可能是 VMess 链接内部的 JSON 编码。此时应先观察前缀：整份订阅二次编码可以继续解码，vmess:// 后面的部分则属于单个节点，不应把整行前缀一起送给普通 Base64 命令。

用开源转换工具生成 Clash YAML

当来源是 URI 列表或 Base64 订阅，而目标客户端运行 Mihomo 时，可使用支持 Clash 输出的开源订阅转换器。常见实现会提供一个 /sub 接口，接收来源地址、目标类型和规则模板，再返回 YAML。

转换前确认三个参数

目标类型：选择 Clash 或明确标注 Mihomo、Clash Meta 的输出。旧版 Clash 目标可能移除较新的协议字段。
来源地址：必须进行 URL 编码，尤其是地址本身带有 ?、& 或等号时。
规则模板：节点转换和规则生成是两件事。第一次测试宜使用简单模板，确认节点可连接后再加入远程规则集。

假设本地转换服务监听 127.0.0.1:25500，来源地址编码后可按下面的形式请求 Clash 输出：

curl "http://127.0.0.1:25500/sub?target=clash&url=https%3A%2F%2Fsub.example.net%2Fapi%2Fdemo-token" \
  -o converted.yaml

不同项目和分支支持的 target 名称并不一致。部分版本支持 clash，部分扩展版本还提供 Mihomo 或 sing-box 目标。应查看当前构建的目标列表，不要凭接口名称猜测。若工具没有 sing-box 输出能力，应换用具备对应适配器的实现，而不是把 YAML 直接改成 .json。

导入前做语法检查

Mihomo 可在命令行中检查配置。假设可执行文件名为 mihomo，配置文件为当前目录的 converted.yaml：

mihomo -t -f ./converted.yaml

测试通过只表示配置可解析，不代表所有节点都能连接。接着应启动客户端，进入「订阅」或「配置」页面加载文件，再到「代理」页面检查策略组中是否出现节点。最后打开「设置」→「系统代理」，确认 HTTP 与 SOCKS 使用的端口与配置一致，例如都指向混合端口 7890。

本地自托管转换服务的稳妥流程

订阅地址通常包含访问凭据。需要频繁转换时，适合把开源转换程序运行在本机或受控服务器中，使来源地址只在自己的设备与订阅服务器之间传递。自托管还便于固定版本和规则模板，减少同一订阅在不同日期产生不同结果。

本机运行时的基本设置

从项目发布记录获取与操作系统、CPU 架构匹配的构建，例如 Windows x64、Linux amd64 或 macOS arm64。
将程序和配置文件放入独立目录，首次启动只监听 127.0.0.1，不要直接绑定到公网网卡。
确认监听端口，例如 25500，再用浏览器或 curl访问本地接口。
把规则模板保存在本地，并记录转换程序版本、模板版本和输出时间。
先用一个节点测试，确认字段映射正确后再处理完整订阅。

如果转换服务必须放在局域网服务器上，应限制来源地址，并在反向代理层增加访问控制。转换接口通常允许调用者提交任意订阅网址；缺少限制时，不仅会暴露订阅内容，也可能让服务端替他人请求内部网络地址。

固定输入与输出，便于回滚

建议保留三份文件：原始响应 source.txt、转换输出 converted.yaml 或 config.json、以及记录版本和参数的 conversion-notes.txt。例如记录监听端口 25500、目标 clash、模板文件名和转换日期。下次节点数量异常时，可以快速比较是来源变化、模板变化还是工具升级造成的。

从 Clash YAML 转到 sing-box JSON 时如何映射

YAML 转 JSON 不是单纯的语法转换。通用 YAML 转 JSON 工具只能把缩进结构改成大括号结构，无法把 Clash 的 proxies 变成 sing-box 的 outbounds，也无法理解策略组和路由规则。必须使用了解两种代理配置模型的转换器。

主要字段对应关系

Clash / Mihomo	sing-box	转换注意点
`proxies[].name`	`outbounds[].tag`	tag 必须唯一，名称重复时要重命名
`server`、`port`	`server`、`server_port`	端口字段名称不同
`proxy-groups` 的 select	`selector` outbound	成员名称要改为对应 tag
`url-test`	`urltest` outbound	测试地址、间隔和容差需重新核对
`rules`	`route.rules`	规则类型和最终出站不能机械复制
`dns`	`dns` 与路由配合	解析器标签、分流条件和缓存行为不同
`tun`	`inbounds` 中的 tun	接口地址、自动路由和严格路由需重设

协议字段也可能存在差异。例如 TLS 的服务器名称、ALPN、Reality 参数、WebSocket 路径与请求头，在两套配置中嵌套位置不同。转换后若节点显示存在但握手失败，应优先比对这些字段，而不是反复更换本地端口。

规则无法完整映射时的处理顺序

先只转换一个节点，并把最终路由设为该节点，验证协议参数。
加入一个手动选择器，确认节点 tag 与选择器成员一致。
加入局域网和常用直连规则，验证本地设备访问不受影响。
再导入域名、IP 和规则集，观察日志中实际命中的规则。
最后启用 TUN 与复杂 DNS 分流，避免同时排查多个变量。

转换后必须复核的十个字段

转换完成后不要立即覆盖正在使用的配置。先另存文件并逐项检查。以下项目比“文件能否导入”更重要。

节点数量：来源有 36 个节点，输出不应只剩 3 个。数量减少时检查协议是否被目标格式或转换器过滤。
节点名称：名称必须唯一。重名可能导致策略组只引用其中一个节点。
服务器与端口：确认 server 没被写成订阅服务器地址，并核对 443、8443、8388 等实际端口。
认证信息：检查密码、UUID、密钥及其大小写，留意 URL 解码是否把加号误处理为空格。
TLS 参数：核对服务器名称、是否跳过证书验证、ALPN 和 Reality 公钥等字段。
传输参数：WebSocket 路径应保留开头的斜杠，gRPC service name 与 HTTP Host 不能互换。
策略组成员：手动选择、自动测速和故障转移组内必须存在有效节点，不能只剩组名。
规则顺序：规则按顺序匹配。局域网直连通常应放在最终兜底规则之前。
DNS 行为：检查监听地址、上游服务器、代理解析与直连解析的分工，避免出现解析循环。
本地端口：配置改为 7891 后，Windows 11 的「设置」→「网络和 Internet」→「代理」也要同步修改，旧的 7890 不会自动跟随。

用最短链路验证结果

先关闭 TUN，只启用系统代理和一个手动节点。访问出口 IP 查询页面，再用命令行通过混合端口请求一个 HTTPS 地址：

curl -x http://127.0.0.1:7890 --connect-timeout 8 https://example.com/

若返回正常，再测试规则模式、自动测速和 TUN。自动测速显示 80 毫秒，只说明探测地址往返较快，不等于所有网站都能稳定访问。实际验证还要观察 DNS、TLS 握手和下载过程。

常见问题

把 YAML 后缀改成 JSON，sing-box 能读取吗？

不能。扩展名不改变内部数据模型。即使先用通用工具把 YAML 语法转成 JSON，里面仍然是 Clash 的 proxies、proxy-groups 和 rules，sing-box 不会把它们自动解释成出站和路由。

为什么 Base64 解码后只有节点，没有规则？

通用 URI 订阅主要负责传递节点参数，本身通常不含 Clash 策略组与分流规则。生成 YAML 时需要选择规则模板，或者在转换结果中自行维护策略组和规则。

转换后的订阅还能自动更新吗？

取决于导入方式。本地导出的静态文件不会自动更新；客户端保存的是转换接口地址时，可以按更新间隔重新请求。应保留原始地址，并确认转换服务长期可用。

Mihomo 配置是否可以直接用于旧版 Clash？

基础字段可能兼容，但 Mihomo 扩展协议、规则集、DNS 与 TUN 字段不一定被旧内核识别。目标客户端使用旧内核时，应选择对应输出类型，并通过该内核自己的配置检查命令验证。

转换后延迟全部显示超时，应先查什么？

先检查测速地址是否可访问，再确认策略组确实包含节点。若手动连接也失败，比较服务器、端口、TLS 服务器名称和传输路径；若手动连接正常，通常是测速 URL、间隔或并发设置的问题。

格式选择建议

目标是 Mihomo 客户端时，优先使用服务端直接提供的 Clash 或 Mihomo YAML；目标是 sing-box 时，优先获取针对当前 sing-box 配置结构生成的 JSON。只有来源不提供目标格式时，再引入转换层。

Base64 URI 订阅适合作为通用节点来源，但它不负责完整分流。长期使用时，应把节点转换与规则模板分开管理：节点按订阅更新，规则由自己选定的配置维护。这样出现问题时，可以明确判断是节点参数变化，还是路由与 DNS 设置变化。

最后保留一条简单原则：先验证单节点，再加策略组；先验证系统代理，再开 TUN；先确认语法，再检查网络。格式转换涉及的变量越少，定位错误越快。