Clash 開源專案關係整理：原版核心停止維護後，mihomo 與圖形用戶端的關係

先分清三個層級：核心、圖形用戶端與訂閱

搜尋「Clash 下載」時，結果可能同時包含命令列程式、桌面安裝檔和手機 App。它們分屬不同層級：核心負責執行代理與流量分流，圖形用戶端負責管理及啟動核心，訂閱則提供節點或設定資料。先釐清這三個層級，才能判斷「更換用戶端能不能解決問題」。

核心：監聽代理連接埠、建立對外連線、比對規則並處理 DNS；mihomo 就屬於這個層級，也能脫離圖形介面獨立執行。
圖形用戶端：管理訂閱、選擇策略群組、切換系統代理、安裝背景服務，並顯示核心記錄與連線紀錄。
訂閱：可能只提供節點清單，也可能提供包含 DNS、規則和策略群組的完整 YAML；訂閱服務本身並不是核心專案。

例如，用戶端視窗顯示「執行中」，只代表某些程序或服務已啟動，不表示訂閱中的節點可以連線。反過來說，瀏覽器能透過 127.0.0.1:7890 上網，也不能證明 TUN 已接管整台裝置的流量。先找出問題所在的層級，再決定要升級什麼，通常比反覆重新安裝省時。

原版 Clash、Premium、Meta 與 mihomo 的演進

原版 Clash：設定模型與規則架構的起點

Dreamacro/clash 是這個生態的重要起點，採用 Go 語言編寫，原版開源核心使用 GPL-3.0 授權。許多至今仍在使用的設定概念都由此延續，例如 proxies、proxy-groups、rules，以及由上而下比對規則的運作方式。約在 2023 年 11 月，原專案停止公開維護，但歷史用戶端和教學並未因此從網路上消失。

這也是舊教學容易造成誤解的原因：其中介紹的 HTTP 代理和規則順序可能仍適用，但安裝檔、核心功能與系統權限設定，已不再是相同的環境。看到「Clash 支援某個欄位」時，還得進一步確認：指的是哪個核心、哪個版本？

Clash Premium：不是 mihomo 的「付費進階版」

Clash Premium 是原有生態中獨立發行的閉源核心分支，曾提供 TUN、指令碼等擴充功能。Premium 在這裡是分支名稱，不能直接理解成某個圖形用戶端的付費方案。由於完整實作並未開源，不能把後來的 mihomo 描述成「公開 Premium 原始碼持續更新」這麼簡單的直線傳承。

原版開源 Clash、Premium 與 Meta 的功能有所重疊，但設定項目並非一一相容。尤其是舊版 Premium 的指令碼規則，不能只把執行檔換成 mihomo，就假設仍會生效；遷移時應改寫為目標核心支援的規則與策略群組。

Clash.Meta → mihomo：名稱更改與功能擴充

Clash.Meta 是從 Clash 開源程式碼發展而來的社群分支，之後更名為 mihomo，儲存庫識別名稱為 MetaCubeX/mihomo。因此，舊文件中的「Meta 核心」和訂閱平台上的「Clash Meta 格式」，通常指的就是現在討論的 mihomo 生態，而不是另一個必須同時安裝的程式。

mihomo 延續 Clash 風格的 YAML 設定與控制介面，並持續擴充通訊協定、規則與 DNS 功能。mihomo 採用 GPL-3.0 授權，但使用 mihomo 的圖形用戶端可能採用不同授權；檢視軟體授權時，應分別查看前端與核心的 LICENSE，而不是只看安裝檔名稱。

關係示意：逐一標示箭頭代表的含義

原版 Clash 開源程式碼
  └─ 社群分支發展 → Clash.Meta
                       └─ 專案更名 → mihomo

Clash Premium
  └─ 原有生態的閉源核心分支；不是 mihomo 公開原始碼的上游

Clash Verge Rev / FlClash 等圖形用戶端
  └─ 打包、啟動並透過控制介面管理 → mihomo

