Clash 開源生態專案關係圖：核心分支、桌面用戶端與行動版實作

搜尋 Clash 時，常會同時看到 Clash、Clash Meta、mihomo、Clash Verge Rev、Clash Nyanpasu、FlClash、OpenClash 等名稱。它們並不是同一個程式的不同安裝套件，也不一定由同一個團隊維護。有些專案提供代理核心，有些只負責圖形介面，另一些則面向路由器、Android 或特定桌面系統。

理解這些專案，關鍵不是先記住名稱，而是先判斷它位於哪一層：負責處理連線的核心、負責操作設定的用戶端、負責系統接管的平台元件，還是負責下發節點與規則的訂閱服務。只要分清層級，版本選擇、設定相容性與故障定位都會直接許多。

先從四個層次拆解 Clash 生態

一套能實際運作的 Clash 環境，通常由多個部分組合而成。名稱中帶有 Clash，不代表一定包含原版 Clash 核心；名稱中沒有 Clash，也不代表無法讀取常見的 Clash 設定。各專案更像零件組合，而不是單一產品的版本序列。

訂閱與本機設定
        ↓
圖形用戶端 / Web 控制面板
        ↓
Clash 系列核心：Clash、Clash Meta、mihomo
        ↓
系統代理 / TUN / 路由器轉發
        ↓
目標網路

第一層：訂閱與設定

訂閱網址通常會回傳 YAML 設定，內容可能包含代理節點、策略群組、分流規則、DNS 設定與規則集引用。訂閱服務不等於用戶端，也不等於核心。用戶端只是定期下載並管理這些設定，真正解析設定與處理連線的是核心。若訂閱內容使用某個分支專屬的欄位，切換到較舊核心時就可能發生解析錯誤。

第二層：用戶端與控制面板

桌面用戶端通常提供訂閱更新、代理群組切換、連線檢視、日誌顯示、系統代理開關與 TUN 管理。它可能內建一個核心，也可能允許切換核心檔案。Web 控制面板則透過外部控制介面連接核心，負責顯示狀態，不直接承擔資料轉發。

第三層：代理核心

核心負責監聽連接埠、解析 DNS、比對規則、選擇策略群組、建立代理連線並輸出日誌。同一個圖形用戶端若替換不同核心，可用欄位與執行行為也會改變。因此排查問題時，應同時記錄用戶端版本與核心版本，不能只寫「Clash 最新版」。

第四層：系統接管

系統代理只會影響遵循作業系統代理設定的應用程式。TUN 模式會建立虛擬網路介面，可涵蓋更多不讀取系統代理的程式。路由器部署則透過防火牆、策略路由與 DNS 轉發接管區域網路裝置。三種入口最終都能將連線交給核心，但權限要求、DNS 路徑與排障方法各不相同。

原版 Clash、Clash Meta 與 mihomo 的分支關係

原版 Clash 是早期生態的核心基礎，確立了 YAML 設定、規則比對、策略群組與外部控制介面等常見結構。大量桌面用戶端、路由器外掛與訂閱範本都圍繞這些介面建立。原版儲存庫停止持續維護後，生態並未整體停擺，而是轉向仍在維護的分支與相容實作。

Clash Meta 最初以原版 Clash 分支的形式發展，擴充了代理協定、規則能力、DNS 行為、TUN 支援與設定欄位。之後專案名稱逐步改為 mihomo。現在看到「Meta 核心」與「mihomo 核心」時，通常是在描述同一條演進路線的不同階段，而不是兩個需要同時安裝的獨立核心。

mihomo 對常見 Clash 設定保持高度相容，但相容不代表所有欄位都能無條件雙向遷移。使用規則集提供者、特定 DNS 選項、新協定參數、流量嗅探或擴充規則類型時，應以目標核心目前的文件為準。將 mihomo 設定直接交給舊版原始核心，最常見的結果是未知欄位、策略群組引用失敗或規則提供者載入失敗。

桌面用戶端是外殼，不是核心名稱的同義詞

Windows、macOS 與 Linux 使用者通常會先接觸圖形用戶端。用戶端將設定檔、核心程序、系統代理與系統匣選單整合在同一個介面中，但它與核心仍屬於不同層次。用戶端更新可能只修改介面與平台整合；核心更新則可能改變協定、DNS 或規則行為。發布說明若分別列出應用程式版本與核心版本，正是這種分層的直接體現。

Clash Verge Rev

