Clash 開源專案關係圖：原版核心、Meta、mihomo 與各圖形介面的分工

核心、用戶端與設定檔的分工

挑選 Clash 桌面用戶端前，先釐清三個部分：負責處理連線的核心、提供設定介面的圖形用戶端，以及描述節點與規則的設定檔。名稱裡都有 Clash，不代表使用相同核心，也不代表能讀取完全相同的設定。

核心負責監聽代理連接埠、解析設定、比對規則、建立對外連線，並處理 DNS 等網路邏輯。圖形用戶端負責匯入訂閱、選擇策略群組、切換系統代理、管理背景服務及顯示記錄。設定檔則將代理節點、策略群組、規則與 DNS 設定交由核心執行。

原版 Clash、Meta 與 mihomo 的關係

原版 Clash：生態系的起點

原版 Clash 通常指 Dreamacro/Clash 專案的開源核心，以 Go 編寫，建立了廣泛使用的 YAML 設定格式與控制介面。原專案於 2023 年 11 月停止公開維護後，舊版程式與設定仍然存在，但不能把舊安裝檔視為持續更新、修正問題的現行版本。

也要區分歷史上的 Clash Premium。它不是「所有開源 Clash 核心」的統稱，也不是 mihomo 的舊名稱。部分舊教學中的功能以 Premium 為前提，不能只看到某個設定欄位，就認定原版開源核心一定支援。

Clash Meta：從原版延伸的分支

Clash Meta 由原版 Clash 程式碼發展而來，擴充了協定、DNS 與路由等功能。舊文件中的「Meta 核心」或「Clash.Meta」，通常指的是這條專案路線，而非一種獨立的訂閱格式。訂閱若標示「需要 Meta」，通常表示設定使用了原版舊核心尚未支援的功能。

mihomo：Meta 專案後續使用的名稱

Clash Meta 後來更名為 mihomo，目前常見的專案路徑是 MetaCubeX/mihomo。因此，Meta 與 mihomo 並非兩套互不相關、必須依序啟動的核心。用戶端選單、訂閱說明、檔名或教學中可能仍會出現舊名稱，辨識時應一併確認儲存庫網址與版本資訊。

核心專案演進（簡化）
Dreamacro/Clash
└─ Clash.Meta（延伸分支）
   └─ mihomo（後續名稱，MetaCubeX/mihomo）

呼叫關係（不是程式碼繼承關係）
Clash Verge Rev 等圖形用戶端
├─ 管理訂閱與本機設定
├─ 啟動、停止或重新載入 mihomo
└─ 透過控制介面讀取狀態、切換策略

這張關係圖呈現的是專案演進與執行分工，不表示不同分支的每項功能都完全對應。要確認設定能否使用，應查閱目前核心版本支援的欄位與協定，而非只看用戶端名稱裡有沒有「Clash」。

Verge Rev 等圖形用戶端如何呼叫核心

Clash Verge Rev 是桌面圖形用戶端專案，採用 Tauri 技術，與 mihomo 是各自獨立的專案。安裝檔通常會附帶核心；用戶端負責產生執行設定、啟動核心程序，再透過控制介面顯示代理群組、連線記錄與日誌。用戶端版本與核心版本各有自己的編號，升級其中一項不代表另一項也會同步更新。

1. 匯入設定：用戶端會儲存訂閱網址或本機 YAML，並讀取設定內容。
2. 整理執行參數：用戶端可能透過覆寫、合併設定或腳本，調整連接埠、DNS 與規則。
3. 啟動核心：核心讀取最終產生的設定，建立本機監聽並載入規則。
4. 介面控制：用戶端呼叫控制介面，切換策略、重新載入設定及顯示日誌。
5. 系統整合：用戶端可視需要設定系統代理，或透過服務與權限機制支援 TUN。

圖形介面、網頁面板與核心是不同項目

網頁控制面板主要透過控制介面管理已在執行的核心，通常不負責完整的桌面安裝、開機啟動與權限服務。只有面板網頁，不代表本機已啟動代理核心。反過來說，核心也能在命令列執行，不一定需要桌面視窗。

判斷歷史用戶端時也應分開看。Clash for Windows、原版 Clash Verge 與 Clash Verge Rev 並非同一專案的三個版本。名稱相似不代表維護團隊相同；能呼叫開源核心，也不代表圖形用戶端的所有程式碼都採用相同授權條款。

設定相容性：優先檢查四個項目

多數設定沿用 proxies、proxy-groups、rules 等頂層結構，但「能解析 YAML」不等於「能執行所有設定」。舊核心遇到新協定、不同規則語法或新增的 DNS 欄位，可能會報錯，也可能產生與預期不同的行為。

