Clash 内核兼容对照

先区分客户端、内核与配置

Clash 客户端名称不能直接代表实际能力。窗口界面负责导入订阅、管理配置、设置系统代理；内核负责解析节点、监听端口、匹配规则和建立连接。同一个客户端在不同发行版本中，可能捆绑不同版本的内核。判断一份订阅能否使用，首先要看正在运行的内核，而不是桌面快捷方式上的名称。

本文中的“原版”指早期 Clash 开源内核；Premium 指当时额外提供的闭源增强内核。二者不能混为一谈。原版开源项目与 Premium 的原有公开发布渠道在 2023 年停止维护后，旧程序仍可能启动，但不能据此推断它们获得了后续协议更新或系统适配。

建立三层检查顺序

1. 客户端层：能否保存自定义规则、更新订阅、申请 TUN 所需权限。
2. 内核层：是否识别节点的 type、传输选项与 DNS 字段。
3. 运行配置层：界面操作、订阅转换和配置合并后，最终传给内核的 YAML 是否符合预期。

例如，编辑器里保存了 mixed-port: 7890，客户端的端口覆写仍可能把它改为其他值。排查时应同时查看客户端设置与运行配置，不能只检查下载到本地的订阅原文。

原版、Premium 与 mihomo 对照

下表比较的是内核系列的能力边界，不是对任意历史版本的保证。尤其是 mihomo，新增协议、字段和规则格式都有版本要求；“使用 mihomo”不等于“旧版二进制支持所有当前配置”。

Premium 的名称不表示它在今天仍比 mihomo 功能更多，也不表示使用它必须购买订阅。内核分支、客户端发行方式与代理服务订阅是三件不同的事。订阅中能否连接某个服务器，还取决于服务端参数、认证信息、网络路径与证书配置。

协议支持要检查到具体参数

识别协议名称不等于连接成功

当节点出现 type: vless、type: hysteria2 或 type: tuic 时，应选择明确支持这些类型的 mihomo 版本。把节点的类型文字改成 vmess 或 trojan 不能完成协议转换；服务端必须提供对应协议的入口。

即使两个内核都能识别 type: ss，它们支持的加密方法也可能不同。Shadowsocks 2022 系列方法不能仅凭“支持 Shadowsocks”这一描述判断兼容。类似地，VLESS 的 REALITY 参数、传输方式、指纹设置，都需要与服务端一致，并由所用内核版本支持。

• 解析阶段报未知类型：优先检查内核分支、版本和订阅格式。
• 提示缺少字段或参数非法：对照该版本的配置文档，检查字段名称、层级与数据类型。
• 配置加载成功但握手失败：检查服务器地址、端口、认证、SNI 与证书相关参数，而不是继续调整规则顺序。
• 网页正常但 UDP 应用失败：检查节点、服务端及本地接管链路是否都支持 UDP。

订阅格式也有兼容边界

“Clash 订阅”不是精确的版本声明。服务商可能提供面向原版的精简配置，也可能提供包含 mihomo 扩展的配置。若导入过程经过订阅转换，转换器还可能删除不认识的节点或字段。出现节点数量减少时，应比较原始响应、转换结果与客户端运行配置，确认内容在哪一步发生变化。

配置兼容：从基础字段到扩展字段

迁移时可以先保留监听端口、基础策略组和常见规则，再逐项加入扩展功能。下面是一份用于验证 mihomo 能否加载的最小配置，不含远程代理节点；“出口选择”只有直连选项，不能用于验证代理服务器是否可用。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxy-groups:
  - name: 出口选择
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,出口选择
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,出口选择

7890 是本例选择的本地 HTTP 与 SOCKS 共用端口，不是所有客户端的固定默认值。allow-lan: false 用于限制局域网访问。导入前若已有其他程序监听该端口，应更换端口，或停止冲突进程。不要同时启动两个使用相同监听端口的内核。

规则顺序与策略引用仍然重要

常见规则按从上到下的顺序匹配；前面的规则命中后，后面的规则不会继续决定该连接的出口。MATCH 应放在兜底位置。规则末尾引用的策略名称必须真实存在，且文字完全一致。迁移内核不会自动修复拼错的策略组名称。

