Clash 開源生態梳理:原版核心、mihomo 與各圖形客戶端的關係與選擇
從原版 Clash 核心到 mihomo 的演進,再到 Clash Verge Rev、FlClash 等圖形客戶端各自的定位,一張脈絡圖講清專案之間的繼承關係與目前的選型建議。
A-01專案脈絡的起點:原版 Clash 核心
要看懂現在市面上五花八門的 Clash 類客戶端,得先回到脈絡的起點。最早的 Clash 是一個用 Go 語言編寫的規則化代理核心,只提供命令列程式與一份 YAML 設定檔,負責解析訂閱、比對分流規則、管理代理節點,本身不帶任何圖形介面。這個核心奠定了整套生態的基礎語法:proxies 宣告節點、proxy-groups 組織策略組、rules 定義分流順序,後續幾乎所有分支與客戶端都延續了這套設定結構,這也是為什麼不同來源的訂閱連結大多能在不同客戶端之間通用。
原版核心的開發在 2023 年年中之後陷入停滯,倉庫長期沒有新版本發布,一些較新的協定特性與規則寫法也沒有跟上。這不代表原版核心「不能用」,很多舊有設定檔仍能正常運作,但意味著它已經不再是社群維護的主線,新特性、協定支援與安全性修正都不會再落到這個版本上。
A-02分支演進:Clash Meta 與 mihomo 的關係
原版核心維護放緩之後,社群裡出現了多個分支專案,其中影響最大的是 Clash Meta。這個分支在原版基礎上補上了 TUN 模式的穩定實作、更完整的規則語法(如 RULE-SET、行程層級規則)、更多協定支援(如 Hysteria、TUIC 等新型代理協定),迅速成為大多數圖形客戶端底層預設呼叫的核心。
Clash Meta 後來正式改名為 mihomo,這不是另起爐灶重寫一個新專案,而是同一條開發脈絡的延續與品牌重新命名。目前主流圖形客戶端底層普遍搭載的是 mihomo 核心,而不是原版 Clash 核心,這也是為什麼很多客戶端設定頁裡看到的「核心版本」一欄,其實顯示的是 mihomo 的版本號,而不是「Clash」字樣。理解這層關係,能幫助你看懂客戶端更新日誌裡出現的「升級核心到 mihomo x.x.x」這類描述,它指的正是底層引擎的迭代,而不是客戶端介面本身的變動。
換個角度說,mihomo 相當於整套生態目前實際在運轉的「心臟」,各個圖形客戶端則是包裹在這顆心臟外面的「外殼」,負責把核心的能力轉化成使用者可以點選、可以查看的介面操作。搞清楚這一點後再去看後面的客戶端對比,會容易理解得多。
A-03圖形客戶端盤點:介面各異,核心趨同
圖形客戶端解決的是設定檔編輯門檻高的問題,把訂閱匯入、節點切換、規則查看這些操作做成可視化介面。不同客戶端在介面框架、操作習慣、附加功能上差異很大,但底層呼叫的核心基本都指向 mihomo 或其早期形態。以下按幾類典型客戶端說明各自定位。
| 客戶端類型 | 典型代表 | 底層核心 | 定位說明 |
|---|---|---|---|
| 跨平台桌面客戶端 | Clash Verge Rev | mihomo | 基於 Tauri 框架構建,介面輕量,設定項暴露較完整,適合需要精細調整參數的使用者 |
| 行動端客戶端 | FlClash | mihomo | 跨 Android/桌面的 Flutter 客戶端,介面風格統一,行動端操作習慣友善 |
| macOS 原生客戶端 | ClashX Meta 系列 | Clash Meta / mihomo | 貼合 macOS 選單列互動習慣,操作路徑簡短 |
| 已停止維護的舊版客戶端 | Clash for Windows | 原版 Clash 核心 | 曾長期是 Windows 端主流選擇,專案已停止更新,不建議繼續作為長期選擇 |
需要特別提醒的是最後一類。Clash for Windows 在很長一段時間裡幾乎是 Windows 平台的代名詞,但這個專案已經停止維護,倉庫不再合併新的提交,底層核心也停留在較早版本。繼續使用它不會馬上「壞掉」,但會逐漸遇到新協定節點無法識別、部分規則語法不支援等問題,而且缺乏安全性維護也是長期風險。目前 Windows 平台上活躍維護、社群回饋較多的替代選擇,集中在以 mihomo 核心為底層的新一代客戶端上。
為什麼介面不同,設定檔卻能互通
這背後正是前面提到的繼承關係在發揮作用:大多數客戶端呼叫的都是同一套 mihomo 核心解析邏輯,設定檔遵循的是同一套 YAML 語法規範。所以同一份訂閱連結,理論上可以在 Clash Verge Rev、FlClash 等不同客戶端之間切換使用,不需要重新產生訂閱,只是介面呈現方式、可調整的參數選項數量有所差異。也正因為如此,選擇客戶端時更多是在權衡介面風格與平台相容性,不需要過度擔心「設定能不能用」的問題。
A-04目前選型建議:按平台與需求劃分
結合前面的脈絡梳理,提供幾條實際選型的參考方向:
- Windows 與 macOS 桌面端優先考慮以 mihomo 核心為底層、仍在活躍更新的客戶端,介面偏輕量、設定項暴露完整的選項更適合需要手動調整規則的使用者。
- Android 平台優先選擇明確標註支援
VpnService且持續維護的客戶端,安裝後留意系統省電策略是否會影響背景連線穩定性。 - iOS 平台由於系統限制,客戶端形態與桌面/Android 有所不同,選擇時以官方管道發布、更新記錄清晰的版本為準。
- 如果手上的客戶端說明頁仍標註「基於原版 Clash 核心」且已經很久沒有更新,建議評估遷移到以 mihomo 為底層的替代客戶端,遷移過程通常只需要重新匯入現有訂閱連結。
- 不必糾結「客戶端越新越好」,穩定性、社群回饋量、更新頻率三者綜合判斷比單看版本號更可靠。
遷移時的注意事項
從一個客戶端切換到另一個客戶端時,大部分情況下只需要重新加入訂閱連結即可完成遷移,不需要手動重寫規則。但如果原有設定裡包含了自訂的策略組、腳本規則或特殊參數,遷移後建議先打開客戶端的設定查看介面,核對規則條數與策略組數量是否與遷移前一致,避免因為語法解析差異導致個別規則被靜默忽略。
curl -x http://127.0.0.1:7890 https://www.gstatic.com/generate_204 -I遷移完成後,可以用上面這條命令驗證本機代理埠是否正常回應,回傳 HTTP/1.1 204 No Content 即表示新客戶端的代理服務已經正常接管流量,再逐一檢查策略組切換與規則比對是否符合預期。
A-05常見疑問補充
mihomo 和 Clash Meta 是同一個東西嗎?
是同一條開發脈絡。Clash Meta 是早期分支名稱,後來正式改名為 mihomo,並延續了原有的版本迭代,不是重新起步的新專案。
原版 Clash 核心還能不能繼續用?
能運作,但已不再有新版本更新,協定支援與規則語法會逐漸落後於活躍維護的分支,長期使用建議遷移到以 mihomo 核心為底層的客戶端。
換客戶端需要重新設定規則嗎?
大多數情況下只需重新匯入訂閱連結,底層設定語法基本通用。如果原設定裡有自訂規則或腳本,遷移後建議核對一遍規則條數是否一致。
如何判斷一個客戶端是否還在活躍維護?
查看專案倉庫最近一次發布版本的時間與更新日誌內容,是比軟體知名度更直接可靠的判斷依據。
按圖操作:下載 Clash 客戶端
理清核心脈絡後,前往下載頁選擇以 mihomo 為底層、活躍維護的對應平台客戶端。