Clash 订阅链接格式详解:YAML 配置、Base64 节点串与转换方法

先判断返回内容，再选择导入方式

Clash 订阅链接是获取配置的地址，YAML 或 Base64 才是地址返回的内容格式。能在浏览器打开，不等于能直接导入 Clash 苹果版。优先使用服务商明确标注的 Clash 或 mihomo 订阅；只有通用节点订阅时，再考虑转换。Apple 芯片 Mac 使用 arm64 客户端，不会改变订阅格式要求，iPhone 与 iPad 则还要确认应用支持哪些协议和配置字段。

判断时查看响应正文，不凭链接有没有 .yaml 后缀下结论。同一个地址可能根据查询参数或请求的 User-Agent 返回不同内容；浏览器拿到的页面也可能只是登录页，而不是客户端实际取得的配置。

YAML 配置：节点、策略组与规则各管什么

YAML 是结构化文本，不是把节点逐行罗列就完成配置。Clash 系内核通常使用 proxies 描述代理节点，使用 proxy-groups 组织可选出口，再用 rules 决定连接流向。外部节点集合通过 proxy-providers 引入；外部规则集合通过 rule-providers 声明，并由规则引用。

一份可读的最小结构示例

下面的配置只演示配置层级，所有连接最终直连，不包含远程代理节点。7890 是本例自行指定的混合代理端口，并非所有客户端的默认端口；allow-lan: false 配合回环监听，限制局域网设备使用该入口。

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

proxies: []

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

rules:
  - DOMAIN-SUFFIX,example.com,手动选择
  - MATCH,DIRECT

• proxies：保存节点类型、服务器地址、端口以及认证、TLS 等信息。字段是否可用取决于内核。
• proxy-groups：保存选择策略。规则指向的组名必须存在，节点或组重命名后应同步修改引用。
• rules：通常按从上到下的顺序匹配，前面命中后就使用对应策略；末尾的 MATCH 用于兜底。
• dns 与 tun：分别控制解析与虚拟网络接口行为，不是每份订阅都必须携带，也不应为“完整”而盲目添加。

YAML 缩进使用空格，不要使用制表符。节点名称含 #、冒号后接空格等特殊内容时，使用正确的字符串引号。配置能被 YAML 解析器读取，只能说明语法层面可读；代理类型、字段取值和策略引用还需要内核进一步检查。

Base64 订阅：编码不等于配置，也不等于加密

常见通用订阅会先把多个节点 URI 用换行连接，再对整段文本进行 Base64 编码。解码后得到的可能是 Shadowsocks、VMess、Trojan 等节点描述。不同来源的格式并不完全一致：有的直接返回 URI 列表，有的使用 URL-safe Base64，有的省略末尾填充符，不能只靠“看起来像一长串字母”判断。

在 macOS 本地检查已保存的内容

1. 将需要检查的原始响应保存为本地文本文件，命名为 nodes.b64。不要把登录页面当成订阅正文保存。
2. 在「访达」中打开文件所在目录，再在「终端」中切换到该目录。确认目录不在共享文件夹内。
3. 对标准 Base64 内容执行下面的命令，将结果写入另一个文件，避免覆盖原始响应。

base64 -D < nodes.b64 > nodes.txt

这是 macOS 自带 base64 的解码参数。若命令报错，输出文件可能只有部分内容，不应继续拿它导入。先检查源文件是否已经是明文 URI，或是否使用了 URL-safe 字符及缺省填充；需要兼容处理时，使用明确支持该变体的本地工具，不要随意删除字符。

即使成功解码，也不能据此认定节点有效。Base64 不提供保密能力，解码后的 nodes.txt 可能包含密码、UUID 和服务器信息。检查后应妥善处理原始文件与解码文件，避免通过云盘共享或工单附件扩散。

订阅转换流程与常用参数

转换器的工作链路通常是：获取源订阅、解析节点、筛选和重命名、映射目标协议字段、套用模板、输出配置。它不是内核升级工具，不能让旧内核凭空支持新协议，也不能从节点列表还原服务商没有提供的规则。

先选目标内核，再选输出格式

