Clash 開源生態全景:核心、GUI 客戶端與規則專案之間的關係梳理

生態地圖:四類專案如何分層

搜尋 Clash 相關資料時,經常會同時看到 Clash、Clash Meta、mihomo、ClashX、Clash Verge、subconverter、geoip 這些名字混在一起出現,新手很容易把它們當成互相競爭的軟體去比較。實際上這些專案分屬四個不同層級,各自負責不同工作,合起來才構成一套完整的分流代理方案。

第一層是核心,也就是真正處理網路連線、執行代理規則、維護連線池的背景程序,沒有圖形介面,只接受設定檔和 API 呼叫。第二層是 GUI 客戶端,負責把核心包裝成使用者可以點擊操作的應用,處理訂閱拉取、節點切換、系統代理設定、TUN 網卡管理這些互動工作。第三層是規則集與地理資料庫,提供網域與 IP 段的分類清單,供核心在分流時比對使用。第四層是轉換與面板工具,負責把不同格式的訂閱統一轉換成核心可讀的設定,或者提供網頁版的連線監控面板。

看懂這四層的依賴關係,就能明白為什麼同一台電腦上可能同時安裝了客戶端和核心兩個程序,也能明白為什麼換了一個客戶端之後規則集檔案卻不用重新下載。

核心演進鏈:從原版 Clash 到 mihomo

核心這條線是整個生態裡變化最大的部分,弄清時間線能幫助判斷目前該用哪個版本。

1. 原版 Clash

   由 Dreamacro 發起的最初版本,用 Go 語言實作,奠定了設定檔格式、代理群組、規則分流這套基礎模型。這個倉庫已經處於封存狀態,不再合併新功能,也不會修復新出現的相容性問題,但它定義的設定語法仍被後續所有分支沿用。

2. Clash Premium

   在原版基礎上補充了部分閉源特性和更完整的規則語法,曾是一段時間內功能最全的分支,但更新節奏同樣早已放緩,協定支援落後於新出現的傳輸方式。

3. Clash Meta

   社群在原版停更後接手維護,補齊了 Vision、Hysteria、TUN 模式等新協定與新特性的支援,一度是更新最活躍的分支,大量 GUI 客戶端底層切換到了這個版本。

4. mihomo

   Clash Meta 後續更名延續的專案,倉庫遷移、命名調整之後仍由原團隊和社群持續提交程式碼,新增協定、修復漏洞、適配新系統版本的工作都在這裡進行。目前主流 GUI 客戶端底層核心基本都已切換或正在切換到 mihomo。

換句話說,查看一個客戶端「用的是什麼核心」,本質上是在確認它接的是已經停止更新的舊分支,還是仍在持續維護的 mihomo。這直接決定了新出現的代理協定能不能用、系統版本升級後是否還能正常觸發網路擴充權限。

GUI 客戶端誰在維護,誰已停更

GUI 客戶端這一層的更新最容易被忽視,因為介面看起來照常能打開,但底層核心可能早已停止更新。以下是幾類平台上的典型情況,具體版本以各專案發布頁為準。

iOS 是一個特例:系統政策不允許發布未簽署的可執行核心,因此 iOS 端的客戶端多數是基於類似核心思路獨立實作的應用,透過 App Store 上架,設定語法與 Clash 系相容但並非直接複用同一份核心程式碼。選擇 iOS 客戶端時,應重點看它是否支援標準的訂閱連結格式和規則語法,而不是糾結它是否「官方」。

一個實用的自我檢查方法是打開客戶端的關於頁面或設定頁,尋找「核心版本」或「core version」字樣,再和 mihomo 發布頁的最新版本號做比對,差距過大往往說明客戶端本身也很久沒有更新過依賴。

規則集與轉換工具:核心之外的必要拼圖

核心只負責「按規則執行」,規則從哪裡來是另一套專案在解決。常見的規則集專案會把全球常用網域和 IP 段按地區、按服務類型分類打包成 geosite、geoip 格式的資料檔案,核心載入後就能在設定裡直接引用分類名稱,而不需要自己維護成千上萬條網域項目。這類專案通常按固定週期更新資料,更新記錄裡能看到具體新增或調整了哪些分類。

轉換工具解決的是另一個問題:不同代理服務商提供的訂閱連結格式並不統一,有的是標準協定連結的集合,有的是自訂 JSON。轉換服務在中間做格式翻譯,把原始訂閱轉成 Clash 系設定能直接讀取的 YAML 結構,同時可以按需插入分組和規則範本。使用轉換服務時建議只使用可信來源提供的轉換介面,避免把訂閱連結提交給來源不明的第三方網站。

面板工具則是給核心的 API 介面套上一層網頁介面,用來查看目前連線、延遲測速、切換節點分組,大多數 GUI 客戶端內建的「面板」頁面本質上就是嵌入了這類開源面板專案的前端程式碼。

proxy-groups:
  - name: 自動選擇
    type: url-test
    proxies:
      - 節點A
      - 節點B
    url: http://www.gstatic.com/generate_204
    interval: 300

rule-providers:
  reject:
    type: http
    behavior: domain
    url: "規則集下載位址"
    path: ./rules/reject.yaml
    interval: 86400

上面這段設定片段展示了規則集是如何被核心引用的:核心並不關心規則資料具體如何產生,只按 rule-providers 裡指定的位址週期性拉取並載入,這正是分層設計帶來的好處——規則集專案可以獨立更新,不需要等核心發新版本。

選型建議:按依賴關係倒推該裝什麼

理解了上面的分層關係後,選型問題就變成了三步排查,而不是在一堆專案名字裡憑印象挑選。

• 先確認平台。不同系統能用的客戶端範圍不同,iOS 走 App Store 獨立生態,桌面端和安卓有更多選擇餘地。
• 再確認核心。優先選擇底層核心持續更新的客戶端,可以在設定頁或專案說明裡核對核心版本號與更新時間。
• 最後確認規則來源。如果客戶端自帶的預設規則集更新緩慢,可以在設定裡手動替換為仍在維護的規則集位址,這一步不需要更換客戶端本身。

需要額外說明的是,核心封存不代表軟體立刻無法使用,已發布的版本仍能運作,只是不會再獲得新協定支援和安全修復。對於日常使用而言,更穩妥的做法是選用底層核心仍在活躍維護的客戶端,這樣遇到新出現的傳輸協定或者系統更新導致的相容性問題時,能更快等到修復版本,而不必自己排查核心層面的問題。