client/subscription · 集群 A · 订阅原理与格式 · 3/6

订阅转换是什么：原理、适用场景与使用前要想清楚的问题

订阅转换在做什么

订阅转换就是“代替客户端拉订阅，再改写成另一种格式”，它本质上是一个中间人程序，位于客户端和服务商订阅接口之间。

没有转换：
  客户端 ──请求──> 服务商订阅接口 ──返回原始格式──> 客户端

使用转换：
  客户端 ──请求转换链接──> 转换后端 ──请求原订阅──> 服务商订阅接口
                              │ <──返回原始格式──
                              │ 解析节点 → 套用规则模板 → 渲染目标格式
  客户端 <──返回目标格式────────┘

注意转换链接里通常会包含经过 URL 编码的原始订阅地址，也就是说，原订阅的令牌被完整交给了转换后端。这是理解订阅转换隐私风险的出发点，相关分析见 第三方订阅转换服务有哪些隐私风险。

转换后端内部的四个步骤

一个典型转换后端的处理流程可以拆为“拉取、解析、编排、渲染”四步，每一步都可能成为故障点。

其中“解析”环节最容易被忽视：如果转换后端版本较旧，而原订阅里有较新的协议类型，这些节点可能被静默丢弃，你在客户端看到的节点数就会比服务商后台少。对比后台节点数与客户端节点数，是判断转换是否“吃掉”节点的简单方法。

什么时候需要转换，什么时候不需要

需要转换的前提是“服务商没提供你要的格式”或“你要的规则服务商没给”，其他情况下增加转换环节只会多一个故障点和一个隐私暴露面。

是否需要订阅转换？
 ├─ 服务商后台是否提供你客户端的专用链接？
 │    ├─ 是 → 直接使用，无需转换
 │    └─ 否 ↓
 ├─ 你的客户端能否直接读取现有格式？
 │    ├─ 能 → 无需转换，规则用客户端覆写功能补充
 │    └─ 不能 ↓
 ├─ 能否在本机或自己可控的设备上运行转换？
 │    ├─ 能 → 本地转换（优先）
 │    └─ 不能 → 评估第三方转换的风险后再决定

很多人习惯“拿到订阅先转换一下”，其实现代 Clash 系客户端大多支持覆写、合并或脚本扩展，规则定制完全可以在本地完成，不必把原订阅交给任何人。

规则模板怎么理解

规则模板是一份预先写好的“分组 + 分流”方案，转换后端把节点填进去，就生成了一份完整配置。

一个常见模板大致包含：

• 节点选择组：手动切换节点的总入口。
• 自动测速组：定期测试延迟，选择较低延迟的节点。
• 地区分组：按节点名称中的地区关键词（如“香港”“日本”）筛选节点。
• 场景分组：为特定类型的流量单独指定出口。
• 直连与兜底规则：国内常见域名与局域网地址直连，未匹配流量走默认组。

地区分组依赖节点命名。如果服务商的节点命名不含模板预期的关键词，这些分组就会为空或只剩兜底选项。这不是订阅坏了，而是模板的筛选规则与命名不匹配，需要调整模板中的匹配关键词。节点命名方式本身的含义可参考 节点与 IP 专题。

使用转换前的检查清单

转换前先确认四件事：必要性、转换位置、更新链路、回退方案。

最后一项尤其重要：如果过去曾把订阅交给过来源不明的转换服务，稳妥的做法是在服务商后台重置订阅链接，旧令牌作废后再在可控环境里重新转换，操作方法见 如何重置机场订阅链接。

订阅转换与客户端覆写的分工

很多原本通过转换实现的需求，用客户端的覆写功能完成会更简单、更安全。两者的分工可以这样理解：转换负责“格式翻译”，覆写负责“在已有配置上做加减”。

判断时可以先问自己：我需要的是“让客户端读懂”，还是“在能读懂的基础上改一改”？如果是后者，覆写几乎总是更好的选择，桌面端的覆写入口可以参考 桌面客户端 专题。

小结

订阅转换解决的是格式与规则问题，不改变节点质量，代价是多一个环节和一个能看到你订阅的第三方。能用服务商原生链接就用原生链接，必须转换时优先本地或自建，相关做法见 本地或自建订阅转换。

如果你还没有确定服务商，可以先在 机场品牌库 查看各品牌的客户端支持资料，再回到 订阅管理 专题规划自己的订阅方案。