Clash 開源生態解析：mihomo 核心與各圖形化用戶端的分工

核心、用戶端與設定檔的三層關係

Clash 生態中的名稱分屬不同層次：mihomo 是處理網路流量的核心；Clash Verge Rev、FlClash 是提供操作介面的用戶端；YAML 則是描述節點、策略群組與規則的設定格式。選擇軟體前，先釐清這三層，才能判斷「是否支援某項功能」該查核心文件，還是用戶端設定。

核心可以不透過桌面視窗獨立執行，例如在伺服器上讀取 YAML 檔案並開啟本機代理連接埠。用戶端則將匯入設定、啟動程序、變更系統設定等操作包裝成按鈕。兩者常一起安裝，因此使用者容易把介面版本誤認為核心版本。

原版 Clash、Clash Meta 與 mihomo 的發展沿革

2023 年 11 月，原版 Clash 與多個相關專案的公開程式碼儲存庫陸續遭到刪除、封存等變動，原有的上游維護鏈中斷。歷史資料中的開源 Clash、Clash Premium 和圖形化用戶端也不是同一種發布項目：Clash Premium 是曾提供額外功能的閉源核心分支，Clash for Windows 則是用戶端。

Clash Meta 是以 Clash 為基礎發展的開源分支，後來改名為 mihomo。因此，舊教學中的「Meta 核心」與新文件中的「mihomo 核心」有專案沿革上的關係，並非兩套毫無關聯的設定系統。部分應用程式名稱、儲存庫名稱與訂閱入口仍保留 Meta 字樣；名稱沒有同步變更，不代表其內部使用哪個版本的核心。

設定相容性須逐項確認

• 基本結構：proxies、proxy-groups、rules 等欄位沿用 Clash 系列的組織方式，但不代表所有版本都支援每個子欄位。
• 新增協定：例如 type: vless 或 type: hysteria2，須確認實際使用的核心已實作對應功能，不能只因用戶端名稱含有 Clash 就認定支援。
• 延伸功能：流量嗅探、DNS 策略與 TUN 相關欄位可能隨版本演進而變動，請對照目前執行中的核心文件。
• 其他生態系：sing-box JSON 不屬於 Clash YAML。即使用戶端介面相似，也不能因此直接互換設定檔。

稱 mihomo 為「接棒者」，指的是社群使用情況與功能發展的延續，不代表它是原專案官方發布的升級套件。舊用戶端也不會只因更換訂閱網址，就自動取得新核心的協定支援。

Verge Rev、FlClash 與 Android 用戶端的分工

以下比較著重於專案定位，不以單一固定版本號代表持續變動的發布狀態。各平台是否提供可安裝套件、套件內使用哪個核心，請以對應專案的發行說明為準；同一專案在不同發布管道的更新時程也可能不同。

桌面用戶端：系統整合方式是主要差異

即使 Verge Rev 與 FlClash 使用相近版本的 mihomo，實際體驗仍可能不同。開機啟動、系統匣選單、系統代理還原、服務安裝、設定覆寫與錯誤提示，主要都屬於用戶端層面的功能。比較時，應觀察「結束程式後代理是否恢復」「更新訂閱後本機規則是否保留」等具體行為，而不只看節點清單的排版。

Android 用戶端：VPN 流量接管與背景執行限制

Clash Meta for Android 這類應用程式通常透過 Android 的 VPN 介面接管流量，並需要使用者授權。這裡的 VPN 介面指的是系統接管流量的機制，不代表訂閱服務一定使用傳統 VPN 協定。Android 通常只允許一個一般 VPN 服務同時啟用，因此可能與其他 VPN 型防火牆或過濾應用程式發生資源衝突。

Android 的省電限制、背景程序管理與依應用程式分流，也都是選擇用戶端時應考量的條件。能在桌面正常執行的 YAML，到了手機上仍可能需要調整監聽位址、連接埠或路由設定。支援跨平台不代表各作業系統上的行為完全相同。

流量路徑：系統代理、控制介面與 TUN

了解流量路徑，比記住應用程式圖示更有助於找出問題。常見的系統代理路徑為「應用程式遵循系統代理設定 → 本機代理監聽連接埠 → 核心比對規則 → 節點或直連出口」。不遵循系統代理設定的程式，可能根本不會經過這條路徑。

三種介面不可混為一談

• 代理監聽連接埠：供瀏覽器、命令列工具等傳送代理要求，例如範例中的 127.0.0.1:7890。
• 控制介面：供用戶端或面板查詢狀態、切換策略，例如 127.0.0.1:9090；它不是瀏覽器連線上網所用的代理連接埠。
• TUN 虛擬網卡：在系統網路層接收經路由轉送的流量，實際涵蓋範圍取決於路由、排除項目、DNS 與權限設定。

以下片段僅用來說明連接埠與控制介面的分工，並非包含節點的完整設定。連接埠數值僅供示範，不代表所有用戶端的預設值；圖形化用戶端也可能在啟動時改寫這些欄位。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090

