Apple 原生clash 基于 Mihomo 的开源苹果客户端

技术交流
1

来源: https://x.com/bingwujinyi/status/2092177414751506588

Clash 回来了。这次是给 iPhone 写的，不是再套一层壳

你电脑上那个 Clash，严格说已经死了两年

2023 年底原作者停更。Clash Premium 冻结。VLESS 不认，Reality 不认，Hysteria2 也不认。后来社区把内核救活，改名叫 Clash Meta，再改名叫 mihomo。Windows 上大家改用 Verge、FlClash。iPhone 上各找各的：小火箭、Stash、Clash Mi

还是原来的配置，还是熟悉的规则。内核换成 Hako——mihomo 专门为 Apple Network Extension 削过的版本。界面是 Swift 原生，不是 Electron，不是 Flutter

1660×1148 117 KB

2

来源: https://x.com/ClashbyHako/status/2092445403128164688

我们的macOS版本在美区免费排行榜第一名，诚惶诚恐，还在努力改bug中，大家可以关注我们电报围观作者第一时间滑跪改bug的现场。

官网地址: https://clash.md/zh/platforms/macos

2528×1276 210 KB

3

个人点评:

按照习主席的指示要旗帜鲜明的反对历史虚无主义，小修一下史

首先clash 核心包括Premium 闭源版本到删库那天都没有支持过VLESS，当时vless已经出来好几年了，clash核心出于什么原因不支持，R主席有没有和clash核心作者交流过，issue当时怎么回复已未可知。也不是什么社区把clash 内核救活改名叫 clash.meta ，clash.meta 就是因为clash 不支持vless 所以fork 出来的项目，clash.meta 从建库第一天就叫 clash.meta ，建库就是为了支持vless 以及支持一些新的特性（记得好像是reality，我查一下再做修改），与clash 是独立而又平行的两个项目。

它们的关系跟xray 和v2ray关系相似，xray 也是v2ray fork而来，区别在R主席声明 xray 是v2ray 的超集（如果集合v2ray 内的元素，集合xray全都有，而集合xray拥有集合v2ray没有的元素，那么我们称集合xray 是集合v2ray的超集）。R主席出走建立 Project X 社区后，v2ray 也就是 Project V社区不活跃了，但依然有更新，那时候还挺欣赏R佬的，挺有个性一人，同时也为v2ray 扼腕叹息

说回 clash.meta 和clash，目前最早能找到的clash.meta 版本是 2021年 12月22日发布的1.8.0版本 https://github.com/MetaCubeX/mihomo/releases/tag/v1.8.0 ，比 2023 年 11月clash系大删库事件早2年就开始开发了，而 clash 最早能找到的版本大概在 2018年 11月 https://archive.org/details/github.com-Dreamacro-clash_-_2018-11-08_12-16-19 到 2023年11月删库，两个交叠存在两年的项目，也没有开发人员重合

（上）

4

这个是钓鱼软件，请勿使用

6

请问哪里有问题，源代码公开不是比 Clash Premium 和一众 iOS 软件可靠？

7

iOS无法开源

宣传方式诡异

完全Fork mihomo并AI加料

官网信息显示是一中转站旗下产品

联系方式​

如需就本隐私政策或任何隐私相关事项联系我们，请发送电子邮件至 [email protected]，或邮寄至： OmniWide Media Limited, 128 City Road, London, United Kingdom, EC1V 2NX。

结论为钓鱼软件，勿用

8

…是什么意思？sing-box 的 iOS 软件不是开源的吗？

9

这届浪人的姿势水平肿么辣么底啊

自己问，连美国豆包都能讲清楚

在绝大多数情况下，普通用户无法 100% 完美证明 App Store 商店里的安装包（IPA）和 GitHub 上的开源代码完全一致。

因为 App Store 的打包和分发过程是一个“黑盒”，苹果公司在把软件传给用户之前，会进行加密和重新签名。不过，iOS 社区和开发者通常会通过以下几种方法来建立信任或进行技术验证：

  1. 终极验证：可重现构建（Reproducible Builds）

这是技术上最严谨的证明方法。

  • 原理：如果开源代码非常干净，没有任何时间戳或随机干扰，那么在不同电脑上用相同的代码、相同的编译器（Xcode 版本）和相同的设置进行打包，生成的二进制文件（机器码）应该是一模一样的。
  • 做法：安全团队或资深用户可以从 GitHub 下载代码，在自己的 Mac 上编译出一个文件，然后通过越狱（Jailbreak）或特殊工具提取 App Store 里的安装包，对比两者的核心机器码。
  • 局限：iOS 因为有苹果的 FairPlay DRM（数字版权管理）加密保护，提取和对比的难度极高，目前只有极少数对安全性要求极高的软件（如某些加密钱包、隐私通讯软件）会努力做到这一点。
  1. 官方发布的 Release 校验（哈希值对比）

有些严谨的开源项目会提供这种方式。

  • 做法：开发者在 GitHub 的 “Releases” 页面上传一个已经编译好的正式版安装包，并公布这个文件的 哈希值（Hash/SHA-256）。
  • 原理：哈希值就像文件的数字指纹，代码只要改动一个标点符号，指纹就会完全不同。
  • 局限：这也只能证明 GitHub 上的安装包和代码一致，依然无法直接证明苹果 App Store 里的那个文件没有被动过（除非你用测试证书把 GitHub 的安装包安装到手机上，不走商店）。
  1. 生态信任链与开发者声誉（间接证明）

这是目前绝大多数普通用户和行业默认的“证明”方式。

  • 代码封版标签：开发者在提交 App Store 审核时，通常会在 GitHub 上打一个版本标签（如 v1.0.0），表示当前商店版本使用的是这段代码。
  • 声誉代价：如果一个知名的开源软件（例如 Signal、Bitwarden）在商店版本里偷偷加入了恶意代码，一旦被安全专家通过抓包、逆向工程（反编译分析）发现，该项目的信誉会彻底破产。
  1. 彻底消除疑虑的方法：自己动手

如果你对安全性的要求极高，不信任 App Store 的版本：

  • 完全开源安装：你可以直接把 GitHub 的代码克隆（Clone）到自己的 Mac 电脑上。
  • 自行审计和编译：自己检查每一行代码，然后用 Xcode 把代码直接安装（侧载）到自己的 iPhone 上。这样就能 100% 保证手机里运行的软件和代码完全一致。
10

不想浪费时间自己审计，也行，iOS信任链的常见方式就是基于开发者声誉