同一份配置在两个客户端表现不同?Clash Premium 与 mihomo 的差异
一份配置在 A 客户端能跑、在 B 客户端报错,多半是内核不同。本文说明 Clash 原版、Premium 与 mihomo 的关系、几个常见的字段级差异,以及为什么校验工具会把这类差异标为提醒而不是错误。
本文目录(6 节 · 约 2 分钟) +
- 01 先理清楚谁是谁
- 02 几个常见的字段级差异
- 03 为什么校验工具不按某个客户端来判断
- 04 怎么确认自己用的是哪个内核
- 05 遇到「A 能跑 B 报错」怎么排查
- 06 小结
一句话结论:「Clash」现在指的是一族内核而不是一个程序,不同内核支持的配置字段不完全一样。 同一份配置在两个客户端表现不同,绝大多数时候是内核差异,不是配置写错了。
先理清楚谁是谁
- Clash(原版):最初的开源实现,2023 年底停止维护并从 GitHub 移除。现在基本见不到了。
- Clash Premium:原版的闭源增强版,加了 TUN、eBPF 重定向、脚本模式等。同样已停更。
- Clash.Meta → mihomo:社区分支,在原版基础上持续开发,后更名为 mihomo。这是目前绝大多数客户端实际使用的内核。
- sing-box:独立实现,不是 Clash 分支,配置格式是 JSON。有些客户端两种内核都支持。
所以今天你下载的 Clash Verge Rev、Mihomo Party、FlClash,跑的基本都是 mihomo。老教程里写的「Clash」,大概率指的是原版或 Premium,有些说法已经过时。
几个常见的字段级差异
一、端口写成字符串
port: "443" # 加了引号
mihomo 通常能容忍并自动转换,部分老版本会直接拒绝。规范写法是不加引号的整数 port: 443。
这就是为什么配置校验器把这种情况标为提醒而不是错误——它不规范,但多数环境下能跑。校验工具的判断依据是公开规范,而不是某一个客户端的实际宽容度。
二、协议支持范围
mihomo 支持而 Premium 不支持的:Hysteria2、TUIC、VLESS 的 Reality、以及 smux 多路复用等。
如果你的配置里有这些协议,它在老内核上会直接报「不支持的类型」。反过来,Premium 特有的脚本模式(mode: script)在 mihomo 上写法不同。
三、规则类型
mihomo 新增了不少规则类型,比如 GEOSITE、RULE-SET 的多种格式、SUB-RULE、逻辑规则(AND、OR、NOT)。这些在老内核上会报未知规则类型。
GEOIP 在两边都支持,但 mihomo 默认使用的 GeoIP 数据库和查询方式与 Premium 不同,个别 IP 的归属判断可能有出入。
四、DNS 配置
mihomo 的 DNS 模块字段更多(fake-ip-filter-mode、respect-rules、proxy-server-nameserver 等)。这块是差异最大的地方,直接照抄别人的 DNS 配置最容易出问题。
为什么校验工具不按某个客户端来判断
这是个有意的取舍。
如果按 mihomo 的实际行为判断,那么对老内核用户来说,工具会漏报一堆他们会遇到的问题。如果按最严格的规范判断,又会把大量实际能跑的配置标成错误,变成「狼来了」。
所以本站的做法是:按公开规范判断,把内核之间的差异标为提醒并说明原因,让你自己结合实际使用的客户端来决定要不要改。结果里会写清楚「多数客户端能容忍,但部分版本会解析失败」这类信息,而不是简单地判对错。
这也是配置校验器页面上写着「校验结果仅供参考,以你实际使用的客户端表现为准」的原因——这不是免责话术,是这类工具的真实边界。
怎么确认自己用的是哪个内核
多数客户端在「设置」或「关于」里会显示内核名称和版本。Clash Verge Rev 在设置页能看到 mihomo 的版本号;Mihomo Party 名字里就带着。
如果实在找不到,看客户端最后更新时间:2024 年之后还在更新的,几乎必然用的是 mihomo。
遇到「A 能跑 B 报错」怎么排查
- 先确认两边的内核和版本
- 把配置粘进配置校验器,看有没有结构性问题(这类问题在哪个内核上都是错的)
- 如果校验没问题,那就是内核差异——看报错的客户端具体说了什么字段
- 如果是节点本身的问题,用节点链接解析器看清那条链接的协议和参数,对照目标内核支持的范围
两个工具都在浏览器本地运行,配置和链接不会上传。
小结
- 现在说「Clash」通常指 mihomo,原版和 Premium 都已停更
- 端口引号、新协议、新规则类型、DNS 字段是四个高频差异点
- 校验按公开规范判断,差异标为提醒不判错——这是边界不是甩锅
- 排查顺序:先查结构性问题,再看内核差异
相关文章
select、url-test、fallback、load-balance 到底该用哪个
四种策略组类型经常被混用,尤其是 fallback 和 url-test。本文说清每种的实际行为、适合的场景,以及两个高频误解:load-balance 不会让下载变快、tolerance 不设会导致节点反复横跳。
tcp、ws、grpc、h2 这几种传输方式怎么选
节点配置里的 network 字段决定数据怎么传。本文对比 tcp、ws、grpc、h2 四种的实际差别:谁能过 CDN、谁延迟低、谁在弱网下更稳,以及各自需要配哪些额外字段。
allowInsecure=1 到底有多危险,为什么不该图省事打开
节点链接里的 allowInsecure=1 关闭了 TLS 证书校验,等于让 TLS 只剩加密、失去身份验证。本文说明它具体放弃了什么保护、什么情况下会被利用,以及为什么「反正流量已经加密了」这个想法不成立。