应该是内核导致的 bug:
那么切换 alpha 版本试试:
然后把内核换为 alpha:
或者换一个虚空终端,不过这玩意需要额外的面板
Release v1.18.4 · MetaCubeX/mihomo · GitHub
设备是 MacBook air m1,刚刚发现 cpu 占用第一的是 clash-meta,占用百分之六百多,非常 crazy
或者换一个虚空终端,不过这玩意需要额外的面板
8 个赞
把内核切换到 Alpha 版并升级到最新试试看
2 个赞
Windows没这个问题，要不你别用meta，用verge或者别的版本
1 个赞
最新的是1.18.4 或者1.18.1 都没问题
2 个赞
怎么说呢 相同的机场链接 我放在clash 这类客户端没速度，换nekoray就好了，遇到好几次了我就全面弃用clash系列了，verge meta我都用过 觉得还是nekoray好使，支持的协议也多。
2 个赞
百分之六百有点恐怖
1 个赞
老版本我也遇到过这个问题，nekoray就正常，clash就直接timeout，不过后来更新了新版本又好了，现在最新的版本，基本上都正常用了
1 个赞
百分之六百这能跑到吗？？
2 个赞
m1 air CPU是 6个大核心+2个省电核心，且不支持超线程。
理论上cpu总共有N个核，top默认进程模式就可以显示到上限 N*100% 。总核数N = CPU物理个数 x 每个CPU的核数 （top 按"1"切换看到的是逻辑cpu个数，不是总核数，注意区别。总逻辑CPU数 = 物理CPU个数 x 每颗物理CPU的核数 x 超线程数）
Linux / Mac OS 经常会显示CPU使用率超过100%。这里显示600%，说明CPU被全部占用了。应该是 clash meta 内核代码有问题，亦或者配置出错。极有可能是路由配置错误导致流量回环了，就是说进入clash的流量在本机形成了一个环状链路一直在内部来回转发，进而导致吃满内存和CPU。
最长前缀匹配机制（Longest Prefix Match Algorithm）是目前行业内几乎所有路由器都缺省采用的一种路由查询机制，当路由器受到一个IP数据包时，它会将数据包的目的IP地址与自己本地路由表中的所有路由表项进行逐位（Bit-By-Bit）比对，直到找到匹配长度度最长的条目，这就是最长前缀匹配机制
手动配置路由表，特别是在需要将流量全部导入某个设备时（比如全局代理），记得额外给出口IP单独添加路由，这时根据最长前缀匹配机制，这条路由将是最高优先级，由它兜底。避免出现流量回环。
–来自 wireguard 的折腾经验 
3 个赞
这个分析有道理
1 个赞
真**专业！
1 个赞
有道理