先分清订阅地址、节点链接与配置文件
“订阅”不是单一文件格式。用户粘贴到客户端里的通常是一条 HTTPS 地址，客户端请求该地址后，服务器才返回 Base64 文本、Clash YAML、JSON 或其他结构。地址只是获取入口，响应正文的格式才决定客户端能否解析。因此，同一条订阅地址在浏览器里看似只是一串字符，交给不同客户端却可能出现“格式不支持”“配置解析失败”或导入后没有节点。
另一个容易混淆的概念是单节点链接。以 ss://、trojan://、vmess://、vless:// 开头的内容，通常只描述一个代理节点；订阅正文则可能把几十条节点链接合并成一份列表。Clash 原生配置进一步加入代理组、规则、DNS、监听端口等字段，它已经不只是节点集合，而是一份可直接驱动代理核心的完整配置。
| 内容形态 | 常见特征 | 主要用途 | 能否直接保留规则 |
|---|---|---|---|
| 订阅地址 | https:// URL，可能带鉴权参数 |
定期拉取远端内容 | 取决于服务器返回格式 |
| 单节点 URI | ss://、trojan:// 等 |
分享一个节点的连接参数 | 不能 |
| Base64 节点集合 | 解码后通常是一行一个 URI | 批量分发节点 | 通常不能 |
| Clash YAML | 包含 proxies、proxy-groups、rules |
供 Clash 或兼容核心载入 | 可以 |
| sing-box JSON | 包含 inbounds、outbounds、route |
供 sing-box 及相关客户端载入 | 可以，但字段体系不同 |
Clash YAML 与常见节点链接分别保存什么
Clash 配置由四类信息组成
一份基础 Clash 配置通常同时保存监听设置、节点、代理组和分流规则。传统 Clash 常见的本地混合端口是 7890，控制端口常见为 9090；这些数字只是常用默认值，客户端也可能改为其他端口。节点位于 proxies，选择、自动测速或故障转移逻辑位于 proxy-groups，域名与网段的处理顺序位于 rules。
mixed-port: 7890
mode: rule
proxies:
- name: "Tokyo-01"
type: trojan
server: edge.example.net
port: 443
password: "example-password"
sni: edge.example.net
proxy-groups:
- name: "节点选择"
type: select
proxies:
- "Tokyo-01"
- DIRECT
rules:
- DOMAIN-SUFFIX,example.org,节点选择
- GEOIP,CN,DIRECT
- MATCH,节点选择这段示例说明了为什么“把 Clash 转成节点链接”通常会丢信息。Trojan URI 可以容纳服务器、端口、密码、SNI 等连接参数，却没有统一位置保存完整的 proxy-groups 与 rules。转换器若只输出单节点 URI，代理组的选择逻辑、自动测速间隔以及规则顺序都会被舍弃。
节点 URI 之间也不是等价关系
- Shadowsocks：
ss://主要描述加密方法、密码、主机和端口，插件参数通常放在查询字符串中。 - Trojan：
trojan://主要描述密码、服务器、端口、TLS 主机名及可选传输参数。 - VMess：常见分享形式把一段 JSON 编码后放进
vmess://，不同生成器对字段命名和默认值的处理可能不同。 - VLESS：
vless://常通过查询参数携带security、type、sni、flow等信息。 - Hysteria2 与 TUIC：依赖客户端核心版本与字段支持情况，旧版 Clash 核心通常不能完整识别，mihomo 的支持范围更广。
转换时不能只看协议名称，还要核对传输层、TLS、Reality、WebSocket 路径、gRPC 服务名、UDP 与客户端指纹等参数。协议相同但扩展字段不同，转换结果也可能只能“成功导入”，实际连接仍会超时。
订阅转换服务的实际工作流程
订阅转换不是简单改后缀。转换程序首先获取源订阅，再判断内容属于 YAML、JSON、Base64 节点列表还是若干明文 URI；随后把不同输入解析为内部节点对象，执行筛选、重命名和排序，最后按照目标客户端的字段规则重新序列化。若目标是完整 Clash 配置，还要套用代理组与规则模板。
- 拉取源内容：向订阅地址发起 HTTP 请求，处理重定向、压缩响应和字符编码。
- 识别输入格式：检查响应头、文本结构与协议前缀，而不是仅依据 URL 文件名。
- 解析节点参数：将服务器、端口、认证、TLS 和传输层字段整理为统一结构。
- 执行过滤：依据节点名称、地区关键字或正则表达式保留及排除项目。
- 应用模板：生成代理组、测速组、规则提供器和默认兜底规则。
- 输出目标格式：生成 Clash YAML、单链接集合或其他客户端可读取的结构。
为什么转换后的节点数量会变化
数量减少不一定是网络故障。转换器可能主动跳过无法识别的协议、缺少必填字段的节点或名称重复的条目。例如源订阅包含 86 个节点，其中 8 个使用目标核心不支持的协议，3 个缺少端口，2 个在去重后被合并，最终输出 73 个节点是可解释的结果。更稳妥的检查方式是对比转换日志中的“读取、跳过、输出”三组数字。
数量增加则常见于模板展开或订阅合并。两个源订阅分别有 40 和 35 个节点，合并后可能生成 75 个节点，但代理组中的引用数量会更多，因为同一节点可以同时出现在“手动选择”“自动测速”和“故障转移”三个组里。代理组引用数不能当作真实节点数。
客户端 User-Agent 会影响返回内容
部分订阅服务会依据请求的 User-Agent 返回不同格式。客户端声明为 Clash 时获得 YAML，普通浏览器访问时可能获得 Base64 文本或管理页面。因此，浏览器里看到的内容与客户端实际下载内容不一致并不罕见。排查时应在客户端日志中确认响应状态码与解析错误，而不是只用浏览器页面判断。
从其他格式转换为 Clash 配置
只有节点链接时，需要补齐代理组与规则
把一组 ss://、trojan:// 或 vless:// 链接转换成 Clash YAML，第一步只是生成 proxies。如果配置没有 proxy-groups，用户就无法在界面中按组选择；如果没有 rules，规则模式也缺少流量去向。最小可用模板通常至少包括一个手动选择组、一条局域网直连规则和一条最终 MATCH 规则。
规则顺序必须保持从具体到宽泛。DOMAIN,api.example.com,DIRECT 应放在 DOMAIN-SUFFIX,example.com,节点选择 之前，而 MATCH 必须位于最后。转换工具若把规则重新排序，可能导致本应直连的域名先命中后缀规则。
确认目标核心是传统 Clash 还是 mihomo
“Clash 格式”本身也存在能力差异。传统 Clash 配置常见字段不代表 mihomo 的全部功能；mihomo 增加或扩展了规则提供器、DNS、TUN、Sniffer 及新协议相关字段。把 mihomo 配置导入旧核心时，可能在不认识的代理类型或字段处直接报错，也可能忽略部分可选项。
| 检查项 | 转换后应核对的内容 | 常见表现 |
|---|---|---|
| 协议支持 | 目标核心是否识别节点 type |
导入失败或节点不显示 |
| TLS 参数 | sni、证书验证、指纹是否保留 |
握手失败、连接超时 |
| 传输层 | WebSocket 路径、请求头、gRPC 服务名 | 端口可达但代理不可用 |
| 代理组引用 | 组内名称是否与节点名称完全一致 | 配置校验提示找不到代理 |
| 规则提供器 | 远端地址、行为类型、更新间隔 | 规则集下载失败 |
| DNS 与 TUN | 地址段、监听端口和网卡设置是否冲突 | 开启 TUN 后无法解析域名 |
从 Clash YAML 导出其他格式时会丢失什么
从完整 YAML 导出为单链接集合时，最先丢失的是全局配置。mixed-port: 7890、局域网访问开关、运行模式、外部控制器、DNS 与 TUN 设置都不属于单节点 URI。随后丢失的是节点之间的组织关系，包括选择组、负载均衡组、自动测速组及其测试 URL、间隔和容差。
规则同样无法自然附着到节点 URI 上。域名分流、IP 网段、进程名规则、规则提供器和最终兜底策略必须由目标客户端重新配置。若转换目标是另一种完整配置格式，例如 sing-box JSON，转换器可以尝试映射这些结构，但两边的路由语义并非逐项对应，仍需人工复核。
名称与字符编码也可能改变
- URL 片段中的空格、中文和符号需要百分号编码，错误编码会造成名称截断。
- Base64 可能使用标准字符集或 URL 安全字符集，填充符处理错误会导致整条记录无法解码。
- 同名节点在 Clash 代理组中难以区分，转换器通常追加序号，这会同步改变组内引用。
- YAML 中含冒号、井号或前后空格的名称应加引号，否则可能被解释成语法。
自建订阅转换服务的部署思路
自建的主要目的，是让订阅内容在受控环境内完成解析。部署位置可以是本机、家庭服务器或私有云主机。无论使用哪一种实现，都应把“转换接口”和“管理界面”分开考虑：前者处理源地址与输出格式，后者负责模板、过滤规则和运行日志。
本机运行适合单人维护
本机服务可只监听回环地址，例如 127.0.0.1:25500，避免同一局域网中的其他设备直接访问。客户端订阅地址指向本机接口，由转换程序再去获取远端订阅。此方式不需要把源订阅提交到公开网站，但电脑休眠或服务停止时，客户端自动更新会失败。
服务器部署需要限制访问范围
服务器方案便于多设备更新，但应启用 HTTPS、接口鉴权、请求大小限制与访问日志轮换。转换接口若允许任意用户提交 URL，还要防止它被用于访问内网地址。至少应拒绝回环地址、链路本地地址和私有网段目标，并限制重定向后的最终地址。
缓存策略也要谨慎。假设上游订阅每 6 小时更新一次，可把转换缓存设为 15 至 60 分钟，避免每次客户端启动都重复请求；但缓存文件中包含完整节点凭据，存储权限和过期清理必须同时设置。日志中不应记录完整查询字符串，可只保留请求时间、输出类型、状态码和脱敏后的任务标识。
模板应该纳入版本管理
转换服务升级后，默认代理组名称或字段行为可能变化。建议为模板保留明确版本，例如 clash-template-2026-05.yaml，每次修改先在测试配置中验证，再替换生产模板。节点订阅与规则模板分开保存，可以避免上游更新时覆盖本地分流逻辑。
转换完成后的五步验证
- 执行语法校验：先在客户端导入但不要立即启用，确认 YAML 缩进、重复名称和代理组引用没有报错。
- 核对节点数量：记录源节点数、跳过数与输出数，重点查看未支持协议和必填字段缺失。
- 测试单个节点：选择一个已知可用节点进行延迟测试，再访问 HTTPS 页面确认 TLS 与传输参数正常。仅看到
80 ms或200 ms的延迟值，不能代替实际连接测试。 - 检查规则命中：打开客户端连接记录，分别访问预期直连与代理的域名，确认命中的规则和代理组符合模板设计。
- 验证 DNS 与 TUN：先测试系统代理，再按需开启 TUN。若系统代理正常而 TUN 异常，应检查 DNS 劫持、虚拟网卡权限与路由冲突，不要直接归因于节点转换。
在桌面客户端中，配置入口名称会因版本不同而变化，常见路径是「配置」→「订阅」更新远端文件，再到「代理」选择代理组；部分客户端把更新周期放在「设置」→「参数设置」。更新后应确认当前启用的配置确实切换到了新文件，避免测试的仍是旧缓存。
常见转换失败现象与定位顺序
订阅地址能打开，客户端却提示解析失败
先确认响应是不是客户端需要的格式。浏览器显示正常网页，只能说明 HTTP 请求成功；若返回的是登录页、额度提示或 HTML 错误页，Clash 仍无法解析。接着检查响应状态码、重定向后的域名和内容开头。YAML 中混入制表符、缩进层级错误或未闭合引号，也会导致整份配置载入失败。
可以导入，但全部节点超时
全部超时通常优先检查转换参数，而不是逐个更换节点。核对服务器地址、端口、TLS 的 sni、WebSocket 路径、gRPC 服务名和 Reality 公钥等字段。如果源格式使用了目标格式无法表达的扩展参数，转换器可能输出看似完整但无法连接的节点。
更新后原有规则和分组消失
这通常是把“节点订阅”直接当作“完整配置”覆盖了本地文件。正确做法是让远端节点通过代理提供器载入，或在转换阶段固定套用本地模板。节点数据负责变化，规则和分组由模板维护，两者分离后，上游更新就不会直接重写本地分流结构。
节点名称正常，代理组却为空
检查代理组是静态列出节点名称，还是通过提供器引用。静态名称必须逐字匹配，包括空格、大小写与转换器追加的序号。使用正则筛选时，还应确认地区名称是否在重命名步骤后发生变化。例如先把“Hong Kong”改成“香港”，原先只匹配 Hong Kong 的过滤表达式就会得到空结果。
选择转换方式时的实际建议
如果订阅提供方已经给出 Clash 或 mihomo 专用地址，优先直接使用该格式，减少中间映射。只有源格式与目标客户端不兼容、需要合并多个来源，或确实需要自定义分组和规则时，再加入转换步骤。转换链路越长，排错时需要检查的缓存、模板和字段映射就越多。
临时迁移少量节点，可以在本地完成单链接转换；长期使用多个订阅，适合建立固定模板并记录转换器版本；需要跨设备自动更新时，可以部署带鉴权的私有服务。无论选择哪种方式，最终判断标准都不是“成功生成文件”，而是语法可载入、节点参数完整、规则命中正确，并且更新过程可以重复验证。