选型结论：先查内核，再看客户端名称

新配置需要 VLESS、Hysteria2、TUIC 或较新的规则能力时，应优先检查客户端是否使用满足要求的 mihomo 构建。已有 Clash Premium 配置可以作为迁移来源，但不宜把停止维护的历史内核作为新部署的默认选择。Clash Meta 与 mihomo 则是同一项目演进中的名称，不是两套互不相关的协议体系。

对 Clash 苹果版用户而言，下载页上的应用名称只说明图形界面是哪一款，不能直接证明内部协议支持。一个客户端可能允许切换内核，也可能固定捆绑某个版本；应用更新与内核更新还可能分开发生。排查时至少记录客户端版本、内核名称、内核版本和 macOS 或 iOS 版本。

Clash、Premium、Meta 与 mihomo 的关系

原版 Clash：开源内核与基础配置体系

原版 Clash 建立了常见的 YAML 配置结构，包括代理节点、策略组、规则和本地代理端口。大量客户端沿用了这套结构，因此不同应用都可能出现 proxies、proxy-groups 和 rules。原项目在 2023 年停止原有公开维护后，历史构建仍可能运行，但不应期待它持续适配新的协议和系统变化。

Clash Premium：历史闭源分支，不是付费订阅

Clash Premium 是原项目提供过的闭源内核分支，包含 TUN、规则集等扩展能力。这里的 Premium 指内核分支，不等于节点服务商的付费套餐，也不表示购买某个订阅就能给原版内核增加协议。它同样属于历史维护体系，不能因客户端界面仍能启动，就认定底层仍有持续维护。

Clash Meta 到 mihomo：延续与扩展

Clash Meta 是基于 Clash 发展起来的分支，后来更名为 mihomo。旧教程、订阅转换选项与客户端设置中仍可能保留 Meta 字样。看到“Meta 内核”时，应继续确认实际版本，而不是把名称当作兼容性保证。较新的 mihomo 配置也不保证能在早期 Meta 构建上运行。

  • 项目名称：判断维护来源与文档应查哪一套。
  • 内核版本：判断具体字段、协议选项与修复是否已经包含。
  • 客户端版本：判断界面、辅助服务与配置合并逻辑。
  • 系统版本：判断网络权限、沙盒与扩展机制的限制。

协议支持差异：节点名称不能替代协议类型

节点标题可以任意命名，真正决定解析方式的是 YAML 中的 type 以及相关字段。例如名为“高速线路”的节点可能使用 Trojan，也可能使用 Hysteria2。判断兼容性时，应查看订阅实际内容；向他人提供片段前，先删除密码、UUID、服务器地址和订阅令牌。

检查项 原版 Clash Clash Premium mihomo
SS、VMess、Trojan 等基础协议 支持常见配置 支持常见配置 支持，具体选项按版本确认
VLESS 与 REALITY 相关配置 不应作为兼容目标 不应作为兼容目标 支持相应配置，需核对字段
Hysteria2、TUIC 不支持这些新协议 不应按完整支持处理 支持，协议版本和参数需匹配
内置 TUN 原开源版不提供 提供历史实现 提供，受平台与权限影响
维护定位 历史兼容与存量迁移 历史兼容与存量迁移 按项目发布记录持续核对

同名协议也可能存在参数差异

支持某一种协议，不等于支持它的所有传输方式、加密方法与扩展选项。VLESS 节点还可能涉及 flow、TLS、REALITY 和传输层配置；TUIC 的不同协议版本也不能直接混用。若日志提示 unsupported proxy type，先检查内核类型；若配置能加载但握手失败，再检查认证信息、时间、TLS 参数和网络可达性。

订阅转换只能把输入内容映射成目标格式，不能给内核补上协议实现。将 Hysteria2 节点转换为一份名叫“Clash”的 YAML，并不会让原版 Clash 获得 Hysteria2 支持。选择转换目标时，应明确是传统 Clash 兼容格式，还是面向 mihomo 的扩展格式。

规则与 DNS：语法接近，执行结果未必相同

常见的 DOMAIN、DOMAIN-SUFFIX、IP-CIDR 与末尾 MATCH 是迁移时较容易保留的部分。规则按顺序匹配，前面命中的规则通常决定出口；把宽泛规则放在前面，可能使后面的精细规则失去作用。策略组名称还必须与规则引用完全一致，不能只迁移节点而漏掉分组。

规则集与扩展规则需要逐项确认

  • 外部规则集：检查 rule-providers 的格式、来源、更新方式，以及 RULE-SET 引用是否有效。不要把 Premium 或 mihomo 的完整规则集能力直接套用到任意原版构建。
  • 地理数据：GEOSITE 等规则依赖内核支持和相应数据文件。仅复制规则文本，不能替代数据资源的下载与加载。
  • 进程规则：依赖系统能否提供进程信息，macOS 上的行为不能直接推断到 iOS 网络扩展中。
  • 脚本策略：Premium 的历史脚本写法不能视为 mihomo 的通用兼容接口，迁移时优先改写为明确的规则和策略组。

DNS 配置决定规则能看到什么

fake-ip 与 redir-host 是不同的 DNS 工作模式。fake-ip 通过映射帮助内核关联域名和连接，redir-host 则返回解析得到的地址；它们并不是所有网络环境下可互换的开关。迁移后出现“节点可测延迟、网页打不开”，应同时检查 DNS 上游可达性、域名分流和系统是否真的使用了内核 DNS。

