mihomo、Clash Meta 與各圖形用戶端的關係：開源生態系譜整理

先分清三個層次：代理核心、管理介面與系統整合

mihomo 是代理核心，Clash Meta 是它曾使用的專案名稱；Clash Verge Rev 等用戶端則整合核心、圖形介面與系統功能，組成可安裝的軟體。因此，只說「使用 Clash」無法確認實際執行的是哪個核心，也無法據此判斷支援哪些協定、設定欄位或系統功能。

排查問題時，應先確認問題出在哪個層次。無法辨識節點協定，通常要檢查核心能力與設定格式；訂閱按鈕出錯，可能是用戶端下載或解析時發生問題；瀏覽器可以連線、其他應用程式卻不行，則還要檢查系統代理、虛擬網卡與路由設定。

名稱沿革：Clash、Clash.Meta 與 mihomo

Clash 原版：設定架構與規則引擎的起點

Clash 原版建立了這類工具常見的設定結構：以 proxies 描述代理節點，以 proxy-groups 組織策略，並由 rules 決定連線路徑。許多後來推出的用戶端沿用這套 YAML 設定方式，因此介面不同的產品通常仍有部分設定相容。

也要區分原版開源核心與歷史上的 Clash Premium。Premium 曾是另一條發行線，提供部分進階功能；它的功能清單不能直接當作原版開源核心的功能清單。原專案於 2023 年 11 月停止公開維護後，舊軟體仍可能正常啟動，但不代表它能持續相容後續推出的節點協定或新設定欄位。

Clash.Meta：在相容基礎上擴充功能

Clash.Meta 是從 Clash 生態系發展出的分支，在相容既有設定的基礎上擴充協定支援、DNS 與路由功能。早期文件、訂閱選項和用戶端選單中常見的「Meta 核心」，通常指這條專案線，而不是獨立的圖形用戶端。

mihomo：Meta 專案後來採用的名稱

Clash.Meta 後來更名為 mihomo，由 MetaCubeX 社群持續開發。因此，「Clash Meta 和 mihomo 哪個比較好」通常不是在比較兩個並行的新專案，而是混用了舊名稱與後續名稱。舊檔名、相容欄位或記錄中保留 Meta 字樣，也不一定表示核心仍停留在更名前的版本。

Clash 原版開源核心
└─ Clash.Meta 分支
   └─ mihomo（後續專案名稱）

圖形用戶端、行動用戶端
└─ 整合特定核心發行線，並提供各自的介面與系統整合功能

這張圖只呈現核心專案的演變與用戶端整合關係，不代表所有名稱中含有 Clash 的軟體都由同一個維護團隊開發，也不代表各專案採用相同的開源授權。確認專案身分時，請查閱程式碼儲存庫、發行說明與授權檔案。

桌面用戶端：哪些採用 mihomo，哪些屬於歷史分支

桌面用戶端通常同時負責「管理設定」和「啟動核心」。以下整理常見專案的技術定位；實際安裝套件內含的核心版本，仍應以用戶端顯示資訊和發行說明為準。

其中，Clash Verge Rev 是獨立維護的後續專案，並非只替原版 Clash Verge 換了版本號。遷移時應重新檢查服務安裝、設定目錄與開機啟動項目，不要假設舊用戶端的系統整合功能會自動沿用。

也要留意相似的拼法。本網站下載清單中的 FlClashs 與上表提到的上游 FlClash，不能只因名稱相近就視為來自同一個發行管道。遇到衍生用戶端，應分別確認其原始碼儲存庫、整合的核心與安裝套件來源。其他用戶端也適用相同的判斷方式。

行動裝置：Android VPN 服務與 iOS 網路延伸功能

Android：Clash for Android 與 Meta 分支應分開看待

原版 Clash for Android 已停止維護。名稱中含有 Meta 的 Android 分支屬於另一條維護線，不能根據原版的版本記錄判斷其更新狀態。FlClash 等跨平台用戶端採用不同的介面實作方式，但同樣可以在 Android 上整合 mihomo。

Android 用戶端通常透過系統 VpnService 接管裝置流量。首次啟用時出現的 VPN 授權，是允許用戶端建立本機虛擬網路介面，不代表系統已自動連上某家遠端 VPN 服務。實際連線目的地仍由節點、代理群組與規則決定。

是否支援依應用程式分流、背景常駐與區域網路分享，還取決於用戶端實作和系統限制。手機即使使用與桌面相同的訂閱，也需要另外檢查應用程式排除清單、省電最佳化設定與 DNS 設定。

iOS：介面相似，不代表核心相同

iOS 用戶端通常需要透過 Network Extension 等系統機制處理網路流量，並受到延伸功能執行環境的限制。能匯入某類 Clash 訂閱，只能表示用戶端接受該格式或具備轉換能力，不能據此認定它完整執行了相同版本的 mihomo。

選用 iOS 產品時，應確認公開文件是否明確說明核心來源、支援的協定與設定欄位。尤其是指令碼、規則集、DNS 和 TUN 相關選項，不要直接照搬桌面教學中的選單路徑。

設定相容範圍：訂閱、規則與介面覆寫

訂閱網址不等於最終執行的設定