Verge、FlClash、Nyanpasu 各自屬於哪個層級

這些名稱主要指圖形用戶端，而不是三種完全不同的代理通訊協定。它們可能呼叫同類核心，但在訂閱合併、背景服務、系統代理設定和更新策略方面各有差異。以下依專案關係加以區分，不會把介面相似視為程式碼傳承的證據。

專案名稱	所屬層級	選擇時要確認的重點
mihomo	代理核心	核心版本、設定欄位、目標架構；不附完整的桌面管理介面
Clash Verge	歷史桌面用戶端	原專案已封存，發布紀錄不可與 Rev 混為一談
Clash Verge Rev	延續 Verge 路線的桌面用戶端	Windows、macOS、Linux 安裝檔及隨附的 mihomo 版本
FlClash	以 Flutter 開發的圖形用戶端	桌面版與 Android 版的功能差異，以及實際封裝的核心
Clash Nyanpasu	源自 Verge 路線的桌面用戶端	目前版本提供的核心選項、設定擴充方式與服務模式
Clash for Windows	歷史桌面用戶端	已停止維護；名稱中的 Windows 不代表過去只支援 Windows
Clash for Android	歷史 Android 用戶端	已停止維護；不要只因為能安裝，就認定它支援新設定

Clash Verge 與 Clash Verge Rev 必須分開辨識

「Verge」常被用作簡稱，但原版 Clash Verge 和後續的 Clash Verge Rev 並非同一個發布管道。Rev 延續原專案的發展方向，採用 mihomo 核心。搜尋到舊版安裝說明時，應先確認完整專案名稱與發布儲存庫，再參考操作截圖；即使選單名稱相同，背景服務的實作方式也可能已經改變。

FlClash 與 FlClashs 不應直接視為同一個發行版本

FlClash 使用 Flutter 建構介面，支援桌面與 Android 等平台。如果下載清單中還出現 FlClashs，應將它視為另一個發行名稱，分別確認維護者、儲存庫、套件名稱及說明；不能只因名稱多了一個字母，就認定更新紀錄通用。網站顯示名稱、安裝後的 App 名稱與上游專案名稱，有時並不完全一致。

Nyanpasu 的核心選項應以實際發行版本為準

Clash Nyanpasu 同樣屬於圖形管理層。不同階段的發行版本可能提供不同核心選項，因此不能把舊截圖中的切換選單當成永久不變的功能清單。排除問題時，請記錄「用戶端版本 + 目前選用的核心 + 核心版本」三項；只說「使用 Nyanpasu」不足以判斷某項設定能否解析。

為什麼同一份訂閱在不同用戶端的表現不一樣

訂閱相容性不是一個開關。匯入相同 URL 後，用戶端可能傳送不同的請求標頭，伺服器也可能因此回傳不同內容；即使回傳內容相同，用戶端還可能加入本機覆寫，最後再交由不同版本的核心執行。比較時應檢查實際生效的設定，而不只是訂閱編輯欄中的原始內容。

確認回傳格式：完整的 Clash YAML 通常包含 proxies 或 proxy-providers 等欄位；只有節點連結清單的內容，不一定能當成完整設定直接載入。
確認核心支援情況：舊版核心不一定支援新的通訊協定或欄位。記錄中若出現 unsupported proxy type 之類的錯誤，請先確認核心版本，而不是一再更新同一份訂閱。
確認本機覆寫：用戶端可能會覆寫 mixed-port、dns、tun 和 external-controller。原始設定寫的是 7890，最後實際監聽的連接埠不一定仍是 7890。
確認規則引用：規則中的策略群組名稱必須與實際名稱一致。MATCH,PROXY 中的 PROXY 是引用名稱，不是所有設定都會自動提供的保留群組。

用指令確認目前執行的是哪個核心

不要只靠安裝檔名稱猜測。先在用戶端的「關於」或核心資訊頁面記下版本；各發行版本的入口名稱可能不同。若要檢查獨立核心檔案，可在其所在目錄執行以下指令。這裡使用 mihomo 常見的檔名，若實際檔名不同，請改用本機檔案名稱。

