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

“订阅能导入，但节点连接失败”和“客户端没有 TUN 开关”不是同一层问题。图形客户端负责订阅管理、托盘菜单、系统代理与配置合并；内核负责读取最终配置、监听端口、解析 DNS、匹配规则并建立代理连接。配置文件则描述这些行为。判断 Clash 原版、Clash Meta 与 mihomo 的区别，先确认正在运行的内核，而不是只看窗口上的应用名称。

  • 客户端版本：决定界面、服务安装方式和配置覆盖机制。升级界面程序，不一定同时升级内核。
  • 内核版本：决定协议实现、字段支持与路由能力。以客户端运行日志或内核版本命令的输出为准。
  • 订阅格式：可能是完整 Clash YAML，也可能只有节点列表，或是编码后的分享链接集合。三者不能直接互换。

原版、Meta 与 mihomo 的关系

原版 Clash：开源内核与 Premium 要分开看

原版 Clash 通常指 Dreamacro/Clash。历史上既有开源内核，也有提供额外能力的 Premium 闭源构建。原项目已停止维护。讨论原版是否支持 TUN、脚本或某类规则时，必须说明讨论的是哪种构建；不能把 Premium 的功能全部算进开源版，也不能假定两个版本的配置完全一致。

例如，原版开源内核的 mixed-port 与 Premium 的 TUN 能力属于不同层面的功能。前者提供本地 HTTP/SOCKS 代理入口，后者涉及虚拟网卡接管。看到配置里有 tun:，并不代表任意名为 Clash 的二进制都能执行它。

Clash Meta：从原版分支扩展能力

Clash Meta 是从 Clash 演进而来的分支，扩展了协议、DNS、规则与 TUN 等功能。“Meta 配置”通常表示配置使用了这一分支支持的扩展字段，而不是另一种完全不同的文件格式。它仍广泛使用 YAML，以及 proxies、proxy-groups、rules 这些熟悉的顶层结构。

mihomo：Meta 项目后续名称

Clash Meta 后续更名为 mihomo，两者有直接的项目延续关系，并非互不相关的两个内核。有些客户端仍把内核入口标为“Meta”，运行文件却已经是 mihomo。反过来，一份很早的 Meta 二进制也不会因为名称接近，就自动支持后来加入的新字段。实际兼容边界由具体版本决定。

# 查看手动安装的内核版本
mihomo -v

# 查看历史 Clash 二进制的版本
clash -v

上述命令需要对应可执行文件已在系统搜索路径中。Windows PowerShell 在当前目录运行时，可使用 .\mihomo.exe -v。如果客户端内置了内核，请优先查看其启动日志中的版本信息，避免查到另一份全局安装的程序。

协议支持：看节点类型，也看传输参数

协议名称是第一道检查项，但不是全部。相同的 VMess 或 Trojan 节点，还可能使用 WebSocket、gRPC、TLS 等传输或加密配置。只有节点类型、传输方式与关键字段都得到支持，才具备正常连接的前提。

能力 原版 Clash mihomo 迁移检查
Shadowsocks、VMess、Trojan 有相关实现，受历史版本限制 支持，具体参数随版本演进 检查加密方法、传输与 TLS 字段
VLESS 与 REALITY 不支持 支持相应配置 检查 UUID、flow、服务器名称及 REALITY 参数
Hysteria2、TUIC 不支持 支持相应协议 检查版本、认证字段与 UDP 网络条件
TUN 接管 需区分开源版与 Premium 提供 TUN 能力 另查管理员权限、服务与系统路由

“支持 Shadowsocks”不等于支持所有加密方法

较新的加密方法可能要求更新的内核。排查时应记录 type、cipher、network 等字段，不要只记录“SS 节点”。日志中的“不支持的代理类型”偏向内核能力问题；连接超时则还要检查服务器、线路、UDP 可达性和认证参数，两者不应使用同一种修复方法。

REALITY 不是单独的代理类型

常见配置以 type: vless 声明节点，再通过 reality-opts 等字段指定相关参数。将节点类型直接改成 reality，或只删掉不认识的字段，都不能完成协议转换。同理，把 type: hysteria2 改为 ss 不会得到可用的 Shadowsocks 节点；服务端也必须提供对应协议。

配置兼容：基础结构相近，扩展字段有边界

从原版配置迁移到 mihomo，常见基础结构通常可以保留；从 mihomo 配置退回原版，则容易遇到未知协议、未知规则或字段语义差异。兼容是有方向的，不是“都用 YAML，所以可以互换”。即使解析器没有报错，也要继续验证字段是否真正生效。

先用最小配置确认端口与规则入口

下面是用于检查基本结构的 mihomo 配置，不含远端节点。PROXY 组只含 DIRECT，因此所有请求最终仍然直连。它可以验证本地监听和规则结构，不能用于验证代理线路质量。

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

proxies: []

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

rules:
  - DOMAIN-SUFFIX,example.org,PROXY
  - MATCH,DIRECT
  • mixed-port: 7890：在同一个本地端口接受 HTTP 与 SOCKS 代理请求，不代表自动启用了系统代理。
  • allow-lan: false：不向局域网开放代理入口。迁移时应保留原先的访问范围，不要为解决连接问题直接放开监听。
  • mode: rule：使用规则模式。切到全局模式后，不能再用某条域名规则是否命中来验证分流。
  • MATCH,DIRECT：作为末尾兜底。实际使用代理时，应按自己的策略修改兜底出口。

优先检查容易跨版本出错的字段

