2026-06-15 生態選型 預計閱讀 9 分鐘

Clash、mihomo、Verge Rev 是什麼關係:開源專案譜系一次理清

原版 Clash 封存後,核心與圖形客戶端各自演化出多條分支。本文梳理 mihomo 核心與 Verge Rev、FlClash、Nyanpasu 等 GUI 專案的繼承關係,幫助讀者按平台選對客戶端。

很多人第一次接觸 Clash 生態時會被搞混:搜尋「Clash 下載」能找到十幾個不同名字的軟體,介面各不相同,GitHub 儲存庫也分散在不同帳號下。這種混亂不是偶然,而是有明確的歷史脈絡——原作者封存儲存庫之後,社群接力維護形成了今天的格局。理清這條脈絡,才能明白為什麼某些客戶端更新頻繁、某些已經停止更新,以及不同平台該優先選哪一個。

SEC-01

原版 Clash 封存:分裂的起點

最初的 Clash 專案由 Dreamacro 開發,使用 Go 語言編寫,核心思路是「基於規則的流量分流」:設定檔裡寫明網域或 IP 段該走哪個代理節點,核心按規則逐條比對後轉發流量。這套設計被後續所有分支完整繼承,是理解整個生態的基礎。

2023 年前後,原始儲存庫因為一些外部原因被封存(archive),儲存庫轉為只讀狀態,不再接受新的提交。這對當時依賴 Clash 核心的所有圖形客戶端都是一次衝擊——核心不再更新,意味著新的協定支援、新的規則語法、安全修復都無法進入官方版本。社群隨即出現了兩條應對路徑:

  • 繼續使用舊核心:部分客戶端在封存前的最後版本基礎上原地凍結,不再跟進新特性,長期使用會逐漸遇到協定不相容問題。
  • 切換到社群維護的分支核心:這是目前活躍專案普遍採用的路線,也是本文重點介紹的 mihomo。
NOTE

選擇客戶端時,判斷依據不是「名字裡有沒有 Clash 字樣」,而是它底層依賴的核心是否仍在積極維護。這一點比介面美觀程度更影響長期可用性。

SEC-02

mihomo:社群接力的核心引擎

mihomo 是原 Clash Meta 專案更名後的延續,由社群團隊維護,目前是最活躍、更新最頻繁的開源核心。它在原版 Clash 的規則分流基礎上,補齊並強化了以下能力:

  • TUN 模式:在系統網路層建立虛擬網卡,實現全域流量接管,不再依賴單個應用程式手動設定代理,對不支援系統代理設定的程式同樣生效。
  • 更完整的協定支援:VMess、VLESS、Trojan、Hysteria、Hysteria2、TUICon 等協定逐步補齊,跟進速度明顯快於停止更新前的原版核心。
  • 規則集擴充:支援 GEOSITE、GEOIP 等遠端規則集格式,方便訂閱方按地區與服務歸類維護規則,不需要客戶端手動列舉每一條網域。
  • 腳本與進階策略:提供 Script 類規則和更靈活的策略群組嵌套能力,滿足複雜分流場景。

需要強調的是,mihomo 本身是一個沒有圖形介面的核心程式,日常使用的各類客戶端(Verge Rev、FlClash、Nyanpasu 等)都是在 mihomo 之上包裝出的圖形外殼,負責設定管理、節點顯示、訂閱匯入、流量統計等互動層功能,真正執行代理與分流邏輯的仍是核心本身。

mihomo

核心與協定

原 Clash Meta 更名後的社群維護核心,負責協定解析、規則比對與流量轉發,是當前主流圖形客戶端共同依賴的底層引擎。

SEC-03

圖形客戶端各自的定位

核心統一之後,不同圖形客戶端的差異主要體現在開發語言、介面框架和目標平台上。下面按專案梳理各自特點,方便按使用場景挑選。

Verge Rev(clash-verge-rev)

使用 Tauri 框架開發,前端介面基於 Web 技術堆疊,後端用 Rust 編寫,體積較傳統 Electron 客戶端更輕。它是目前 Windows、macOS、Linux 三端更新最規律的桌面客戶端之一,設定檔採用可視化編輯與 YAML 原始碼編輯雙模式切換,方便同時滿足新手和習慣手寫設定的使用者。策略群組、連線詳情、日誌面板等資訊顯示也比較完整。