Clash Verge Rev 屬於跨平台桌面用戶端，常見於 Windows、macOS 與 Linux。它以 mihomo 為核心，提供訂閱管理、策略切換、系統代理、TUN、連線記錄與日誌介面。名稱中的 Rev 表示社群延續專案，不能與歷史上名稱相近但維護狀態不同的專案混為一談。

這類用戶端適合需要以圖形介面管理多個設定的桌面環境。安裝時除了作業系統，還要核對處理器架構，例如 Windows 的 x64 與 ARM64、macOS 的 Intel 與 Apple 晶片。架構不相容屬於安裝套件選擇問題，與訂閱是否有效無關。

Clash Nyanpasu

Clash Nyanpasu 同樣位於桌面圖形層，提供設定管理、核心控制與系統整合。它與 Clash Verge Rev 可以使用相近的訂閱內容，但介面實作、設定儲存、升級流程與平台細節不同。兩者通常是替代關係，不需要為了「補足功能」而同時執行。

ClashX 系列名稱

macOS 生態中長期存在 ClashX、ClashX Pro、ClashX Meta 等相近名稱。它們的維護來源、核心組合與授權方式不完全相同。看到名稱後，仍應檢查儲存庫來源、最後發布版本、核心類型與支援的 macOS 架構。僅憑「X」或「Meta」字樣，無法判斷專案是否仍適合目前的系統。

在桌面用戶端之間遷移時，不建議直接複製整個應用程式資料目錄。目錄中除了 YAML，還可能包含資料庫、視窗狀態、服務權限資訊、系統代理備份與舊核心檔案。更穩定的做法是保留訂閱網址與確認過的本機覆寫規則，在新用戶端中重新匯入，再逐項恢復 TUN、DNS 與開機啟動設定。

行動版、路由器與 Web 面板的實作差異

行動版專案不僅要封裝核心，還必須遵守系統提供的 VPN 介面與背景執行限制。Android 用戶端通常會透過本機 VPN 服務將應用程式流量送入核心，因此狀態列會顯示 VPN 連線。此處的 VPN 是系統流量入口，不表示訂閱節點一定採用傳統 VPN 協定。

Android 用戶端

Clash Meta for Android 曾是常見的 Meta 系列 Android 實作，許多舊教學仍使用它的介面截圖。判斷是否繼續使用時，應查看專案維護狀態與核心更新時間。FlClash 等跨平台專案也能在 Android 上執行，並採用現代 Clash 系列核心處理設定。不同應用程式的資料目錄與本機備份格式通常不通用，但標準訂閱網址可以重新匯入。

在 Android 上若只有瀏覽器可用、部分應用程式卻無法連線，應檢查應用程式分流、繞過清單、VPN 權限、省電限制與 IPv6 路徑。若所有網域都失敗，應優先查看 DNS 日誌與設定解析結果。行動裝置故障不應只靠頻繁更換節點處理，因為系統限制與核心設定屬於不同層面。

iOS 與 iPadOS

iOS 平台需要透過 Network Extension 等系統機制實現網路接管，應用程式分發與背景資源也受到平台規則約束。市面上有些網路工具能讀取部分 Clash 風格設定或訂閱，但名稱、核心與設定相容範圍各不相同，不能只因支援策略群組，就認定它屬於原版 Clash 專案。

匯入前應確認應用程式支援的是完整 Clash YAML、訂閱轉換後的節點清單，還是自有設定格式。若訂閱中使用 mihomo 專有規則與 DNS 欄位，行動版應用程式可能會忽略、轉換或拒絕這些內容。此時應為目標應用程式準備對應格式，而不是反覆匯入同一份桌面設定。

OpenClash 與路由器部署

OpenClash 是面向 OpenWrt 環境的管理與整合專案，負責下載並啟動核心、產生執行設定、接入防火牆、處理 DNS 轉發並提供管理頁面。實際流量仍由所選核心處理。OpenClash、mihomo 與 OpenWrt 分別對應管理外掛、代理核心與路由器作業系統，三者不能互相取代。

路由器部署比桌面用戶端多出區域網路轉發、策略路由、透明代理與 DNS 劫持等環節。用戶端顯示節點可用，不代表路由器路徑一定正確。出現區域網路裝置無法存取、中國大陸網域解析異常或部分裝置反覆重新連線時，應依序檢查核心日誌、DNS 上游、IPv4 與 IPv6 規則、防火牆鏈及旁路由閘道設定。

Web 控制面板

