Clash、mihomo、Verge Rev 是什麼關係:開源專案譜系與核心演進梳理
很多人第一次接觸 Clash 生態時都會被「到底該裝哪個」問住:Clash、Clash Meta、mihomo、Clash Verge Rev、FlClash……名字相似卻指向不同的專案。這篇文章按時間線梳理核心與用戶端的繼承關係,說明誰是誰的延續,以及如何判斷一個專案是否還在維護。
原始 Clash 核心的誕生與停止維護
最早的 Clash 是一個用 Go 語言編寫的規則代理工具,核心能力是按網域名稱、IP 段、GeoIP 等條件把流量分流到不同出口,並支援 Shadowsocks、VMess、Trojan 等多種協定的統一管理。它的設計思路是把「規則引擎」和「協定實作」解耦:設定檔裡寫規則,核心負責比對和轉發,使用者不需要關心底層交握細節。這套架構後來被幾乎所有 Clash 系用戶端沿用,是理解整個生態的起點。
原始儲存庫在維護多年後被作者封存,不再接受新特性提交,也不再修復新出現的相容性問題。對一般使用者而言,直接的影響是:如果繼續使用基於這個核心的舊版用戶端,遇到新協定不支援、新系統版本適配問題時,不會再有官方更新來解決。這也是社群分支大量出現的直接原因——核心能力沒有消失,只是需要新的維護者接手。
提示:「核心封存」不等於「無法使用」,已經下載好的舊版本仍能運行,但長期來看會逐漸落後於系統與協定的更新節奏,建議優先選擇仍在活躍維護的分支。
Clash Premium 與開源版的分野
在原始專案發展中期,作者曾推出過閉源的 Premium 核心,加入了 TUN 模式、更完整的規則訂閱、腳本擴充等進階能力,與完全開源的基礎版並行存在。這一段歷史造成了後續社群分支的兩個方向:一部分專案專注在開源基礎上補齊 Premium 時代的功能(比如自己實作 TUN 支援),另一部分則圍繞如何整合、複刻這些進階特性展開。
這也是為什麼現在市面上能看到「功能幾乎一樣、但程式碼來源不同」的多個用戶端——它們各自在開源生態的不同分支上,把 Premium 時代留下的功能需求重新實作了一遍。對使用者來說,不需要糾結歷史細節,只需要確認目前使用的版本是否支援 TUN 模式、規則訂閱、腳本策略這幾項關鍵能力即可。
mihomo 核心:社群延續的主線
原始核心封存後,社群裡活躍度最高、更新最頻繁的延續專案最終發展並更名為 mihomo。它在功能上完整涵蓋了原有的規則比對、協定支援,並持續跟進新協定(如 Hysteria2、TUIC 等)和系統層適配(如 macOS/Windows 的 TUN 權限模型變化)。目前絕大多數仍在積極更新的 Clash 系 GUI 用戶端,底層呼叫的都是 mihomo 核心,而不是最初那個已封存的版本。
理解這一點很重要:很多用戶端介面上仍然沿用「Clash」這個名字做產品標識,但實際運行的核心早已切換到 mihomo。判斷一個用戶端是否跟得上協定更新,本質上是判斷它綁定的核心版本更新頻率,而不是看介面上寫的品牌名字。
| 階段 | 關鍵專案 | 狀態 |
|---|---|---|
| 早期 | 原始 Clash 核心 | 已封存,不再更新 |
| 過渡期 | Clash Premium(閉源) | 歷史版本,不再迭代 |
| 目前主線 | mihomo 核心 | 活躍維護,主流用戶端底層 |
GUI 用戶端譜系:誰在用什麼核心
核心之上是各家 GUI 用戶端,它們負責介面、訂閱管理、系統代理設定這些使用者直接接觸的部分,底層則打包呼叫某個版本的核心。梳理清楚這一層關係,才能判斷一個用戶端「新不新」。
- Clash for Windows(俗稱 CFW):早期最流行的桌面用戶端之一,隨著原始核心停止維護,該專案本身也進入停更狀態,不建議新使用者繼續選擇。
- Clash Verge / Clash Verge Rev:基於 Tauri 框架的輕量桌面用戶端,原專案沉寂後由社群以 Rev(revive,復興)分支延續,持續跟進 mihomo 核心更新,是目前 Windows/macOS/Linux 上活躍度較高的選擇之一。
- ClashX / ClashX Meta:macOS 平台上歷史悠久的用戶端,後續版本同樣轉向以 mihomo 為底層核心。
- FlClash:用 Flutter 編寫的跨平台用戶端,介面在 Windows、macOS、Android 上保持一致,同樣基於 mihomo 核心構建。
- Clash Plus:iOS 平台上透過 App Store 發佈的用戶端,遵循 iOS 系統的網路擴充與 VPN 權限模型,介面針對觸控螢幕和小螢幕做了專門適配。
可以看到,這些用戶端的關係不是「誰抄誰」,而是同一套核心能力在不同平台、不同技術堆疊下的介面實作。選擇哪一個,更多取決於作業系統、介面偏好和更新頻率,而不是糾結「正統與否」。
如何判斷一個 Clash 相關專案是否仍在維護
面對一堆相似的專案名字,與其去追溯完整歷史,不如掌握幾個實用的判斷方法:
- 看更新時間
近幾個月內是否有新版本發布,是最直接的訊號。長期停更但仍能下載的版本,大多只適合臨時應急使用。
- 看核心綁定版本
用戶端設定或關於頁面通常會標註綁定的核心版本號,可以對照是否為較新的 mihomo 版本。
- 看協定支援範圍
如果新出現的代理協定在用戶端裡完全找不到對應選項,大概率是核心版本偏舊。
- 看系統適配情況
作業系統升級後(尤其是 macOS 的網路擴充權限、Windows 的 TUN 驅動簽章要求),用戶端是否同步做了適配,也是維護活躍度的體現。
注意:專案名字裡帶「Clash」不代表一定活躍維護,也不代表功能落後;判斷標準始終是更新記錄和核心版本,不是名字本身。
對於日常使用而言,不需要成為開源歷史專家,只需要在下載頁選擇目前仍在積極更新的用戶端版本,配合有效的訂閱連結,就能獲得規則分流、TUN 模式等完整能力。技術選型的細節留給專案維護者,一般使用者關心的其實只是「穩定好用、跟得上系統更新」這兩點。