FlClash

基於 Flutter 框架開發,最大的特點是跨平台程式碼高度複用——同一套介面程式碼可以編譯出 Windows、macOS、Linux、Android 多個平台的客戶端,視覺風格在各平台上保持一致。對於需要在多台不同系統裝置間切換、又希望操作習慣統一的使用者,這類客戶端能減少重新適應介面的成本。

Nyanpasu(clash-nyanpasu)

同樣基於 Tauri 框架,介面設計上更強調動效與主題自訂,支援設定檔的可視化管理與訂閱自動更新。它與 Verge Rev 在技術選型上接近,但介面風格與部分互動細節走了不同路線,適合偏好個性化外觀的使用者。

行動端與其他平台

Android 平台除 FlClash 外,還有多個基於 mihomo 核心的獨立客戶端,普遍支援 TUN 模式下的全域代理和按應用程式分流。iOS 平台的選擇相對有限,多數客戶端透過 App Store 發行,介面風格更貼近系統原生設計規範,設定管理方式也更強調訂閱連結的一鍵匯入。

SEC-04

設定檔與訂閱:跨客戶端通用

由於所有主流客戶端最終都呼叫 mihomo 或相容核心解析設定,YAML 格式的設定檔和訂閱連結在這些客戶端之間基本可以直接互通。一份標準設定通常包含以下幾個核心欄位:

port: 7890
socks-port: 7891
mode: rule
log-level: info
proxies:
  - name: "節點示例"
    type: vmess
    server: example.com
    port: 443
proxy-groups:
  - name: "自動選擇"
    type: url-test
    proxies: ["節點示例"]
rules:
  - DOMAIN-SUFFIX,example.com,自動選擇
  - MATCH,DIRECT

這意味著從一個客戶端遷移到另一個客戶端時,通常不需要重新設定代理節點,直接匯入原有的訂閱連結或本機設定檔即可繼續使用。真正需要注意的差異集中在客戶端專屬的介面設定項目上,例如系統代理開關方式、TUN 模式的啟用入口、日誌保留策略等,這些屬於外殼層功能,不會隨核心切換而自動遷移。

SEC-05

按平台選擇客戶端的實用建議

  1. 確認平台涵蓋範圍

    先明確自己需要涵蓋的系統:僅 Windows 單一平台,還是 Windows、macOS、Android 多端同時使用。多平台場景優先考慮同一專案的跨平台版本,減少設定檔在不同客戶端間轉換的麻煩。

  2. 檢查專案更新頻率

    在 GitHub 儲存庫頁面查看最近一次發布(Release)的時間,長期無更新的客戶端即便介面正常開啟,也可能因核心過舊而無法解析新的協定或規則語法。

  3. 驗證 TUN 模式支援

    如果需要全域流量接管而不是單一應用程式代理,確認目標客戶端明確支援 TUN 模式,並在系統層面完成對應的權限授予(如 Windows 上的管理員權限、macOS 上的網路擴充功能授權)。

  4. 保留原設定檔

    更換客戶端前匯出或備份現有訂閱連結與本機規則,方便新客戶端安裝完成後直接匯入,避免重新整理節點資訊。

WARN

不同客戶端對規則語法的擴充欄位支援程度略有差異,例如部分腳本類規則或較新的策略群組類型並非所有客戶端都完整支援。切換客戶端後建議先用簡單設定測試連線是否正常,再逐步匯入完整規則集。

SEC-06

小結:認準核心,再挑外殼

整理下來可以得到一條清晰的判斷路徑:Clash 確立了基於規則的分流架構 → mihomo 作為社群接力的核心持續實現協定與功能更新 → Verge Rev、FlClash、Nyanpasu 等圖形客戶端在 mihomo 之上建構各自的介面與互動體驗。選擇客戶端本質上是在選擇一層介面外殼,只要核心相同,設定檔通用,不同客戶端之間的遷移成本很低。真正值得花時間比較的,是介面是否符合自己的操作習慣、目標平台是否被穩定支援,以及專案是否仍在活躍維護。

下載客戶端