Clash 核心、mihomo 與各款客戶端的關係：一次看懂開源生態

先釐清三個層次：核心、客戶端與設定

Clash 並不是能概括所有安裝檔的單一產品名稱。原版 Clash 是代理核心；mihomo 是從 Clash Meta 發展而來的核心專案；Clash Verge Rev、FlClash 等則是以核心為基礎打造的圖形客戶端。要確認某項功能是否可用，必須一併查看客戶端版本、實際執行的核心，以及最後載入的設定。

最簡單的分辨方式是看各自負責的工作：核心解析 YAML、處理連線、執行 DNS 與分流規則；客戶端管理訂閱、顯示策略組、切換系統代理，並負責啟動核心程序與服務；訂閱提供者則提供節點參數或完整設定。三者彼此相關，但維護者並不相同。

層級	常見項目	主要職責
代理核心	Clash、mihomo	監聽連接埠、解析設定、比對規則、連線至上游
圖形客戶端	Clash Verge Rev、FlClash	匯入設定、選擇策略、系統整合、顯示記錄
設定與訂閱	YAML 檔案、訂閱網址	提供節點、策略組、規則與更新入口

專案演進：原版 Clash、Clash Meta 與 mihomo

原版核心停止維護，不代表整個生態就此停擺

約在 2023 年 11 月，原版 Clash 專案停止公開維護。當時的生態中也有閉源分支 Clash Premium，其功能與開源原版並不完全相同。舊教學只寫「Clash 支援 TUN」時，往往沒說明具體分支與平台條件，因此不能直接套用到任意舊版核心。

停止維護代表後續的協定支援、系統相容性與問題修正，不再能仰賴原專案持續提供。舊程式或許仍能執行，但「可以啟動」和「適合繼續做為日常網路工具」是兩回事。遷移時應優先確認目前的維護狀態，而不只是比較安裝檔名稱是否熟悉。

Clash Meta 是 mihomo 的舊專案名稱

Clash Meta 源自 Clash 生態中的分支開發，後來更名為 mihomo。舊文件中的「Meta 核心」和新文件中的「mihomo 核心」，通常指的是同一條專案演進脈絡，並非需要同時安裝的兩個元件。專案更名也不代表舊欄位、舊執行檔名稱與客戶端介面標籤會立刻統一。

mihomo 延續了 Clash 風格的 YAML 設定與控制介面，並擴充協定與路由功能。不過，「接棒」指的是生態維護與功能發展，並非原版團隊正式移交，也不代表新舊設定百分之百相容。

專案演進：
原版 Clash ── 分支開發 ── Clash Meta ── 更名 ── mihomo

整合關係：
Clash Verge Rev ── 管理並呼叫 ── mihomo
FlClash         ── 整合並呼叫 ── mihomo

資料輸入：
訂閱或本機 YAML ── 客戶端處理 ── 執行時設定 ── 核心載入

這張圖呈現的是專案與元件之間的關係，不代表客戶端共用同一套介面程式碼。兩款客戶端即使使用相近的核心，也可能採用不同的設定合併流程、服務管理方式與平台支援邏輯。

客戶端的職責：Verge Rev 與 FlClash 各自負責什麼

Clash Verge Rev：桌面介面與系統整合

Clash Verge Rev 是支援 Windows、macOS 和 Linux 的桌面客戶端，採用 mihomo 核心。訂閱清單、系統匣選單、策略組選擇、連線記錄等都屬於客戶端的操作介面；連線最後使用哪個代理、某條規則是否命中，則由執行中的核心處理。

客戶端的「服務模式」通常用來讓背景元件取得所需權限，以管理核心或網路功能。它不是代理協定，也不代表啟用後所有流量都會自動進入代理。是否接管流量，仍須視系統代理、TUN、路由與應用程式本身的連線方式而定。

FlClash：跨平台介面與行動裝置整合

FlClash 是以 Flutter 建置、採用 mihomo 核心的客戶端專案，支援桌面與 Android 等平台。在 Android 上透過系統 VPN 介面接管流量，和桌面系統修改系統代理的方式不同。介面上的啟動按鈕或許相似，底層所需的系統授權卻不一樣。

遇到 FlClash、FlClashs 等名稱相近的專案時，應分別確認專案來源、維護者與發布記錄，不要只憑名稱就認定它們是同一個專案。支援的平台也應以各專案的發行清單為準，不能把某款軟體的功能說明套用到同名分支。

不能只看舊客戶端名稱判斷核心

Clash for Windows：已停止維護。歷史安裝檔可能搭載不同核心，不能將它與目前的 mihomo 客戶端畫上等號。
Clash for Android：原專案已停止維護。Android VPN 權限只是接入流量的條件，不會自動補上舊核心缺少的協定支援。
其他桌面封裝：先查看專案說明所列的核心類型，再確認目前安裝檔實際搭載的核心版本，不能只看名稱中是否包含 Clash。

挑選前可先參考客戶端比較，再依作業系統前往下載頁面。請確認「目前平台可執行、核心支援所需設定、系統整合方式合適」這三項條件都符合。

YAML 設定如何從訂閱送進核心

訂閱網址是設定來源，不是代理協定。網址回傳的內容可能是完整 YAML、節點清單或其他格式。客戶端能否直接匯入，取決於它支援哪些輸入格式；核心能否載入，則取決於產生的設定是否符合該核心的欄位與協定要求。

取得內容：由客戶端下載訂閱，或讀取本機 YAML 檔案。
處理設定：客戶端可能套用覆寫、合併、腳本或全域設定，產生實際執行的檔案。
載入核心：核心讀取最終設定，建立監聽器並初始化代理、DNS 與規則。
接入流量：應用程式連線至代理連接埠，或透過 TUN 等入口將流量送入核心。
執行分流：在規則模式下，核心依序比對規則，並使用指定策略處理連線。