no-resolve 常用于 IP 类规则，表示不为匹配这条规则主动触发域名解析，不表示整个请求永远不使用 DNS。引入 rule-providers 时，还要检查 behavior、format 与规则文件内容是否对应。不能把纯域名列表直接当作包含完整规则语句的 classical 规则集。

不要直接搬运 Premium 脚本

Premium 的脚本功能不能视作 mihomo 的通用兼容接口。旧配置若含 script，应先确认所用内核是否支持相同机制，再考虑改写为规则集、逻辑规则或策略组。YAML 能被读取，并不保证所有未知字段都产生作用；部分字段可能被忽略，因此需要通过实际连接的命中记录验证。

DNS 与 TUN 是两项独立检查

Fake-IP、DNS 分流与 TUN 经常同时出现在教程中，但它们负责不同环节。DNS 模块处理域名解析与映射；TUN 通过虚拟网卡和路由接管流量。开启 TUN 不会自动保证所有 DNS 查询都按预期处理，也不能单凭 DNS 检测页面显示的服务商名称判断内核兼容性。

迁移 DNS 配置时检查四处

1. 监听地址：例如 127.0.0.1:1053 只对本机开放；系统若仍查询其他地址，内核 DNS 不一定参与。
2. 增强模式：核对 enhanced-mode 使用的是 fake-ip 还是 redir-host，不要只保留旧界面的开关状态。
3. 解析分流：检查 nameserver、fallback、nameserver-policy 的实际语义；fallback 不能简单理解为主解析器超时后的备用地址。
4. 额外解析入口：浏览器安全 DNS、应用内置 DoH 和路由器转发都可能绕过原本设想的解析链路。

TUN 不等于所有流量必经代理

mihomo 的 tun.enable、auto-route 与 dns-hijack 各有职责：启用虚拟网卡、配置路由、劫持指定 DNS 流量。最终出口仍由规则决定，命中 DIRECT 的连接会直连。权限不足、路由冲突或 VPN 并行运行，也可能导致部分流量未被接管。

不要为了兼容旧教程直接复制 stack 的取值。可用栈与行为会受内核版本和操作系统影响。应先使用客户端为当前平台提供的默认设置，再针对具体故障调整。测试时先关闭 TUN 验证系统代理，确认节点正常后再启用 TUN，可以减少同时变化的因素。

迁移前后如何验证运行结果

迁移应使用可回退的配置副本。先记录旧内核名称、版本、监听端口和订阅更新时间，再复制配置进行测试。命令行用户可以对实际二进制执行以下检查；桌面客户端用户则应查看内核日志，并确认测试的是客户端真正启动的那一份内核。

mihomo -v
mihomo -t -f ./config.yaml

第一条查看版本，第二条检查配置能否被解析与加载。检查通过只说明静态配置满足相应条件，不代表远程节点握手成功、DNS 路径正确或 TUN 路由生效。若配置引用远程规则或节点提供器，还应确认相关资源能够取得。

若出现故障，按“加载失败 → 本地监听 → 节点连接 → 规则命中 → DNS/TUN”的顺序排查。一次只改一个变量。更详细的通用检查可见故障排查；初次导入配置可先按配置教程完成基础连接。

客户端选型的最终判断

• 新部署：优先选择仍在维护、明确标注所用 mihomo 内核版本的客户端，再核对操作系统和处理器架构。
• 已有稳定旧环境：先保留可用副本，再检查新订阅是否引入旧内核不支持的协议，避免直接覆盖全部配置。
• 依赖 TUN：除了内核能力，还要确认客户端能申请权限、管理服务，并在退出时清理路由。
• 依赖复杂规则：重点检查规则提供器、逻辑匹配与持久化覆写方式，确认订阅更新不会移除本地修改。

选择依据应落在可观察的事实：实际运行的内核版本、配置检查结果、日志中的协议错误，以及连接记录里的规则与出口。Meta 与 mihomo 的名称差异不是主要障碍；旧二进制、扩展字段和客户端覆写之间的不一致，才是迁移时更常见的兼容问题。