mixed-port 可在同一個監聽連接埠接受 HTTP 與 SOCKS 代理要求。mode: rule 表示依規則處理流量，不代表系統中的每個程式都會自動使用代理。控制介面具有管理功能，應限制在可信任的範圍內；若確實需要遠端存取，也必須設定驗證方式與網路存取限制。

從訂閱到執行設定：用戶端還會處理哪些內容

訂閱下載成功，只代表用戶端取得了遠端內容。接著還要解析格式、套用本機合併或覆寫設定、產生執行用設定，再交由核心載入。訂閱來源檔案、用戶端編輯器顯示的檔案，以及核心最後使用的檔案，可能不完全相同。

兩種遠端更新方式應分開理解

1. 完整設定訂閱：遠端 YAML 可同時包含節點、策略群組與規則。更新時，用戶端如何保留本機修改，取決於其設定管理機制。
2. 節點提供者：proxy-providers 引用的遠端資源主要用來提供節點；外層設定仍須定義策略群組，以及如何使用這些節點。
3. 規則提供者：rule-providers 提供規則集，無法取代節點訂閱；規則集仍須由規則項目引用。

例如，策略群組引用了名為 工作出口 的節點，但訂閱更新後該名稱消失，設定可能無法載入，或出現選擇異常。這是設定引用關係的問題，並非用戶端視窗的顯示故障。排查時應查看產生後的設定與核心錯誤訊息，而不是一再重新安裝應用程式。

更換用戶端時，應優先保存訂閱網址、本機規則與覆寫邏輯，而不是只複製應用程式內部資料庫。尤其是腳本覆寫，不同用戶端提供的物件與執行流程可能不同；某個用戶端能執行的腳本，不代表它是 mihomo 核心的通用功能。欄位細節請參閱YAML 設定手冊。

用戶端選擇與遷移檢查步驟

選擇用戶端時，可先從作業系統、所需協定與流量接管方式三項著手。只需要瀏覽器代理的桌面使用者，可先確認系統代理路徑；若要處理更多應用程式的流量，再檢查 TUN 與服務權限。Android 使用者則應優先確認 VPN 授權、背景執行及依應用程式分流是否符合實際需求。

1. 確認平台與架構。先區分 Windows、macOS、Linux 與 Android，再核對 x64、ARM64 等安裝套件架構；Apple Silicon 與 Intel Mac 不應只憑檔名中的 macOS 就混用安裝套件。
2. 記錄兩種版本。分別從用戶端的關於頁面、核心設定或啟動記錄，確認用戶端版本與 mihomo 版本。介面入口會隨用戶端版本變動，請以實際畫面為準。
3. 先匯入，再查看記錄。先確認 YAML 解析成功，且節點與策略群組都存在，再啟用系統代理或 TUN，避免把設定錯誤誤判為網路故障。
4. 一次只啟用一條流量接管路徑。遷移時先關閉舊用戶端的系統代理、TUN 與背景服務，再啟動新用戶端，以減少連接埠占用與路由衝突。
5. 驗證實際連線。查看連線頁面中的程序、目標位址、命中規則與出口策略。節點延遲測試成功，只能表示該探測要求成功，不能證明所有應用程式的連線路徑都正常。
6. 檢查更新後的行為。手動更新一次訂閱，確認本機規則仍存在、策略群組引用有效，並確認執行中的設定使用預期的監聽連接埠。

若兩個用戶端設定了相同的 7890 監聽連接埠，後啟動的用戶端可能會回報位址已被占用；若舊用戶端結束後，系統仍指向 127.0.0.1:7890，瀏覽器可能就無法連線。這兩種情況都與遠端節點是否在線無直接關係。

常見疑問：名稱相近不代表功能相同

安裝 mihomo 後，還需要圖形化用戶端嗎？

不一定。熟悉命令列、服務管理與設定檔的使用者，可以獨立執行核心。若需要系統匣操作、訂閱管理與系統設定整合，圖形化用戶端會更方便日常使用。若兩種方式使用相同核心，協定能力主要取決於核心版本；系統整合功能則取決於用戶端的實作。

舊版 Clash YAML 可以直接匯入新用戶端嗎？

許多基本設定可以沿用，但應先載入並確認結果。檔案中的協定類型、外部資源路徑、規則目標名稱，以及用戶端注入的 DNS 或 TUN 設定都需要檢查。舊檔案能成功解析，也不代表其網路策略適合目前的裝置。

該選介面，還是選核心？

先依核心能力確認協定與規則需求，再依用戶端能力選擇操作方式。想比較平台支援、設定覆寫、背景服務與更新機制，可接著閱讀用戶端比較評測；初次使用則可依照快速入門完成匯入與驗證。分開記錄核心、介面與設定三個層次，日後升級與排查問題會更清楚。