外观
mihomo（Clash Meta）内核：与原版 Clash 的差异
mihomo 内核和原版 Clash 有什么区别？简单说，mihomo 是从原版 Clash 内核分叉出来、由社区持续维护的继任内核，原名 Clash Meta。
最直接的差异在三处：协议覆盖更广，尤其是 VLESS 与相关传输层；规则、DNS 与分流能力有扩展；项目仍在维护，而原版内核已停止更新。选择客户端时，内核是前置条件。
核心结论与适用条件
- 如果机场资料标注 VLESS，那么需要使用 mihomo、sing-box 或 Xray 一类内核，原版 Clash 内核无法解析这类节点。brands.json 中 17 个品牌有 12 个标注 VLESS。
- 如果你的客户端界面还是“Clash for Windows”一类旧软件，那么它大概率仍在使用原版或早期内核，需要确认内核是否具备你所需的协议能力。
- 如果你只使用传统协议、配置也没有变动，那么原版内核仍可能运行，但没有后续维护意味着缺陷和协议变化都得不到跟进。
- 如果你要写自己的规则，那么 mihomo 提供了更多规则类型与 DNS 选项，配置能力更强，同时对使用者的理解要求更高。
- 如果你关心“名字”：Clash Meta 与 mihomo 指的是同一条内核线，只是项目更名后的叫法不同。
这些结论基于公认的通用技术资料，不涉及具体版本号。内核说明之外的安装步骤请看Clash Verge Rev 安装与订阅导入，整体选择框架见桌面客户端专题。
先把名字说清楚：Clash、Clash Meta、mihomo、客户端
围绕 Clash 的名词很多，混着用是新手最常见的困惑来源。分四层理解会清楚得多。
第一层是内核。内核是真正处理网络连接的程序：解析配置、建立与节点的连接、按规则决定每个请求的去向。原版 Clash 内核由原作者开发，后来该项目停止维护。Clash Meta 是社区在其基础上继续开发的分支，后更名为 mihomo。
第二层是配置格式。Clash 系使用 YAML 格式的配置文件，里面有节点、策略组、规则等段落。mihomo 在兼容原有大部分写法的基础上增加了新字段，所以原版配置通常能被 mihomo 读取，反过来不一定成立。
第三层是客户端。客户端是给人用的图形界面，负责导入订阅、选择节点、展示日志。Clash Verge Rev、以及其他基于 mihomo 的图形客户端，都是“壳”，底下调用的是内核。同一款客户端换了内核，能力就跟着变。
第四层是订阅。订阅是机场提供的一个链接，下载后得到节点和（常常还有）规则的配置内容。订阅里写了什么，内核能不能读懂，决定了你最终看到的节点列表。
把这四层分开，就能解释很多现象：同一个订阅在 A 客户端里节点齐全，在 B 客户端里节点缺失，原因多半是 B 使用的内核不认识其中某类协议，而不是订阅出了问题。
差异总览：原版内核与 mihomo 内核
下表从可对照的维度列出差异。表中只写通用层面的能力描述，不写版本号。品牌侧字段为 Vendor Data，涉及速度的项目一律 Not Tested。
| 指标 | 原版 Clash 内核 | mihomo 内核 | 单位 | 统计口径 | 数据来源 | 更新时间 |
|---|---|---|---|---|---|---|
| 项目维护状态 | 已停止维护 | 社区持续维护 | — | 项目公开状态 | 通用技术资料 | 2026-10-18 |
| VLESS 协议 | 不支持 | 支持 | — | 协议覆盖 | 通用技术资料 | 2026-10-18 |
| 较新传输与安全层（如 REALITY） | 不支持 | 支持 | — | 协议覆盖 | 通用技术资料 | 2026-10-18 |
| 传统协议（Shadowsocks、VMess、Trojan） | 支持 | 支持 | — | 协议覆盖 | 通用技术资料 | 2026-10-18 |
| 规则类型 | 基础域名、IP、GEOIP 等 | 在基础上扩展更多类型 | — | 规则表达力 | 通用技术资料 | 2026-10-18 |
| 规则集远程订阅 | 有限 | 支持较完整 | — | 规则管理方式 | 通用技术资料 | 2026-10-18 |
| DNS 配置选项 | 基础 | 更丰富 | — | 配置项范围 | 通用技术资料 | 2026-10-18 |
| TUN 支持 | 取决于分支 | 内核自带 | — | 接管能力 | 通用技术资料 | 2026-10-18 |
| 配置兼容 | — | 大部分兼容原版写法 | — | 配置迁移成本 | 通用技术资料 | 2026-10-18 |
| 标注 VLESS 的品牌数 | — | — | 个 | brands.json 协议字段，共 12 个 | Vendor Data | 2026-10-18 |
| 品牌节点速度与延迟 | Not Tested | Not Tested | — | 本站未对品牌测试 | 本站 | 2026-10-18 |
表中“较新传输与安全层”一行提到了 REALITY。它是 VLESS 常搭配使用的一种传输安全方案，与 uTLS 一类 TLS 指纹伪装技术相关；这里只作名称与用途说明，详细原理见代理协议专题。
协议覆盖：为什么这是最关键的差异
协议是客户端与节点之间的“通信约定”。内核不认识某个约定，就无法与使用该约定的节点通话。这是内核选择必须放在第一位的原因。
原版 Clash 内核支持当时主流的几类协议。随着协议演进，VLESS 作为更轻量的协议被越来越多服务端采用，它去掉了协议本身的加密层，把安全性交给外层的 TLS 或 REALITY 一类机制。原版内核没有跟进，因此遇到 VLESS 节点时，常见表现是节点被静默忽略或报“不支持的类型”。
mihomo 在原有协议之上增加了对 VLESS 及其搭配传输方式的支持，这是它被广泛采用的直接原因。对读者而言，操作层面的结论很简单：品牌资料标注 VLESS 时，选 mihomo 系客户端；资料为空时，先向官方核实。
要注意，“内核支持协议”只是必要条件。一个节点能否连通，还取决于服务端配置、本地网络环境、系统时间等因素。内核选对了不等于节点一定可用。
规则与 DNS：配置能力上的扩展
分流是 Clash 系客户端的核心价值，而规则表达力直接决定了分流的精细程度。
在规则层面，原版内核支持按域名、域名后缀、域名关键字、IP 段、地理位置标记等条件匹配。mihomo 在此基础上扩展了更多匹配条件，并支持把大批规则作为“规则集”从远程拉取、定时更新，使维护成本降低。规则集的好处是：你不需要手写成千上万条域名，只需引用别人维护的列表。风险也在这里：规则集来源必须可信，不可信的规则集可以把任意域名导向任意策略组。规则模式与全局、直连的区别见三种出站模式专题。
在 DNS 层面，mihomo 提供了更多选项，比如为不同域名指定不同上游、使用加密 DNS（如 DoH）、在 TUN 模式下做域名映射等。DNS 与分流是紧密耦合的：域名解析到哪个地址，会影响规则匹配的结果和是否发生泄露。配置文件里这些字段的阅读方法见配置文件结构说明。
对多数用户，规则与 DNS 用客户端的默认模板即可，不必一开始就深入。需要自定义时再针对性地阅读对应段落，并且一次只改一处。
Decision Path
判断当前客户端内核是否够用
text
机场资料标注的协议是什么？
├─ 包含 VLESS 或其他较新协议
│ ├─ 客户端基于 mihomo / sing-box / Xray 内核？
│ │ ├─ 是 → 内核满足协议前置条件，继续核对订阅格式
│ │ └─ 否 → 更换客户端或更换内核
│ └─ 不确定客户端用的什么内核 → 查看客户端设置中的内核信息
├─ 仅传统协议
│ ├─ 客户端仍在使用且没有问题 → 可继续使用，但留意维护状况
│ └─ 希望使用规则集、新 DNS 选项 → 迁移到 mihomo 系
└─ 协议字段为空（待核实）
└─ 先向官方核实协议，再回到上面第一个分支从旧客户端迁移：需要注意什么
如果你过去使用的是已停止更新的旧版 Clash 图形客户端，迁移到基于 mihomo 的客户端通常分四步。
第一步，保留旧环境。迁移前不要先卸载旧客户端，先备份它的配置目录。这样迁移失败时可以回退。
第二步，不迁移配置，只迁移订阅。很多用户习惯复制整个配置文件，但订阅链接才是单一事实来源。在新客户端中重新导入订阅，让它自己生成节点与策略组，比手工搬运配置更不容易出错。
第三步，逐项核对自定义内容。如果你在旧配置里手写过规则或策略组，把它们列出来，再在新客户端中重新实现。mihomo 兼容大部分写法，但个别字段在不同分支上语义不同，不能想当然。
第四步，退出旧客户端后再启用新客户端。两个客户端同时运行会争抢系统代理设置和本地端口，造成难以解释的行为。这一原则在Clash Verge Rev 的安装步骤里也有强调。
迁移后的验证和日常验证一致：本地层、路径层、业务层逐层确认，不要跳级。
与 sing-box、Xray 的关系
mihomo 并不是支持 VLESS 的唯一内核。sing-box 和 Xray 也是常见的内核家族，各自有对应的图形客户端。三者在协议覆盖上有大量重叠，区别主要在配置语言、生态和客户端形态：
- mihomo 沿用 Clash 的 YAML 配置与策略组概念，上手门槛较低，迁移成本也低。
- sing-box 使用自己的 JSON 配置，结构更偏向“入站、出站、路由”三块，适合喜欢精细控制的用户，桌面端和移动端的覆盖都较广。
- Xray 一般与 v2ray 系客户端搭配，配置同样为 JSON，节点以链接或订阅列表形式管理，见v2rayN 专题。
选择哪一家，更多取决于你的使用习惯与设备，而不是谁“更强”。如果你需要的是图形界面、策略组和规则集，mihomo 系是自然的起点；如果已经在使用 v2rayN 或 NekoRay，也不必为了换内核而换客户端。后者的特点见NekoRay 专题。
三类典型读者的选择路径
同样是“要不要换成 mihomo”，不同读者的答案并不相同。下面按使用习惯分三类说明，帮助你对号入座，而不是给出统一结论。
第一类是刚买机场、从零开始的读者。你没有历史包袱，直接选择基于 mihomo 的图形客户端即可。这样做的好处是协议覆盖面足够，即使机场将来调整协议，也不需要重新换软件。导入订阅、选节点、开系统代理，这条链路在安装与订阅导入里已经按步骤写清楚，不需要先研究内核细节。
第二类是长期使用旧客户端的读者。你的现有配置可能已经包含大量自定义规则，迁移会带来一次性的整理成本。如果现在一切正常、只用传统协议，也没有迫切理由立即迁移；但只要出现下面任一情况，就应该开始计划迁移：机场新增了 VLESS 节点，节点列表里出现你的客户端无法识别的条目，或者你需要的规则类型旧内核不支持。迁移时遵循上一节的四步，不要一次性替换所有环节。
第三类是已经在用 sing-box 或 v2ray 系客户端的读者。你的内核本身已经满足新协议的前提，换成 mihomo 并不会带来协议层面的收益。只有当你想要策略组的使用习惯、规则集生态，或者想在多台设备上共享同一套 Clash 风格配置时，才值得考虑。否则保持现状更省心。
不论属于哪一类，都建议在改动前记录当前可用状态：哪些网站正常，哪些节点能用，系统代理是否开启。改动之后用同样的清单复测，才能确定改动是否真的带来了变化。
常见误区对照
围绕内核有一批流传很广的说法，下表逐条说明哪些成立，哪些需要条件。
| 常见说法 | 是否成立 | 条件或说明 | 依据 |
|---|---|---|---|
| “Clash 已经不能用了” | 部分成立 | 原版内核停止维护，但基于 mihomo 的客户端仍在使用 | 项目公开状态 |
| “换 mihomo 就能解锁更多服务” | 不成立 | 内核不决定出口 IP 属性和平台策略，可用性随 IP、地区和平台策略变化 | 通用技术原理 |
| “mihomo 一定比旧内核快” | 无依据 | 本站未做速度测试，速度取决于线路与网络环境 | Not Tested |
| “节点导不进来是机场的问题” | 不一定 | 常见原因是内核不支持协议或订阅格式不匹配 | 排错经验归纳 |
| “内核越新越好” | 需要条件 | 新版本带来新功能，也可能带来行为变化，更新前应备份配置 | 通用实践 |
| “所有 Clash 客户端的内核都一样” | 不成立 | 客户端可以搭配不同内核，能力随内核变化 | 通用技术资料 |
| “开了 TUN 就不需要规则” | 不成立 | TUN 只是接管方式，仍需要规则决定去向 | 通用技术原理 |
这张表的用途是让你在看到某条说法时多问一句“它的前提是什么”。很多论断在特定条件下是对的，脱离条件就会误导。
从日志里看内核在做什么
内核不是黑盒，日志与连接面板是观察它的窗口。学会读几类信息，可以把大多数疑惑变成可核对的事实。
启动记录。内核启动时会输出自己加载了哪份配置、监听了哪些端口、读取了多少条规则。配置加载失败时，这里会给出出错的位置，比如某个字段格式不对。遇到客户端“内核启动失败”，先看这一段。
协议相关警告。当订阅里存在内核不支持的节点类型时，有的客户端会在日志里留下警告，说明哪些条目被忽略。这是判断“内核不够用”最直接的证据，比反复重导订阅有效得多。
连接记录。每条连接都会标明目标地址、命中的规则、使用的策略组与节点。当你怀疑某个网站没有走代理，或者国内网站被送到了境外，看这条记录就能知道是规则问题、策略组问题还是节点问题。
DNS 记录。在启用 DNS 模块时，日志会显示域名被解析到哪个地址、由哪个上游处理。域名解析结果异常，往往能解释“规则看起来对但流量走错”的现象。
读日志时的原则是：先看时间，再看级别，最后看内容。把问题发生的时间点附近的几行日志找出来，比通读全部日志有效。需要把日志发给他人求助时，先删去订阅链接、令牌和节点地址等敏感字段。
一个排错演练：节点只剩一半
下面用一个假设化的场景把前面的内容串起来。场景纯属示例口径，数字没有任何统计含义。
假设你导入订阅后，客户端显示的节点数量只有机场后台的一半左右。按照前面的思路，处理顺序如下。
第一步，确认是否为内核问题。查看日志中是否有“不支持的类型”之类的警告，同时对照机场资料中标注的协议。如果缺失的节点恰好都是 VLESS 节点，那么大概率是内核不支持，换用 mihomo 系客户端。
第二步，确认订阅格式。如果日志没有协议警告，检查你使用的是否为 Clash 格式链接。通用 Base64 链接导入 Clash 系客户端时，经常出现解析不完整的情况。
第三步，确认订阅内容是否完整。把订阅链接在浏览器中打开，看能否下载内容、内容是否被截断。若链接本身返回的内容就不完整，问题在机场侧或链接本身。
第四步，确认是否被过滤。有些订阅会按套餐或设备限制下发不同数量的节点，后台显示的数量可能包含你当前套餐不可用的条目。这一点以各品牌官方说明为准，本站资料中此项为待核实。
走完这四步，你就能把“节点只剩一半”归因到内核、格式、链接或套餐四类原因之一，而不是笼统地怀疑线路质量。
知识图谱：mihomo 内核的概念关系
实体定义
mihomo 是一个开源的代理内核，前身为 Clash Meta，是原版 Clash 内核停止维护后由社区延续的分支。它读取 YAML 配置，负责节点连接、规则匹配、DNS 处理和 TUN 接管，不提供图形界面，也不提供节点。
相关概念
上位概念是桌面代理客户端；平行概念是 sing-box 与 Xray 内核；下游概念是各类基于 mihomo 的图形客户端；依赖概念是代理协议；内部概念包括策略组、规则集、DNS 模块、TUN 模块、出站模式、外部控制接口。
技术参数
内核层面可观察的参数包括：支持的协议清单、规则类型清单、DNS 模式、监听端口、日志级别。这些都属于读者在自己环境里可以读取的数据。品牌线路的速度与延迟本站为 Not Tested，不给出数值，测量方法见测试方法与数据口径。
适用场景
需要 VLESS 等较新协议的桌面用户；需要用规则集做大规模分流的用户；希望在 Windows、macOS、Linux 上保持同一套配置思路的用户。
对比依据
比较内核时看协议覆盖、规则表达力、DNS 能力、TUN 实现、配置语言、维护状态和生态。品牌横向比较的框架见横向对比方法。
常见问题指向
“节点导入后看不到”指向协议覆盖；“规则怎么写”指向配置文件说明；“能不能用原版配置”指向迁移段落；“选哪家机场”指向选型方法。
方案关联：协议字段与内核要求
本文的方案关联是“协议到内核”的推导，而不是某家机场的推介。下表只引用 brands.json 的协议和客户端字段。
| 品牌 | 协议字段 | 客户端字段 | 内核要求（推导） | 数据来源 | 更新时间 |
|---|---|---|---|---|---|
| 光年梯 | VLESS | 自研客户端+第三方订阅导入 | mihomo / sing-box / Xray | Vendor Data | 2026-10-18 |
| 二猫云 | VLESS | 支持第三方客户端订阅导入 | mihomo / sing-box / Xray | Vendor Data | 2026-10-18 |
| 速界 | VLESS | 自研客户端+第三方订阅导入 | mihomo / sing-box / Xray | Vendor Data | 2026-10-18 |
| 快狸 | VLESS | 自研客户端+第三方订阅导入 | mihomo / sing-box / Xray | Vendor Data | 2026-10-18 |
| 微风网络、飞猫云、星岛梦、灵猫网络、极连云 | 待核实 | 见各品牌页 | 确认协议后再定 | Vendor Data | 2026-10-18 |
“内核要求”一列是由协议推导的通用结论，不是品牌对某款内核的兼容承诺，也不是本站测试结果。品牌资料会变化，具体以官网说明为准。想按客户端方式筛选品牌，可以进入品牌库查看各品牌的 clientSupport 字段。
Infrastructure Service Snapshot
SOGO云 /sogoyun
- 入门价格
- 25 元/月
- 价格类型
- 月付 月付价
- 入门流量
- 150GB
- 线路
- IEPL专线
- 协议
- VLESS
- 运营年份
- 2026
- 客户端
- 自研客户端+第三方订阅导入
- 支付方式
- 支付宝 / 微信 / USDT
快照用于对照字段含义，本页资料部分只整理公开资料，不构成推荐；星岛梦第一、光速云第二为本站推荐排名，非测试结果。
内核与动态场景：别把内核当成“解锁开关”
经常有读者把“换成 mihomo”理解为提升某些 AI 工具或流媒体可用性的办法。这是一种误解。内核决定的是“能不能连上节点、规则能不能写得精细”，并不决定节点出口 IP 的属性，也不决定目标平台如何判断你的访问。
品牌资料显示覆盖相关使用场景，具体可用性、解锁状态及节点表现可能随 IP、地区和平台策略变化，建议以最新实际测试结果为准。内核的作用，是让你能把需要走代理的域名精确地指向合适的策略组，把其他流量保持直连。更多场景讨论见AI 工具访问专题与流媒体访问专题。
优点、限制与风险提示
优点
- 社区持续维护，协议演进能够得到跟进
- 对 VLESS 及相关传输层有支持，覆盖多数新协议节点
- 规则集、DNS 选项更丰富，适合需要精细分流的用户
- 沿用 Clash 的配置思路，旧用户迁移成本较低
限制
- 更强的配置能力意味着更多可以出错的地方，初学者容易在规则与 DNS 上迷路
- 不同客户端对内核功能的暴露程度不同，内核支持不等于界面上有对应开关
- 配置兼容只是“大部分”，个别字段需要核对
- 本文基于通用技术资料，不对具体版本功能做确认
风险提示
- 内核和客户端只从项目官方渠道获取，来路不明的二进制风险很高
- 使用来源不明的规则集或配置文件，可能把流量导向不可信节点
- 继续使用已停止维护的内核，意味着缺陷和协议变化得不到跟进
- 内核更新后行为可能变化，更新前建议备份配置目录
- 请在遵守所在地法律法规的前提下使用，本文只讨论技术原理
常见问题
mihomo 和 Clash Meta 是同一个东西吗？
是同一条内核线。Clash Meta 是社区在原版 Clash 基础上继续开发的分支，后来项目更名为 mihomo，所以两个名字常被混用。选择客户端时看它使用的内核家族即可，名字叫哪个并不影响判断。
原版 Clash 内核还能继续用吗？
在配置不变、只使用传统协议的情况下，旧内核可能仍能运行。但项目已停止维护，协议变化和缺陷都得不到跟进，遇到 VLESS 等新协议节点时无法使用。长期使用建议迁移到仍在维护的内核。
我的节点是 VLESS，必须用 mihomo 吗？
不是必须用 mihomo，但必须使用支持 VLESS 的内核。mihomo、sing-box 和 Xray 都具备这种能力。如果你想继续使用 Clash 系的策略组和规则习惯，mihomo 系客户端是最顺手的选择。
换成 mihomo 后会不会提高速度？
内核本身不决定节点速度。速度取决于线路、节点负载、本地网络和目标站点等因素。本站对品牌节点的速度状态为 Not Tested，不给出数值，也不能把更换内核当作提速手段。
旧的 Clash 配置文件能直接给 mihomo 用吗？
大部分可以，因为 mihomo 兼容原版常见写法。但个别字段在不同分支上含义不同，直接套用可能出现意料之外的行为。更稳妥的做法是在新客户端重新导入订阅，再把自定义规则逐项加回去。
怎么知道我的客户端用的是什么内核？
多数图形客户端会在设置或关于页面显示内核信息，也可以在日志的启动记录里看到内核名称。如果界面上找不到，查看项目文档说明。不要靠客户端外观判断，因为不同客户端可以使用同一内核。
mihomo 与 sing-box 该选哪个？
取决于使用习惯。如果你习惯策略组和 YAML 配置，mihomo 系更自然；如果你偏好入站、出站、路由的结构化 JSON 配置，或需要在多平台保持一致，可以考虑 sing-box。两者都能满足 VLESS 的内核前提。
内核更新后需要重新导入订阅吗？
通常不需要，订阅保存在客户端的配置目录里，内核更新不影响它。但更新前仍建议备份配置目录，更新后若行为异常，先看项目发布说明，再决定是否回退。
规则集可以随便引用别人的吗？
不建议。规则集决定哪些域名走代理、哪些直连，来源不可信的规则集可以把任意域名导向任意策略组。优先使用知名、公开维护的规则集，并留意更新来源是否变化。
mihomo 是不是比原版更耗资源？
本站没有对此做测试，不给出数值。内核运行资源占用取决于规则数量、连接数和系统环境，通用资料不支持一概而论。如果你担心资源占用，可以在自己的设备上观察系统资源监视器。
下一步
内核问题弄清楚之后，可以按需往下走：想知道三种出站模式什么时候用，读规则、全局、直连的区别；想动手装一个客户端，读Clash Verge Rev 安装步骤；还没有确定机场，则先看选型方法。下方卡片指向品牌库，品牌详情页中的注册链接为各品牌官方注册或推广链接；本页资料部分只整理公开资料，不构成推荐；星岛梦第一、光速云第二为本站推荐排名，非测试结果。