Windows PowerShell

.\mihomo.exe -v
.\mihomo.exe -t -d . -f .\config.yaml

macOS / Linux

./mihomo -v
./mihomo -t -d . -f ./config.yaml

-v 會顯示核心版本；-t 用來檢查設定；-d . 將目前目錄設為工作目錄，方便定位本機資料檔案。包含遠端規則集或其他資源的設定，檢查過程也可能受網路狀態與檔案路徑影響。設定測試通過，只代表通過相關檢查，不表示所有節點都已建立連線。

如果用戶端已啟用本機控制介面，也可以讀取版本。以下僅適用於控制位址為 127.0.0.1:9090，且未設定控制密鑰的本機環境；若有設定密鑰，請依設定加入 Bearer 驗證，不要為了執行範例而刪除密鑰。

讀取執行中核心的版本資訊

curl http://127.0.0.1:9090/version

從舊用戶端遷移：分三步檢查設定、權限與流量

第一步：備份輸入資料，不要整個目錄覆蓋

保留訂閱網址、本機規則、策略群組選擇紀錄和覆寫指令碼。先在新用戶端重新匯入訂閱，再逐項遷移本機修改；不要把舊應用程式的資料目錄整個覆蓋到新應用程式的目錄。兩者的資料庫結構、路徑慣例和指令碼介面可能不同，YAML 格式相似不代表內部儲存方式也相容。

第二步：先測試明確代理，再啟用 TUN

在新用戶端確認實際使用的 mixed-port。假設連接埠是 7890，可以先用以下指令檢查明確 HTTP 代理的連線。範例網域僅用來示範指令格式，回應狀態取決於目前網路與規則，不預設任何「實測延遲」。

透過本機代理傳送 HTTPS 請求

curl -I --proxy http://127.0.0.1:7890 https://example.com

明確代理能正常運作後，再測試系統代理和 TUN。系統代理主要影響遵循系統設定的應用程式；TUN 透過虛擬網路介面接管流量，通常還需要背景服務、管理員權限或平台 VPN 授權。Android 上的相關用戶端一般透過系統 VPN 介面運作，與桌面版安裝服務的流程不同。

第三步：檢查 DNS、UDP 與休眠後恢復

DNS：比較一般網頁瀏覽與 App 內的連線，確認系統的 DNS 查詢是否依預期接管；啟用 TUN 不代表所有加密 DNS 都已受控。
UDP：語音通話、遊戲和 QUIC 也需要節點與通訊協定支援；能開啟網頁不能取代 UDP 測試。
休眠恢復：裝置從休眠狀態恢復並重新連線後，檢查背景核心是否仍在執行，以及系統代理連接埠是否仍有監聽。
關閉後恢復：結束用戶端後，確認系統代理已還原；如果系統仍指向已關閉的 7890 連接埠，使用體驗可能像是「整個網路都斷了」。

選擇結論：確認維護脈絡，不要只看名稱

桌面使用者可先比較 Clash Verge Rev、FlClash 與 Clash Nyanpasu 的設定管理方式、服務權限及核心更新入口；Android 使用者則應確認系統 VPN 授權、背景執行限制與目前安裝版本支援的平台架構。iOS 使用者應另外確認特定 App 的設定相容範圍，不要直接假設桌面版 mihomo 的所有功能都能套用。

最後應記錄一條可追溯的脈絡：安裝檔來源 → 用戶端發行版本 → 實際核心版本 → 最終生效設定。只更換介面，不一定能解決通訊協定相容問題；只升級核心，也不一定能修復系統代理殘留。先釐清各個層級，再查看記錄，專案關係就不只是名稱接龍，而能成為排除問題的工具。

需要確認安裝步驟時，可參閱全平台指南；不熟悉 TUN、策略群組等術語時，可先閱讀名詞解釋。下載時請選擇符合系統與處理器架構的版本，並留意用戶端的維護狀態。