Yacd、MetaCubeXD 這類 Web 面板會透過控制介面讀取代理群組、連線與日誌。它們是操作介面，不是代理核心。關閉瀏覽器頁面通常不會停止代理服務；反過來，面板能開啟也不代表核心已正確接管流量。面板連線失敗時，應檢查控制位址、監聽範圍、驗證金鑰與防火牆，而不是修改節點協定。

為什麼同一份訂閱在不同專案中的表現不同

訂閱能否匯入，只代表用戶端取得一段內容；真正能否執行，還要經過設定解析、資源下載、DNS 初始化、監聽連接埠建立與系統接管。不同專案在這些階段採用的預設值不盡相同，因此同一份訂閱在兩台裝置上可能得到不同結果。

1. 核心版本不同：較新的規則類型、協定參數或 DNS 欄位可能不被舊核心識別。
2. 用戶端覆寫不同：用戶端可能自動修改連接埠、控制介面、TUN、DNS 或設定目錄。
3. 規則資源不同：遠端規則集下載失敗後，策略可能缺少關鍵比對項目，日誌中通常會出現 provider 錯誤。
4. 系統入口不同：桌面端使用系統代理，行動端使用本機 VPN，路由器使用透明代理，接管範圍自然不同。
5. DNS 路徑不同：系統 DNS、核心 DNS、瀏覽器安全 DNS 與路由器轉發可能同時存在，最終查詢不一定會進入同一個解析器。
6. 策略選擇未同步：設定中的策略群組預設項目可能與舊裝置儲存的選擇不同，匯入後應重新核對目前策略。

排查時可以先採用最小路徑：確認設定能夠解析，選擇一個已知可連線的節點，暫時關閉額外覆寫，只保留必要的 DNS 與規則，然後測試核心監聽連接埠。核心直連測試通過後，再開啟系統代理或 TUN。如此可以區分問題位於設定層、核心層還是系統接管層。

檢查順序：
1. 訂閱是否成功回傳 YAML
2. 核心是否完成設定解析
3. 代理與規則資源是否載入
4. 本機監聽連接埠是否建立
5. 系統代理或 TUN 是否接管
6. DNS 查詢是否進入預期路徑
7. 規則是否命中預期策略群組

日誌層級可先設為 info，觀察設定載入、DNS、規則集與連線錯誤。只有在需要追蹤具體請求時，才暫時提高日誌詳細程度，避免大量重複記錄掩蓋關鍵錯誤。調整規則、DNS 與 TUN 時，每次只修改一個變數，並保留可還原的原始設定。

依維護狀態、平台與設定需求選擇專案

選擇 Clash 系列專案時，首先確認維護狀態，其次確認平台與架構，最後確認所需功能是否由對應核心提供。專案名稱相近、搜尋結果排名靠前或舊教學數量多，都不能取代這些檢查。

如果目標只是讓桌面瀏覽器與一般應用程式使用代理，選擇維護活躍的桌面用戶端通常更省步驟。如果需要接管遊戲、命令列程式或不遵循系統代理的軟體，再評估 TUN。若希望整個區域網路統一分流，應考慮路由器方案，但要預留防火牆與 DNS 排障能力。伺服器環境通常不需要桌面外殼，直接執行 mihomo 並交由 systemd 管理會更清晰。

設定遷移應以標準 YAML、訂閱網址與自行建立的規則為核心，而不是依賴某個用戶端的內部資料庫。核心專有欄位要單獨記錄，確保下一個專案確實支援。遇到舊教學時，先核對教學中的專案名稱、發布時間與核心階段，再決定哪些步驟仍然適用。

關係圖的最終判斷方法

看到新的專案名稱時，可以用四個問題定位：它是否包含代理核心；包含的是原版 Clash、舊稱 Meta 還是 mihomo；它透過系統代理、TUN、本機 VPN 還是路由器防火牆接管流量；它的設定是標準 Clash YAML、擴充欄位還是獨立格式。四項答案明確後，專案在生態中的位置基本就能確定。

Clash 生態的延續仰賴多個獨立專案協作。mihomo 負責現代核心能力，桌面與行動用戶端負責平台互動，OpenClash 負責路由器整合，Web 面板負責遠端控制，訂閱與規則專案負責設定資料。它們可以組合，但發布節奏、維護團隊與相容邊界各自獨立。選擇時按層級核對，排障時沿資料路徑逐段檢查，比把所有程式統稱為「Clash 用戶端」更準確。