1. 确认客户端内核。从应用的「关于」或内核信息页面记录内核名称和版本。界面版本与内核版本是两项信息；仅知道应用支持 macOS 或 iOS 不够。
2. 优先使用原生订阅。服务商若同时提供 Clash 与 mihomo 专用入口，选择与目标内核相符的入口，减少中间转换。
3. 确需转换时选择可信环境。优先在本机或自行管理的服务上运行。第三方转换服务通常可以读取源订阅和节点认证信息，HTTPS 只能保护传输过程。
4. 确认输出范围。区分“完整配置”和“仅代理列表”，再决定用配置导入入口还是代理提供者入口。
5. 保留原配置并测试。先新增配置，不直接覆盖正在使用的文件。确认节点数量、策略组、末尾规则与连接日志后再切换。

以常见 subconverter 接口习惯为例

下面是常见参数含义，不是所有转换服务的统一标准。具体可选值必须以所用实例的文档和版本为准，尤其不要假定任意实例都支持名为 mihomo 的输出目标。

源地址如果带有 &，直接拼接到转换请求的 url= 后面，后续内容可能被误读成转换器自身参数。应交给可信工具进行一次正确的参数编码，避免手工拼接或重复编码。转换地址本身也可能包含原始令牌，同样需要按敏感信息处理。

转换后规则丢失：按输出、模板、覆盖顺序排查

“节点能连接，但所有网站走同一个出口”不一定是规则被删除。它可能是只有节点列表、配置没有被激活、当前模式是全局，或者原本的规则被模板替换。把下列检查分开做，比反复更换节点更有效。

第一步：检查转换结果本身

• 搜索顶层 rules: 与 proxy-groups:。只有 proxies: 时，先检查是否开启了仅列表输出。
• 如果规则中使用 RULE-SET，检查对应的 rule-providers 名称是否存在，远程资源是否下载成功。
• 检查规则指向的策略名称是否与策略组完全一致，包括空格、大小写和重命名后的字符。
• 检查兜底规则的位置。过早出现的 MATCH,DIRECT 会让后面的规则没有匹配机会。

第二步：检查转换模板是否替换了上游规则

完整 YAML 经过转换后，输出规则不一定与输入一致。某些转换流程只提取节点，再按自己的模板重建配置。应分别保存转换前后的文本，对比 rules、proxy-groups、dns 和提供者声明；如果上游已经提供适用的完整配置，直接导入往往更容易保留原有语义。

第三步：检查客户端实际运行的配置

确认刚导入的配置已被选中，运行模式为规则模式，而不是全局或直连模式。再检查客户端的覆写、合并、脚本或增强配置功能：这些本地设置可能在订阅下载之后再次改写内容。只修改缓存里的订阅文件，下一次更新时可能被覆盖；需要长期保留的本地调整，应放入客户端明确支持的持久化覆写机制。

最后打开连接记录，对照一个具体域名查看命中规则与最终出口。网站显示的地区、节点延迟数字或页面是否打开，都不能单独证明规则已经生效。如果记录显示规则命中正确，但访问仍异常，再继续检查 DNS、节点可达性和目标服务限制。

Mac、iPhone 与 iPad 导入后的验证清单

苹果设备之间可以共用订阅来源，但不保证每个客户端都支持同一份配置的全部字段。尤其是 mihomo 的扩展协议、规则和 DNS 选项，不能只凭文件扩展名为 YAML 就判断兼容。

1. 核对导入类型。完整配置使用远程配置入口；代理集合使用应用支持的节点或代理提供者入口。菜单名称随客户端变化，不要将规则集 URL 当节点订阅。
2. 核对配置来源。确认订阅地址没有被复制时截断，没有额外的中文标点，也没有过期的访问令牌。遇到 HTTP 401 或 403，先处理授权，不急着改 YAML。
3. 核对监听端口。本例使用 127.0.0.1:7890；实际应用可能使用其他端口。开启系统代理前，检查客户端显示的监听地址，避免把浏览器指向未监听的端口。
4. 分别验证流量接管与分流。macOS 系统代理主要影响遵循代理设置的应用；TUN 通过虚拟接口接收被路由进来的流量。iOS 通常通过系统 VPN 配置接管流量。订阅转换本身不会授予这些权限。
5. 验证一次远程更新。首次导入成功后手动更新一次，确认本地覆写仍然存在，节点筛选没有清空列表，策略引用没有失效。

订阅格式常见问题