macOS 与 iOS 的 TUN 实现差异

系统代理与 TUN 接收流量的位置不同。系统代理主要供遵循代理设置的应用使用；TUN 通过虚拟网络接口与路由处理接收流量，能够覆盖更多不读取系统代理的应用，但并不意味着所有流量都必然进入代理节点。最终出口仍由路由、排除项、规则与直连策略共同决定。

macOS：辅助服务不等于网络扩展

macOS 客户端可能通过具备权限的辅助服务创建 TUN，也可能使用 Apple 的网络扩展机制。不同实现的授权步骤不同，不能把“开启 TUN”统一解释为“必须批准系统扩展”。在 macOS 13 及之后版本，可先从「系统设置」→「网络」检查 VPN 与网络服务状态；若客户端明确提示系统软件被阻止，再按它的说明到「系统设置」→「隐私与安全性」核对授权。

mihomo 的 TUN 配置中常见 auto-route、auto-detect-interface 与 dns-hijack。自动检测出口适合常见单出口环境，但多网卡、其他 VPN 与特殊路由环境仍需检查实际结果。macOS 出现 utun 接口并不能单独证明当前客户端接管成功，因为系统与其他 VPN 也可能创建同类接口。

iOS：网络扩展与应用能力共同决定

iPhone 与 iPad 通常依靠应用的 Network Extension 隧道扩展运行网络功能，不能把 macOS 的可执行文件复制过去使用。首次建立隧道一般需要确认添加 VPN 配置；之后可在「设置」→「通用」→「VPN 与设备管理」检查相关项目。即使应用导入了 Clash 风格配置，实际支持的协议和字段也必须以该应用内核及文档为准。

因此，“同一份 YAML 能在 Mac 导入”只说明 Mac 端解析成功，不代表 iOS 端的进程规则、文件路径和后台更新方式完全一致。多设备共用订阅时，可以统一节点和主要分流规则，把平台权限、文件位置与网络接管设置留给各设备单独管理。

迁移到 mihomo：从最小配置逐层恢复

下面是一份用于检查解析、端口绑定与基础规则的最小配置。它只有直连策略，没有代理节点，不能用来验证远程节点是否可用。示例将 HTTP 与 SOCKS 混合端口设为 7890，仅绑定本机回环地址；端口号是示例选择，不是所有客户端的固定默认值。

mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1
mode: rule
log-level: info
ipv6: false

proxy-groups:
  - name: DIRECT-TEST
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,DIRECT-TEST

先检查语法，再检查网络

独立运行内核时，可用以下命令记录版本并测试配置。文件路径以当前目录为准；若使用图形客户端，应通过它的配置检查功能验证最终合并结果，不要同时启动第二个内核争用端口。

./mihomo -v
./mihomo -t -f ./config.yaml
lsof -nP -iTCP:7890 -sTCP:LISTEN

-t 通过，只代表配置检查通过，不代表节点、DNS 与规则都已验证。某些检查还会读取本地资源或获取外部数据，失败时要分清是语法错误、资源缺失还是网络请求失败。若日志出现 address already in use，先确认是否已有客户端占用 7890，不要为了绕过错误而盲目开放局域网访问。

  1. 备份：保存旧配置、内核版本、客户端覆盖设置与当前策略组选择，保留可直接恢复的副本。
  2. 验证基础：关闭 TUN，用最小配置确认解析与本地端口正常，再导入一个已知可用的节点。
  3. 恢复分流：依次加入策略组、规则、规则集和 DNS，每次只改一类内容，并查看连接实际命中了哪条规则。
  4. 最后开启 TUN：检查权限、默认出口和 DNS 接管，再测试浏览器以外的应用。
  5. 验证回退：退出新客户端后，确认系统代理与隧道已关闭，再恢复旧版本；避免两个工具同时改写路由。

常见问题：从错误信息定位兼容层

配置能导入，为什么启用后立刻失败？

部分客户端只在导入阶段检查 YAML 结构，启用时才交给内核解析。先查看启动日志，区分未知协议、无效字段、找不到策略组和监听端口冲突。若服务商提供多个订阅格式，应选择与当前内核对应的格式，而不是反复修改订阅地址中的名称。

旧 Clash Meta 配置可以直接用于 mihomo 吗？

常用节点与基础规则通常有较好的延续性，但不能保证所有扩展字段、实验功能与默认行为完全一致。先运行配置检查，再核对发布说明中涉及 DNS、TUN 和协议参数的变更。即使没有报错，也要通过连接日志验证规则命中和实际出口。

Apple 芯片 Mac 的节点延迟高，是选错架构了吗？

不应只凭延迟判断架构。可在「应用程序」→「实用工具」→「活动监视器」中查看相关进程的种类，确认客户端与内核的运行情况。网络延迟更应检查节点线路、DNS、测试目标及是否启用了其他 VPN；界面内的单次延迟测试也不等于网页完整加载耗时。

升级内核后，需要立即开启 TUN 吗？

不需要。先用系统代理验证节点和规则，可以减少权限、路由与 DNS 接管带来的变量。只有目标应用不读取系统代理，或确实需要更广的流量接管时，再单独开启 TUN。具体故障可继续参照排查手册按日志与网络层次检查。

最终选型应落到三个问题：订阅中的协议能否解析，所需规则能否正确执行，当前苹果设备上的网络接管是否可靠。内核名称用于确定技术路线，准确版本与可复现的测试结果才用于确认兼容性。