Clash 開源生態梳理:原版、Meta/mihomo 與各客戶端的關係
在 Clash 的語境裡,同一個名字往往同時指向一條已經凍結的原版核心、一支由社群接力的 mihomo 主線,以及十餘個介面各異的客戶端。本篇以詞條筆法著錄這條生態線:原版核心的歸檔始末、Clash Meta 到 mihomo 的繼承關係、核心與客戶端的分工架構,以及各平台客戶端的維護現況,卷末附一份按平台選型的參考結論。
一、原版 Clash 的始末
原版 Clash 由開發者 Dreamacro 以 Go 語言編寫,約於 2018 年公開,以 GPL-3.0 授權發布。它是一個純粹的命令列核心:本身不帶圖形介面,啟動後讀取一份名為 config.yaml 的設定檔,在本機開啟 HTTP 與 SOCKS 代理埠,並依據設定中的規則,把每一條連線分派給直連或某個代理出站。
就當時的環境而言,它的協定支援相當齊全:Shadowsocks、VMess、Trojan、Snell,以及標準的 HTTP 與 SOCKS5 出站;規則系統支援網域後綴、關鍵字、IP 段、GEOIP 等比對方式。「規則自上而下、命中即停」的分流模型,加上「策略群組」這一出站選擇器,構成了後來整個生態沿用至今的通用範式。
除開源版本外,作者另發布過閉源的 Premium 核心,以預編譯二進位檔形式提供 TUN 虛擬網卡、腳本規則等增強能力,供有需要的用戶替換使用。
2023 年 11 月,作者清空並刪除了託管在 GitHub 的 clash 儲存庫,專案首頁自此無法存取;同一時期,Clash for Windows 等多個知名下游客戶端相繼宣布停更或撤下發布內容。原版核心的版本號就此凍結,協定支援與功能不再演進——這是理解今天整個生態格局的起點。
二、從 Clash Meta 到 mihomo
在原版停更之前,社群中已存在功能分支 Clash.Meta,由 MetaCubeX 組織維護,目標是在原版程式碼的基礎上持續納入新協定與新特性。原版刪庫之後,這個分支自然成為事實上的主線;2024 年初,專案更名為 mihomo,儲存庫遷移至 MetaCubeX/mihomo,版本號在原有序列上延續,授權條款維持 GPL-3.0 不變。
相對原版,mihomo 的主要增量可以按類別著錄:
- 出站協定:新增 VLESS、Hysteria、Hysteria2、TUIC、WireGuard 等,涵蓋原版凍結之後出現的多數主流協定。
- 規則系統:引入規則供應器(rule-providers)與二進位規則集格式,便於分發與載入大規模網域或 IP 清單。
- DNS 模組:支援按網域分派的解析策略、網域嗅探等能力,用於緩解解析污染與分流錯位。
- TUN 模式:重寫並增強虛擬網卡堆疊,提供 gVisor 與 system 兩種實作,整機流量接管更為穩定。
- 控制介面:external-controller 與原版本保持相容,舊有面板與客戶端可以平滑遷移。
目前,幾乎所有仍在維護的 Clash 系客戶端,預設或建議核心均為 mihomo;原版核心僅在少數舊裝置與舊設定中繼續服役。
三、核心與客戶端的分工
Clash 生態的架構可以概括為「核心 + 外殼」兩層。核心是背景執行程序,負責代理協定、規則比對與 DNS 解析;客戶端是圖形外殼,負責介面呈現、訂閱的下載與更新、系統代理開關與開機自動啟動,並透過核心公開的 RESTful 控制介面下達指令、讀取執行狀態。這個介面預設監聽本機 127.0.0.1:9090:
# config.yaml(節選):核心對外控制介面
external-controller: 127.0.0.1:9090
secret: ""
由於設定檔格式在核心之間基本相容,同一份 config.yaml 通常可以在不同客戶端之間直接搬用;面板類工具(如 metacubexd、zashboard)也透過同一控制介面運作,可以掛接到任何一個 mihomo 實例上,與具體使用哪款客戶端無關。
訂閱連結的本質,是按 Clash 設定格式產生的一段 yaml 文字,客戶端負責定時抓取並合併進本地設定。理解「核心、外殼、訂閱」這三層之後,生態裡任何新出現的客戶端都可以快速對號入座:先看它內建哪條核心,再看它對訂閱與系統代理做了哪些封裝。
四、各平台客戶端現況
下表按平台著錄常見客戶端的核心歸屬與維護狀態(以各專案公開發布頁為準):
| 客戶端 | 平台 | 內建核心 | 維護狀態 |
|---|---|---|---|
| Clash Verge Rev | Windows / macOS / Linux | mihomo | 積極維護 |
| FlClash | Windows / macOS / Linux / Android | mihomo | 積極維護 |
| mihomo party | Windows / macOS / Linux | mihomo | 積極維護 |
| ClashX Meta | macOS | mihomo | 維護中 |
| ClashMetaForAndroid | Android | mihomo | 維護中 |
| OpenClash | OpenWrt | mihomo(可在設定中切換) | 積極維護 |
| Clash for Windows | Windows / macOS / Linux | 原版 / Premium | 2023 年 11 月停更 |
| Clash for Android | Android | 原版 | 已停更 |
| ClashX | macOS | 原版 | 已停更 |
| Clash Verge(舊版) | Windows / macOS / Linux | 原版 / Meta | 停更,由 Rev 接替 |
幾點補充著錄:Clash Verge Rev 是已停更的 Clash Verge 的社群續作,基於 Tauri 建構,介面與舊版一脈相承;FlClash 以 Flutter 編寫,桌面與行動平台共用一套介面邏輯;OpenClash 是 OpenWrt 上的 LuCI 應用,核心可在設定中切換;iOS 平台上常見的 Stash 為閉源付費軟體,相容 Clash 設定格式,與開源核心並無直接繼承關係,此處僅作著錄。
五、選型建議
綜合上述譜系,選型可以歸結為三條原則:
- 優先選擇仍在維護的組合。代理軟體需要跟隨協定實作與作業系統的變化持續更新,停更版本只能應付舊環境,曝露的問題也不會再有修復。
- 核心認準 mihomo。新協定與新規則集格式只在 mihomo 這一側演進;除非舊設定強依賴原版的特定行為,沒有理由回到已歸檔的核心。
- 客戶端按平台習慣挑選。桌面三平台可在 Clash Verge Rev 與 FlClash 之間按介面偏好取捨;Android 平台可選 ClashMetaForAndroid 或 FlClash;OpenWrt 路由器則使用 OpenClash。
舊客戶端匯出的 config.yaml 多數可以直接匯入基於 mihomo 的客戶端;個別已被移除的舊欄位或舊協定寫法,需要對照 mihomo 官方文件逐項調整後再載入,避免啟動時報錯。
各客戶端的取得管道、系統需求與安裝步驟,本站安裝包頁有逐項著錄;首次完成設定的流程,可參照入門指南逐步操作。
六、術語速查
實際執行代理與分流的背景執行程序,本身不帶介面,如原版 Clash 與 mihomo。
核心的圖形外殼,負責設定管理、訂閱更新與系統代理開關。
按 Clash 設定格式分發節點與規則的連結,由客戶端定時抓取。
出站的選擇器,決定某條比對最終交給哪個節點或群組。
以虛擬網卡接管整機流量的運作方式,可涵蓋不服從系統代理的程式。
可重複使用的規則清單檔案,mihomo 另提供體積更小的二進位格式。