Clash 订阅格式详解：配置类型识别、兼容差异与转换原则
辨别 Clash、Mihomo 与通用节点订阅的结构差异，并说明转换前应检查的字段和规则。
订阅、配置与编码不是同一层
排查 Clash 订阅问题时，第一步不是寻找转换工具，而是分清链接、响应内容和客户端配置之间的关系。订阅链接只是一个获取入口。客户端请求这个地址后，服务器可能返回完整 YAML 配置、仅含节点的 YAML、逐行排列的分享链接，也可能返回经过 Base64 编码的文本。链接末尾是否带有文件扩展名，通常不能准确说明响应类型。
完整 Clash 配置描述的是一条可执行的流量处理路径。它除了节点，还可能包含监听端口、代理组、规则、规则集合、DNS、TUN、嗅探和配置提供器等部分。节点订阅只解决“有哪些代理入口”，不能独立决定域名应进入哪个策略组，也不能代替本机的 DNS 与网络接管设置。
常见内容可以分成以下四类：
- 完整配置：通常能看到
proxies、proxy-groups和rules。导入后可以直接形成规则模式的基本执行链。 - 节点提供器配置：常见主体是一个
proxies数组，用于被主配置中的proxy-providers引用，未必能作为完整配置独立运行。 - 通用分享链接列表：每行是一个协议链接，例如
ss://、trojan://或vmess://。是否能直接导入取决于客户端的订阅解析能力。 - 编码后的文本：Base64 只是文本传输方式。解码后仍要继续判断它是链接列表、YAML、JSON，还是服务端返回的错误页面。
从响应内容识别配置类型
判断格式时应查看订阅请求实际返回的正文，而不是只看网页中的说明。可以使用浏览器开发者工具、客户端更新日志，或能够显示响应头与正文的命令行工具。若订阅需要认证，应避免把完整地址粘贴到公开日志、截图或在线分析页面，因为查询参数中可能包含长期有效的访问凭据。
先确认返回的是配置而不是网页
订阅地址失效、认证过期或访问频率受限时，服务器可能返回 HTML 登录页、错误页或验证页面。正文开头若出现 <!doctype html>、<html>，就不应继续按 YAML 解析。HTTP 状态为成功也不能单独证明正文是有效配置，有些服务会用普通网页展示错误说明。
检查 YAML 的顶层字段
一个结构较完整的 Clash 配置可能包含如下骨架。具体字段会随内核和需求变化，但代理组引用与规则目标必须能够闭合：
mixed-port: 7890
mode: rule
log-level: info
proxies:
- name: Tokyo-01
type: trojan
server: edge.example.invalid
port: 443
password: example-password
sni: edge.example.invalid
proxy-groups:
- name: PROXY
type: select
proxies:
- Tokyo-01
- DIRECT
rules:
- DOMAIN-SUFFIX,example.org,PROXY
- MATCH,DIRECTproxies 中定义节点，proxy-groups 将节点或其他策略组组织成可选择的策略，rules 的最后一段则引用策略组、节点名或内置动作。若规则写向 PROXY，配置里就必须存在同名策略组或可用目标。名称区分字符与空格，转换时随意改名会导致引用断开。
识别链接列表和编码内容
逐行文本如果在解码后大量出现协议前缀，通常属于节点链接订阅。链接中携带服务器、端口、认证信息和部分传输参数，但一般不包含完整规则体系。某些链接会把显示名称放在片段标识中；如果解析器对百分号编码或字符集处理不同，导入后可能出现节点名称乱码或重名。
不能仅凭“文本看起来像一串随机字符”就确定它是 Base64。先排除压缩数据、JSON、HTML 和服务端提示，再使用与字符集匹配的解码方式。解码完成后仍需重新执行格式识别，不能把解码成功等同于配置可用。
| 观察到的特征 | 可能类型 | 下一步 |
|---|---|---|
| 同时出现 proxies、proxy-groups、rules | 完整 Clash 或 Mihomo YAML | 检查内核字段兼容性与引用关系 |
| 只有 proxies 数组 | 节点提供器内容 | 由主配置通过 provider 引用，或补齐策略与规则 |
| 每行以协议链接开头 | 通用节点订阅 | 使用支持对应协议的解析器生成节点项 |
| 正文以 HTML 标签开头 | 登录页或错误页 | 检查地址、认证、状态码和重定向 |
| 解码后才出现 YAML 或链接 | 编码包装的订阅 | 以解码后的真实内容继续判断 |
Clash、Clash Meta 与 Mihomo 的兼容边界
“Clash 格式”并不是一个永远固定的单一版本。早期 Clash 内核建立了常用 YAML 结构，Clash Meta 在此基础上扩展了协议、规则、DNS、TUN 和路由能力，后续项目名称使用 Mihomo。现在许多客户端以 Mihomo 作为内核，但界面或订阅提供方仍沿用 Clash 这一通用称呼。
兼容关系通常是新内核能读取较多传统字段，但这不表示任意 Mihomo 配置都能反向交给旧内核。配置中只要使用了旧内核不认识的代理类型、传输参数、规则语法或 DNS 选项，启动时就可能报字段错误，也可能忽略部分设置。转换目标必须指向实际运行的内核，而不是只依据客户端名称判断。
代理协议与传输参数
节点能否使用取决于内核是否实现对应协议及其参数组合。即使两个订阅都包含同名协议，TLS 指纹、Reality、HTTP/2、gRPC、QUIC 或其他扩展参数的字段名称和支持范围也可能不同。转换器若不认识某个字段，常见结果不是“自动兼容”，而是删掉该字段或降级成无法连接的节点。
规则提供器的行为类型
rule-providers 不只是远程文件地址，还包括 behavior、格式、更新间隔与存储路径。常见行为有 domain、ipcidr 和 classical。域名集合不能直接当作 IP 网段集合使用，经典规则集合则可以承载带类型前缀的规则条目。主规则中的 RULE-SET 引用必须与提供器名称一致。
DNS 与 TUN 属于本机执行环境
DNS 和 TUN 配置与操作系统、权限、网络接口及客户端实现紧密相关。节点订阅中的服务器信息可以跨设备迁移，但整段复制 TUN 接口名、路由排除项、DNS 监听地址或系统代理设置，往往会把来源设备的假设带到目标设备。桌面系统可用的配置不一定适合服务器，Android 客户端也可能由界面接管 VPN 权限而忽略部分桌面字段。
订阅转换前要检查的六项内容
转换的目标应当是把来源数据映射到目标内核可理解的结构，而不是把所有内容压缩成一个“能导入”的文件。开始转换前，至少检查以下六项。
- 确认目标内核。记录客户端使用的是 Mihomo、传统 Clash 兼容内核，还是具有自有解析层的移动客户端。相同订阅在不同客户端中的导入结果可能不同。
- 确认来源范围。判断来源是完整配置、节点集合还是单个分享链接。节点集合转换后通常仍需主配置提供策略组、规则和 DNS。
- 列出协议与关键字段。检查每种节点类型的认证、TLS、SNI、传输方式、UDP 支持及扩展参数。转换后应抽样对照，而不是只比较节点数量。
- 检查名称引用。代理组可以引用节点和其他代理组，规则会引用策略目标。重命名、去重或字符规范化必须同步更新全部引用。
- 检查规则语义。规则顺序会影响结果，因为 Clash 按配置顺序自上而下匹配，命中后停止。转换时重新排序规则可能改变流量路径。
- 划分远程与本地设置。节点和远程规则可以按计划更新；端口、控制接口、DNS、TUN、局域网监听和认证通常更适合由本机模板维护。
为什么节点数量相同仍可能转换失败
节点数量只能证明解析器创建了相同数量的条目，不能证明每个条目的参数完整。转换器可能保留服务器与端口，却遗漏 SNI、传输路径或协议扩展；也可能把两个同名节点自动加后缀，导致原有策略组仍引用旧名称。验证时应选择不同协议的节点分别检查，并查看连接日志中的握手阶段错误。
为什么规则不能只做文本拼接
两份规则列表直接首尾拼接，可能产生顺序冲突。例如前部的广泛域名规则会提前命中，使后面的精确规则失去作用；IP 规则还可能触发 DNS 解析，具体行为受规则类型和参数影响。合并时应先确定优先级：本机例外规则通常放在更具体的位置，广泛规则和最终兜底规则靠后，且整个配置只保留清晰可控的最终去向。
在线转换服务的凭据边界
订阅地址通常具备读取节点配置的权限。把完整地址提交给第三方转换服务，等同于让该服务获得订阅响应的访问能力。更稳妥的做法是在可信环境中使用本地转换流程，或使用订阅提供方明确给出的目标格式。若必须经过中间服务，应了解其请求方式、日志策略和缓存行为，并在处理后按提供方能力更新访问凭据。
建立可验证、可回退的转换流程
稳定的转换流程应把远程节点、本地主配置和生成结果分开保存。这样订阅更新时只替换数据源，不会覆盖已经验证过的 DNS、TUN 与规则结构。
步骤一：固定来源快照
保存一次原始响应，记录获取时间、响应类型与使用的目标内核。快照用于排除“订阅源在排查期间发生变化”的干扰。保存时应限制文件访问权限，因为其中可能包含节点认证信息。
步骤二：解析而不改写
先让解析器输出结构化结果，查看识别出的协议、节点名称和字段。此阶段不添加规则，也不做批量重命名。若某类节点无法识别，应先解决来源与目标的协议兼容问题，避免在后续模板中掩盖错误。
步骤三：映射到本地主配置
将节点作为 proxy-providers 或明确的 proxies 数据接入主配置，再由本地主配置定义策略组。使用提供器时，可以让策略组通过 use 引用节点集合，从而减少每次订阅变化后手工改动组内列表的工作。
proxy-providers:
remote-set:
type: http
url: https://config.example.invalid/profile.yaml
interval: 21600
path: ./providers/remote-set.yaml
health-check:
enable: true
interval: 600
url: https://www.gstatic.com/generate_204
proxy-groups:
- name: PROXY
type: select
use:
- remote-set
proxies:
- DIRECT示例用于说明结构关系。实际使用时，提供器返回内容必须符合目标内核要求；健康检查地址、更新间隔与存储路径也应按网络环境调整。若订阅源只返回完整配置而不是提供器格式，不能仅把地址放入 proxy-providers 就期待内核自动提取节点。
步骤四：做三层验证
- 语法层：确认 YAML 缩进、列表层级、引号和字段类型正确。包含冒号、井号或特殊字符的名称适合使用引号包裹。
- 引用层：确认代理组引用的节点或提供器存在，规则目标存在，规则集合名称与提供器一致。
- 运行层：启动后查看配置加载、提供器更新、DNS 查询、节点握手和规则匹配日志，分别测试直连与代理流量。
步骤五：逐项启用 DNS 与 TUN
先在普通系统代理或明确的代理端口下验证节点与规则，再启用复杂 DNS 设置，最后按需测试 TUN。一次同时修改节点格式、DNS 和 TUN，会让连接失败难以归因。每次只增加一组变量，并保留上一份可启动配置。
导入失败与节点缺失的排查顺序
订阅更新提示解析错误
先查看错误发生在下载阶段还是 YAML 解析阶段。下载阶段重点检查状态码、重定向、认证和响应正文；解析阶段重点查看具体行号附近的缩进、冒号、列表符号和字符编码。YAML 使用空格表达层级，制表符或错位缩进都可能让整个文件无法加载。
导入后没有节点
确认响应是否真的是节点集合。如果文件只有 proxy-providers 定义，它描述的是如何继续获取节点，不代表当前文件内已经存在 proxies。如果文件只有规则集合，则本来就不会生成节点。还应查看客户端是否把完整配置导入功能和单独的节点订阅功能分成两个入口。
节点存在但策略组为空
静态策略组的 proxies 列表需要写入节点名称，提供器策略组则需要通过 use 引用对应提供器。若转换器改了节点名而未更新组内引用，客户端可能报告目标不存在。正则筛选型策略组还要检查过滤表达式，过于严格的筛选会排除全部节点。
配置能启动但所有连接失败
先绕开复杂规则，直接选择一个节点进行连通测试。检查系统时间、服务器域名解析、端口可达性、TLS 服务器名称和传输参数。若只有特定协议失败，重点对照转换前后的协议扩展字段；若所有节点同时失败，则优先检查订阅是否过期、网络出口、DNS 与系统代理接管状态。
规则模式下流量去向不符合预期
开启规则日志并确认实际命中的规则。不要只根据规则文件中“应该存在”的条目推断结果，因为更靠前的规则可能已经完成匹配。检查规则集合是否更新成功、规则行为类型是否正确、策略目标是否指向预期组，并确认最终兜底规则没有被提前放置。
同一订阅在不同设备结果不同
对比客户端版本、内核名称、内核版本和订阅导入入口。某些客户端会在导入前执行自有转换，另一些则把 YAML 原样交给内核。移动设备还可能限制后台更新、VPN 接管和本地文件访问。应从两端导出实际生效配置或查看启动日志，而不是只比较订阅地址。
Base64 订阅能直接当作 Clash 配置使用吗？
不能只根据编码方式判断。Base64 解码后可能是逐行节点链接，也可能是 YAML 或其他文本。客户端必须同时支持解码后的内容格式和其中使用的协议。
Mihomo 配置可以直接导入旧版 Clash 内核吗？
基础字段可能兼容，但 Mihomo 扩展的协议、规则、DNS 与 TUN 字段不一定被旧内核识别。应按旧内核支持范围删减或映射，并重新验证规则和连接。
订阅转换后需要保留原来的规则吗？
取决于转换目标。若只需要节点数据，可以由本地主配置统一维护规则；若迁移完整配置，则要保留规则顺序、规则集合与策略目标之间的关系，不能只复制规则文本。
为什么订阅更新会覆盖手工修改？
直接编辑下载得到的订阅文件时，下次更新通常会用远程内容重新写入。可把设备相关设置放进独立主配置，通过提供器引用远程节点，或使用客户端支持的覆写机制。
格式识别的最终检查表
订阅转换完成后，可以用一条固定路径复核：确认响应不是网页错误，识别真实内容类型，核对目标内核，抽查协议字段，验证节点与策略组引用，检查规则顺序，再分别测试 DNS 和 TUN。遇到问题时回到最早出现异常的层级，不要反复更换转换工具。
对多数长期使用场景而言，最稳固的结构不是把所有选项塞进远程订阅，而是将更新频繁的节点数据与设备相关的本地设置分离。这样既能持续接收订阅变化，也能保留已经验证的规则链、端口、DNS 和网络接管方案。