• 節點類型：VLESS、Hysteria2、TUIC 等功能，需確認 mihomo 的實際版本；不能據此推論原版舊核心也支援。
• 規則與規則集：rule-providers 的格式、行為類型與檔案內容必須相符。網域清單不能直接當成完整規則清單使用。
• DNS 設定：fake-ip、上游解析與路由相關設定，應依目前核心文件確認，避免整段照搬舊教學。
• 用戶端覆寫：編輯訂閱原始內容後沒有生效，可能是最終執行設定被覆寫，也可能是訂閱更新覆蓋了修改。

連接埠範例：代理連接埠與控制連接埠不可混用

以下是用來說明用途的設定片段，不是可獨立連線的完整設定，也不代表所有用戶端的預設值。範例中的 7890 用於 HTTP 與 SOCKS 代理，9090 則用於控制介面，兩者用途不同。

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

瀏覽器或命令列程式應連接代理連接埠，不要把 9090 設為上網代理。控制介面建議限制為本機存取；若需要遠端控制，應另外設定驗證與存取限制。不要只為了讓介面連線成功，就直接對區域網路或公網開放控制介面。

系統代理與 TUN：分別檢查介面與核心

系統代理通常會將作業系統的代理設定指向本機監聽連接埠。遵循這項設定的瀏覽器與應用程式會透過代理發出請求，但並非每個應用程式都會讀取系統代理設定。規則模式則決定進入核心的連線如何分流；它本身不會強制所有程式接入。

TUN 透過虛擬網路介面與路由接管流量，也涉及 DNS、權限及系統網路環境。mihomo 提供相關核心功能，用戶端則負責切換、安裝服務及處理權限。介面上出現 TUN 按鈕，不代表服務、路由與 DNS 都已正常運作。

第一次測試建議先使用系統代理，確認訂閱、策略群組與代理連接埠正常，再依應用程式需求啟用 TUN。這樣可以區分節點連線問題與系統流量接管問題，避免同時變更多個設定。

挑選用戶端與確認版本的步驟

先記下兩種版本，再比較功能

以 Clash Verge Rev 為例，可先到「設定」→「關於」查看用戶端版本，再到「設定」中的核心相關區域或啟動日誌確認核心名稱與版本。實際位置可能因發行版本而異；若沒有獨立的核心版本頁面，請以該版本的日誌與專案說明為準。記錄時應寫下完整版本號，而非籠統地標註「最新版」。

如果已找到實際使用的核心執行檔，可以在終端機查看版本。以下是 Windows PowerShell 範例指令；檔名請依安裝檔中的實際名稱確認，別誤把圖形用戶端主程式當成核心執行。

# 在核心實際檔案所在目錄執行
.\mihomo.exe -v

# 檢查準備使用的 YAML 設定
.\mihomo.exe -t -f .\config.yaml

設定檢查可以找出語法與部分欄位錯誤，但不代表節點已連線，也不代表系統代理或 TUN 已接管流量。若設定使用相對路徑、外部規則集或提供器檔案，檢查時也要使用對應的工作目錄與配套檔案。

依使用情境決定挑選順序

1. 日常桌面使用：先確認作業系統與處理器架構，再選擇仍有維護、且能清楚顯示核心狀態的圖形用戶端。
2. 設定使用較新的協定：先確認所需的 mihomo 版本，再核對用戶端實際附帶的版本，不能只比較介面功能。
3. 需要 TUN：確認目前系統的服務安裝方式、管理員權限與已知網路相容性問題，並保留關閉 TUN 的復原方式。
4. 伺服器或自動化用途：可直接執行核心，並自行管理設定、程序與控制介面，不必因此安裝完整的桌面介面。
5. 沿用舊設定：先在新用戶端確認設定解析、策略選擇與 DNS 正常，再遷移開機啟動及系統流量接管設定。

確認開源資訊時，也要分別查看核心與用戶端儲存庫的授權條款。mihomo 採用 GPL-3.0；這不能取代對特定圖形用戶端、安裝檔附帶元件及發行說明的個別查核。專案名稱、儲存庫網址、用戶端版本與核心版本都應一一對應。

遷移後的基本檢查清單

安裝或替換完成後，先用一份已知可用的設定進行小範圍測試。不要一開始就同時啟用系統代理、TUN、複雜覆寫與自動切換；每次只新增一項設定，才容易從日誌找出問題。

• 確認核心已啟動，實際監聽連接埠與應用程式設定的連接埠一致，例如範例中的 127.0.0.1:7890。
• 確認訂閱已完成解析，策略群組中的節點名稱都存在，且沒有引用已刪除的策略。
• 在規則模式下測試一次連線，查看連線記錄中的命中規則與最終對外連線路徑。
• 確認本機規則與覆寫設定已套用至最終執行設定，再更新訂閱，確認修改仍符合預期。
• 最後測試重新啟動用戶端後設定是否還原正常，以及依需求啟用的系統代理或 TUN 是否正常運作。

若要逐步完成安裝與匯入，請接著參閱使用指南；遇到連接埠、訂閱或系統流量接管問題，可查閱說明中心。若不熟悉策略群組、規則集等術語，可先閱讀名詞解釋。