Clash 订阅格式详解:YAML、Base64 与订阅转换的正确姿势
拆解 Clash YAML、通用 Base64 与各客户端私有格式的区别,说明订阅转换服务的工作原理、常见转换失败原因,以及如何在不同内核客户端之间迁移同一份订阅。
READ →Clash 不是单一软件,而是一套围绕同一内核的客户端家族。不同平台有各自维护活跃的图形客户端,下载页按平台分组列出了可选项、系统要求与安装说明,以下入口直达对应分组。
规则是 Clash 的核心机制:每条连接按域名、IP 归属地或进程名逐条匹配,命中即送往对应出口,未命中则落入 MATCH 兜底规则。常用类型包括 DOMAIN-SUFFIX(域名后缀)、DOMAIN-KEYWORD(域名关键词)、GEOIP(IP 地理数据库)与 IP-CIDR(网段)。规则自上而下匹配、先命中先生效,顺序即优先级。与手动逐个应用设置代理相比,规则分流一次配置后长期生效:国内网站直连不绕路,目标网站走代理,广告域名直接拒绝,三类流量互不干扰。多数订阅已内置成熟规则集,新手无需从零手写。
规则匹配后的去向由出口决定,共三种基本值:DIRECT 直连本地网络、PROXY 经代理节点转发、REJECT 直接拒绝连接。PROXY 通常不是单一节点,而是一个策略组:手动选择组(select)由用户指定节点,自动测速组(url-test)定期测延迟选最快节点,故障转移组(fallback)在首选节点失效时自动切换备用。策略组可以嵌套,例如「地区分组套自动测速」。理解出口策略后,节点切换不再是玄学操作——在客户端面板里点选的每一项,都对应配置文件里一个明确的组与节点。
订阅是一条 HTTP 链接,指向服务商托管的节点与规则清单。在客户端的配置/订阅页粘贴链接,客户端会下载并解析为完整配置,后续按设定周期自动更新,节点变动无需手动改文件。格式上分两类:Clash YAML 原生格式可直接导入;通用 Base64 格式需经订阅转换服务转成 YAML 后使用。导入失败时先核对三点:链接是否完整未被截断、返回内容是否为 YAML 而非网页、客户端内核版本是否支持配置中用到的协议。本站教程页对导入步骤有逐屏截图级说明。
系统代理只对遵守代理设置的应用生效,命令行工具、游戏客户端与部分桌面软件会绕开它直接联网。TUN 模式在系统里创建一块虚拟网卡,把全部网络流量在网络层截获后交给 Clash 内核按规则处理,不依赖应用是否配合。开启前提:Windows 需以管理员身份安装服务组件,macOS 需授权系统扩展,Linux 需要相应权限。开启后建议配合 fake-ip 的 DNS 模式使用,避免 DNS 解析先于规则匹配造成分流失准。日常浏览用系统代理即可,涉及全局接管时再启用 TUN。
域名解析发生在规则匹配之前,DNS 配置不当会导致两类典型问题:解析结果被污染,直连流量拿到错误 IP 打不开网页;或解析走了错误路径,GEOIP 规则把代理流量误判为直连。Clash 内核提供内置 DNS 服务,支持 fake-ip 与 redir-host 两种模式:fake-ip 返回保留段虚拟地址、由内核在建立连接时再决定真实解析路径,配合 TUN 使用最稳;redir-host 行为更接近传统解析,兼容部分对 IP 敏感的应用。多数订阅已带可用的 DNS 段,出现「已连接但打不开网页」时优先检查这里。
Clash 最初是一款用 Go 语言编写的开源规则代理内核,以「一份 YAML 配置描述全部行为」的设计在技术社区获得广泛采用。原始仓库归档后,社区分支 Clash.Meta 延续开发并更名为 Mihomo,成为当前事实上的标准内核:协议支持更全、规则类型更多、TUN 实现更完善,主流图形客户端均已切换至该内核。
图形客户端与内核是两层关系:内核负责协议握手、规则匹配与流量转发,客户端负责订阅管理、界面交互与系统集成。Clash Plus、Clash Verge Rev、FlClash 等客户端各自独立开发维护,但读取同一套 YAML 配置格式——这意味着订阅与规则可以在不同客户端之间直接迁移,换客户端不必重学一遍配置。
内核与各客户端的代码均托管在公开仓库,提交历史、议题讨论与版本发布对任何人可查。版本更新由各项目社区驱动:内核修正协议与规则实现,客户端跟进内核版本并迭代界面。本站下载页的版本信息与安装包同步各项目的正式发布渠道,不做修改分发。
配置格式是纯文本 YAML,这带来一个实际好处:任何配置问题都可以还原成「文件里哪一行写了什么」,可以备份、可以比对、可以在文章里逐行讲清楚。本站的教程与排错文章全部基于这一格式展开,拿到自己的配置文件即可对照操作。
git clone https://github.com/MetaCubeX/mihomo.git
内核源码仓库。普通用户无需编译,直接在下载页获取图形客户端即可。
下面四条是新手最常卡住的地方。它们的共同特征是:表面症状相似,根因却分布在配置的不同层面,因此排查顺序比具体操作更重要。遇到问题先判断故障发生在哪一段——是客户端没能正常启动、订阅没能正确解析,还是客户端已经跑起来但流量走错了出口——再针对该层动手,可以避免把可用的配置越改越乱。
一个通用的判断方法:先看客户端界面是否列出了节点。列不出节点说明问题在订阅解析或配置格式;能列出节点但全部超时,说明问题在节点或线路;节点延迟正常却打不开网页,问题基本落在系统代理、DNS 或分流规则这三处本地设置上。按这个次序走,绝大多数故障都能在几分钟内定位到具体一层。
另外建议在动手改配置之前先备份当前可用的配置文件。YAML 是纯文本,复制一份留底的成本极低,却能保证任何一次改动失败后都可以立刻退回到已知可用的状态,而不是靠回忆去还原改过哪几行。完整解法与逐步截图见常见问题页与故障排查文章。
拆解 Clash YAML、通用 Base64 与各客户端私有格式的区别,说明订阅转换服务的工作原理、常见转换失败原因,以及如何在不同内核客户端之间迁移同一份订阅。
READ →把网速慢拆成节点、线路、本地三层逐段排查:先用延迟测试和切换节点隔离问题,再检查协议与端口选择,最后核对系统代理、DNS 与分流规则是否拖慢了直连流量。
READ →启动报错 bind: address already in use 的完整处理流程:用 netstat 与 lsof 找出占用 7890 端口的进程,判断该结束进程还是改端口,并给出改端口后同步系统代理设置的步骤。
READ →