配置区域核对内容常见现象
proxies协议类型、TLS 参数、传输选项加载失败，或指定节点握手失败
proxy-groups节点名称、组名称及 provider 引用找不到代理、策略组为空
dns增强模式、解析器地址与分流策略节点可连，但域名解析异常
tun网络栈、路由与 DNS 劫持设置内核启动成功，但应用流量未进入
script 等历史扩展是否属于原版 Premium 的专有配置不能直接套用到另一内核

规则、规则集与订阅要分别检查

基础规则主要看顺序和目标名称

DOMAIN、DOMAIN-SUFFIX、IP-CIDR、MATCH 是常见规则类型。一般按顺序匹配，前面的宽泛规则可能遮住后面的细分规则。迁移后如果所有流量都走同一个组，先看是否提前放置了 MATCH，再看规则引用的组名是否与 proxy-groups 完全一致。

mihomo 的逻辑规则、进程相关规则及扩展匹配能力不能一概视为原版支持。进程识别还受平台、权限和流量接管方式影响。配置通过检查，只能说明语法和引用满足当前内核要求，不能保证每个应用在每个平台上都能被识别到进程。

RULE-SET 还依赖规则文件的格式

使用 RULE-SET 时，应同时检查 rule-providers 中的名称、behavior、format 与文件内容。domain、ipcidr、classical 对规则内容有不同要求。不能把一份完整的 DOMAIN-SUFFIX,example.org 规则随意塞进只接受域名条目的数据源。

mihomo 的 MRS 规则集属于特定格式，还受内核版本及行为类型支持范围约束。将文件后缀从 .mrs 改成 .yaml 不会改变文件编码。回退旧内核时，应取得目标内核支持的规则源，而不是只改扩展名。

订阅导入成功不代表完成兼容验证

  1. 确认订阅返回的是完整配置，还是供 proxy-providers 使用的节点集合。
  2. 确认订阅服务提供的是 Clash 通用配置，还是明确面向 Meta/mihomo 的扩展配置。
  3. 查看客户端是否通过覆写、合并或脚本改变了端口、DNS、规则和策略组。
  4. 以实际交给内核运行的最终配置为准，避免只检查下载下来的原始文件。

配置和日志可能含有订阅地址、节点密码、UUID 或控制接口密钥。提交问题时只保留相关字段结构与错误信息，先移除认证数据。不要把完整订阅链接放进截图或公开讨论区。

迁移步骤：先验配置，再验流量

建议保留旧环境作为回退点，每次只改变一个变量。不要同时换客户端、换订阅、开 TUN、重写 DNS，否则即使故障消失，也无法确认具体原因。

  1. 记录现状：保存内核版本、客户端版本、当前配置副本、监听端口和策略组选择。确认旧配置在当前网络下的实际表现。
  2. 检查候选配置：使用准备运行的 mihomo 二进制执行配置测试。遇到第一个解析错误，先修复该错误，再继续检查。
  3. 单独启动新内核：停止旧内核，或为新内核使用不同端口。避免两个进程同时占用 7890 或控制接口端口。
  4. 先测显式代理：关闭 TUN，仅通过指定 HTTP/SOCKS 端口测试一个确定可用的节点。
  5. 再测规则与 DNS：分别访问应直连和应代理的目标，从连接记录核对命中规则、策略组与最终节点。
  6. 最后启用 TUN：安装客户端需要的服务或授予权限，再检查虚拟网卡、路由与 DNS 接管。
# 检查候选配置；不会启动常驻代理服务
mihomo -t -f ./candidate.yaml

# 通过 HTTP 代理入口进行请求
curl -I --proxy http://127.0.0.1:7890 https://example.org/

# 通过 SOCKS 入口请求，并让代理侧处理目标域名
curl -I --proxy socks5h://127.0.0.1:7890 https://example.org/

Windows 上可用 curl.exe 明确调用 curl，避免旧版 PowerShell 的同名别名干扰。测试时请把目标地址替换为需要验证的站点，并检查连接记录中的出口；上面的最小配置只会直连，不能证明远端节点可用。

-t 检查不等于完整联网测试。外部规则、节点 provider、本地数据库文件和相对路径仍需要单独核对。命令行运行与客户端运行的工作目录也可能不同，手动测试时找不到文件，不一定是 YAML 内容错误。

常见问题与内核选择

以前的 Clash YAML 可以直接交给 mihomo 吗？

基础节点、策略组与规则结构通常可以沿用，但应先执行配置检查，再验证 DNS、TUN 和外部资源。原版 Premium 的脚本等专有能力不能默认获得同等实现。还要检查客户端是否改变了最终运行配置。

客户端显示 Meta，是否必须手动换成 mihomo？

不必仅因名称就替换。先看实际内核版本与项目来源，界面标签可能保留旧名称。优先使用客户端提供的内核更新渠道；手动替换还涉及可执行文件路径、权限和客户端接口兼容性。

换内核后能提高网速吗？

内核可能影响协议支持、连接行为与资源占用，但不能直接改善节点带宽和运营商线路。比较时应固定节点、目标地址、网络接入和测试时间段，同时观察延迟、吞吐与失败率，不要把一次测速差异当作普遍结论。

支持 TUN 的内核为什么仍然不能接管应用？

内核支持只是前提。还要检查服务权限、自动路由、其他 VPN 的路由冲突，以及 DNS 请求是否进入预期路径。若显式代理成功而 TUN 失败，优先排查接管链路，不要立即更换节点或修改节点认证参数。

最终选择应从配置需求倒推：先列出节点协议，再列出规则、DNS 与接管要求，最后选择能够提供相应 mihomo 版本和权限管理能力的客户端。有关字段含义可继续查阅技术参考；首次部署时，按教程先完成订阅导入和显式代理测试，再逐步添加规则与 TUN。