Clash中文官网站
客户端与配置参考

项目历史：从原版 Clash 到维护分支

原版 Clash 建立了 YAML 配置、策略组和规则分流等常用模型，许多桌面与移动客户端围绕这套模型提供图形界面。随着原项目进入归档状态，社区维护工作逐步转向延续分支。Clash.Meta 扩展了协议、DNS、规则和运行能力，后续以 mihomo 名称继续维护。今天看到的“Clash 客户端”往往不是同一个仓库的不同安装包，而是多个界面项目对兼容内核和配置格式的组合。

这段关系直接影响选型：历史客户端可能仍能运行，但不会持续适配新的系统变化和配置字段；活跃客户端通常会更新内置内核、安装方式与系统集成功能。迁移时不必一次重写所有配置，可以先复制订阅地址和必要的本地覆写，再逐项检查策略组、规则提供器、DNS 与 TUN 设置是否被新客户端正确识别。

生态分层：界面、内核、规则与订阅各自负责什么

图形客户端负责配置档案、托盘菜单、开机启动、内核控制和系统代理切换；mihomo 内核负责协议连接、流量嗅探、DNS 处理、规则匹配与策略执行；规则集合负责描述域名或 IP 应进入哪个策略；订阅则负责分发节点或完整配置。某一层出现问题时，表面症状可能相似，但处理方式完全不同。

例如“订阅更新后无法连接”可能来自订阅内容无效、客户端没有正确写入配置、内核不支持某字段、策略组引用了不存在的成员，或者系统流量根本没有进入客户端。按层检查比频繁重装更有效：先看配置能否解析，再看内核是否启动，然后检查代理组与日志，最后确认系统代理或 TUN 的接管状态。

内核关系：配置兼容不代表所有字段完全一致

mihomo 延续了 Clash 常见配置结构，并加入更多协议、DNS 选项、规则能力和运行参数。基础字段通常容易迁移，但涉及 tun、sniffer、geodata、rule-providers、profile 或实验特性的配置，需要根据当前文档核对。客户端可能还会在原始 YAML 之外维护自己的覆写文件、脚本或界面设置，因此导出单个配置文件不一定包含全部本地状态。

判断兼容性时应以“客户端版本支持什么内核、内核支持什么字段、当前订阅实际使用了什么内容”三项为准。不要只根据名称推断能力，也不要把某个客户端界面里的选项当作所有平台都存在的通用设置。协议手册进一步比较 SS、VMess、Trojan、VLESS、Hysteria2 与 TUIC 的设计侧重，以及它们在不同内核和订阅格式中的表达方式。

更新机制：区分客户端更新、内核更新与订阅更新

客户端更新通常修复界面、安装、权限或系统兼容问题；内核更新影响协议实现、规则引擎、DNS 和配置字段；订阅更新则改变节点、策略组或规则内容。三者时间并不一致。遇到问题时记录最近发生的是哪一类变化，可以显著缩小排查范围。若刚更新订阅，应先检查配置差异；若刚升级客户端，应核对内核和权限；若只更换了网络，则优先检查 DNS、路由与连接可达性。

稳妥的更新流程是保留当前可用配置，阅读新版本说明，更新后先验证配置载入和基本连接，再逐步恢复 TUN、覆写与自动策略。对长期运行的服务器，应把配置纳入版本管理并使用服务管理器控制重启；桌面用户则可以利用客户端的配置备份和日志界面保留迁移依据。