訂閱回傳的內容可能是完整 YAML、只有節點清單，或是需要用戶端轉換的其他格式。完整設定通常包含 proxies、proxy-groups 和 rules；節點型 provider 通常只提供節點，代理群組與規則則由主設定定義。

圖形用戶端也可能將本機覆寫、指令碼處理與介面設定合併至訂閱內容。因此，排查「同一份訂閱在兩個用戶端結果不同」時，應比較實際交給核心的最終設定，而不只是比對訂閱原文。遷移時先匯入基礎訂閱，再逐項還原覆寫設定，更容易找出差異。

規則語法相似，仍須檢查策略名稱

以下片段用來說明規則順序，並非可直接執行的完整設定。代理群組中必須已存在名為 PROXY 的策略；這裡的 PROXY 是自訂名稱，並非不必定義就能使用的通用內建出口。

rules:
  - DOMAIN-SUFFIX,example.org,PROXY
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,PROXY

規則會依序比對，末尾的 MATCH 用來接住未符合前面規則的連線。若遷移後將代理群組改名為「節點選擇」，規則卻仍引用 PROXY，設定可能無法通過檢查。同樣地，RULE-SET 引用的規則集名稱，也必須存在於 rule-providers 中。

TUN 與 Fake-IP 是不同面向

TUN 解決的是如何將流量送入核心；Fake-IP 則是 DNS 處理模式，透過虛擬位址對應協助還原網域名稱。兩者經常搭配使用，但不是同一個開關。啟用 TUN 不會自動修正錯誤的代理群組，也無法保證所有 DNS 要求都會依預期進入核心。

設定中的 tun、dns、協定專屬欄位與規則集格式，都可能有版本需求。新核心接受的欄位，舊版 Clash 或舊版 Premium 未必能辨識。若出現未知欄位或不支援的代理類型，應先確認版本需求，而不是刪除錯誤欄位來假裝遷移成功。

確認目前使用的核心：版本、程序與本機控制介面

最可靠的紀錄方式是「用戶端名稱與版本＋實際執行的核心版本＋最終設定」。不同用戶端的選單位置可能隨版本變動，可先從「關於」、核心管理介面或啟動記錄中查找完整版本字串；回報問題時請保留原始字串，不要只寫「最新版」。

1. 檢查執行記錄：停止連線後重新啟動核心，查看啟動資訊，確認核心名稱與設定載入結果。
2. 檢查實際執行檔：對確認來源的 mihomo 檔案執行 mihomo -v；使用 mihomo -t -f config.yaml 檢查指定設定。命令列檢查的檔案必須與用戶端實際啟動的核心相同。
3. 檢查控制介面：若已啟用本機 REST API，可查詢 /version；控制連接埠與代理連接埠用途不同。

以下使用明確的示範設定：混合代理連接埠為 7890，控制介面為 127.0.0.1:9090。這些值不是所有用戶端共用的預設值；實際檢查時應讀取執行中的設定。

mixed-port: 7890
external-controller: 127.0.0.1:9090
secret: "local-demo-token-change-before-use"

本機查詢指令如下。請先將範例權杖換成自行設定的值，切勿在公開回報中貼上實際權杖。

curl --header "Authorization: Bearer local-demo-token-change-before-use" \
  http://127.0.0.1:9090/version

在 Windows PowerShell 中可使用 curl.exe，並將指令寫成一行。若連線遭拒，通常表示連接埠不正確或介面未在監聽；若回傳 401，則應檢查驗證權杖。不要為了取得版本資訊而將控制介面設為監聽所有網卡；控制介面具備設定與連線管理功能，應限制存取範圍。

用戶端選型與遷移檢查清單：先確認功能，再調整系統整合方式

選擇用戶端時，可依照以下順序評估。如此能將「介面偏好」與「執行能力」分開，也能避免一次變更太多設定而難以追查。

1. 確認平台與架構：Windows、macOS、Linux、Android、iOS 的權限模型各不相同；Apple 晶片與 Intel 的安裝套件也不能只看檔案大小來選擇。
2. 確認核心需求：檢查訂閱中的協定類型、provider 格式與 DNS 欄位是否受到目標核心版本支援。
3. 備份設定來源：分別保存訂閱網址、本機規則、覆寫設定與指令碼；請勿將含有憑證的設定上傳至公開位置。
4. 只執行一個接管流量的用戶端：遷移時先關閉舊用戶端的系統代理或 VPN/TUN，避免連接埠衝突與路由競爭。
5. 先測試基本連線：匯入訂閱、選擇策略群組，再用瀏覽器發出連線要求，並在連線清單中確認命中的規則與實際出口。
6. 最後還原進階功能：逐項啟用 TUN、DNS 覆寫、應用程式分流與開機啟動，每次變更後都檢查記錄。

總結來說，Clash 是這套設定生態系的重要起點；Clash.Meta 與 mihomo 是同一條專案線上的舊名稱與後續名稱；各圖形用戶端則負責將核心整合至不同作業系統。了解這三個層次後，就能更準確判斷問題該透過更新核心、修改設定，還是調整用戶端的系統權限來解決。

需要進一步確認參數時，可參閱使用手冊；不熟悉策略群組、Fake-IP 或 TUN 的概念，可先閱讀術語手冊。