以下是用來說明欄位歸屬的最小設定範例，不含遠端代理節點。所有一般流量最後都會直連，因此不能用來證明遠端代理可正常運作。連接埠 7890 和 9090 僅為範例值，並非所有客戶端固定使用的預設值。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

external-controller: 127.0.0.1:9090
secret: "local-doc-demo-rotate-before-use"

proxy-groups:
  - name: Route
    type: select
    proxies:
      - DIRECT
      - REJECT

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,Route

mixed-port 是 HTTP 與 SOCKS 共用的代理入口，應用程式流量可由此進入核心。
external-controller 是控制 API 的監聽位址，用來查詢狀態及變更選擇，並非供瀏覽器設定的代理連接埠。
proxy-groups 用來定義策略組；客戶端負責顯示選項，核心則儲存並執行目前的選擇。
rules 用來定義比對順序。最後的 MATCH 會處理前面規則都未命中的連線。

如果訂閱原始內容中的連接埠是 7890，客戶端最後卻監聽其他連接埠，請先檢查客戶端的全域設定或覆寫項目。排查時應查看執行時設定，而不是一再修改下次更新就會被覆蓋的訂閱檔案。欄位說明可參閱YAML 手冊。

系統代理、TUN 與協定支援分別由誰決定

系統代理是應用程式的連線入口，不會提升核心能力

啟用系統代理後，只有遵循系統代理設定的應用程式會向指定連接埠傳送要求。自行建立直連、不讀取系統代理設定的命令列工具，以及部分遊戲流量，不一定會被接管。遇到這種情況，更換圖形介面的主題或重新匯入相同訂閱，通常都無法改變應用程式的連網方式。

TUN 需要核心支援，也仰賴客戶端與系統權限

TUN 透過虛擬網路介面接收 IP 流量。核心必須支援相關功能；客戶端也須正確建立介面、管理權限與路由，並處理 DNS。Windows 服務權限、Linux 網路管理權限與 Android VPN 授權，都是整個流程所需的平台條件。

TUN 也不代表「所有連線都會經過遠端節點」。流量進入核心後，仍可能依規則選擇 DIRECT，也可能受到路由排除或應用程式分流設定影響。請一併確認流量接管範圍與規則結果，不要只看 TUN 開關是否已啟用。

新協定通常取決於核心，設定方式還得看客戶端

某種節點類型能否使用，首先取決於核心是否支援，以及節點參數是否正確。舊核心遇到新協定時，可能會顯示代理類型不受支援或設定載入失敗。升級圖形客戶端有時也會一併更新核心，但客戶端版本號和核心版本號並非同一套編號。

反過來說，即使核心支援某個欄位，也不代表客戶端的編輯器已提供相應選項。有些功能必須寫入 YAML，或透過覆寫加入。若介面儲存時會重新改寫設定，也要確認自訂欄位不會被刪除。

選型與疑難排解：逐層確認各個元件

遇到「同一份訂閱在另一款客戶端能用」的情況，先別急著歸因於節點品質。兩邊可能使用不同核心、覆寫設定或 DNS 設定，甚至採用不同的流量接入方式。依照以下順序比對，比較容易找出差異。

記下兩種版本：分別記錄客戶端版本與核心版本。可從「關於」、核心管理介面或啟動記錄中查詢；實際選單名稱請以目前發行版本為準。
檢查載入結果：先查看設定解析錯誤、未知代理類型、策略名稱不存在等訊息。設定尚未成功載入前，測試出口 IP 沒有診斷意義。
確認流量入口：確認目前使用的是系統代理還是 TUN。若以明確指定代理的方式測試，連接埠必須符合實際監聽值，不要直接照抄教學內容。
確認策略：查看連線記錄中的命中規則、策略組與最終節點。若規則指向直連，出口維持本機位址就是預期結果。
最後比對 DNS 與網路：即使設定相同，解析結果、IPv6 路由或上游網路不同，也會造成連線差異。

例如，實際混合連接埠為 7890 時，可在終端機明確指定代理，排除應用程式是否遵循系統代理這項變因。在 Windows 上，若 curl 被解讀為其他命令，可改用 curl.exe。

curl --proxy http://127.0.0.1:7890 --head --max-time 15 https://example.com

這個命令只會檢查透過指定 HTTP 代理入口送出單次要求的結果，不能代表 TUN 已接管其他應用程式，也無法單獨證明流量使用了遠端節點。請同步查看核心連線記錄；若命中 DIRECT，要求仍會透過本機網路直接連到目標。

遷移舊設定：保留必要欄位，逐項恢復功能

從已停止維護的客戶端遷移至 mihomo 客戶端時，建議先備份原有設定與自訂規則，再用有效訂閱建立最基本的連線。不要直接覆蓋新客戶端的整個執行目錄，也不要混用舊服務檔案與新核心執行檔。

先確認協定：檢查訂閱輸出是否適用於目前的核心，並確認節點名稱與策略組引用相符。
接著遷移規則：先恢復少量明確規則，確認命中結果，再加入規則集與複雜分流設定。
最後遷移 DNS 與 TUN：這兩部分與作業系統及區域網路環境密切相關，不宜不加確認就照搬舊設定。
避免重複接管：測試新客戶端時，請先退出舊客戶端，並確認舊服務沒有繼續占用代理連接埠或管理虛擬介面。

生態選型的重點不是尋找名稱完全相同的替代品，而是拆分各項職責：根據核心能力判斷協定與設定相容性，根據客戶端功能評估平台整合體驗，再透過執行時設定與記錄確認實際行為。釐清這三個層次後，專案更名、客戶端分支與設定遷移就能用同一套流程檢查。