Clash、mihomo、Verge 到底有什麼關係：開源生態專案脈絡整理

先分清三個層次：核心、圖形化客戶端與設定

理解 Clash 生態最有效的方法，不是記住一串相似名稱，而是先把軟體拆成三個層次。最底層是代理核心，負責讀取 YAML 設定、建立代理連線、比對規則、執行 DNS 查詢，以及接管系統流量。中間層是圖形化客戶端，負責訂閱管理、系統匣選單、系統代理開關、日誌顯示與更新操作。最上層則是設定與訂閱，其中包含節點、策略群組、規則與 DNS 參數。

原始 Clash 與 mihomo 屬於核心層。Clash Verge、Clash Verge Rev、ClashX、FlClash 等名稱通常指的是圖形化客戶端。訂閱連結則是設定來源，既不是核心，也不是某個固定客戶端的組成部分。同一份基礎設定可能由多個客戶端載入，但能否完整執行，取決於底層核心是否支援其中使用的欄位。

代理核心: 解析設定並轉送流量。常見名稱包括原始 Clash、Clash.Meta，以及後續的 mihomo。
圖形化客戶端: 為核心提供視窗、系統匣、訂閱管理、系統代理與 TUN 開關，本身不等同於代理協定實作。
訂閱與設定: 以 YAML 或訂閱回應的形式提供節點、策略群組、規則、DNS 與流量接管參數。

從原始 Clash 到 mihomo 的專案脈絡

原始 Clash：設定語法與規則模型的起點

由 Dreamacro 開發的原始 Clash 奠定了至今仍廣泛使用的設定結構：以 proxies 定義節點，以 proxy-groups 組織選擇與自動測試，再由 rules 依序決定流量去向。常見的 DOMAIN-SUFFIX、IP-CIDR、GEOIP 與末尾的兜底規則，都源自這套模型。

原始開源 Clash 常見的最終版本標示為 v1.18.0。此外，Clash Premium 也曾以獨立版本發布，公開版本可見 2023.08.17。原專案於 2023 年停止持續維護後，仍具備重要的設定相容性參考價值，但已不適合做為了解新協定、新規則能力與新平台修正的唯一依據。

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

Clash.Meta 最初可理解為相容 Clash 設定體系的擴充核心。它保留常見的策略群組與規則寫法，同時持續加入更完整的 TUN、DNS、規則集與協定支援。許多設定中的 rule-providers、fake-ip-filter、程序比對，以及更細緻的網路堆疊選項，在 Meta 系列核心上都有較積極的維護。

這裡的「相容」不代表所有方向都能互換。基礎 Clash 設定通常可以由 mihomo 讀取，但使用 mihomo 擴充欄位的設定，放回舊版原始 Clash 時可能出現「無法辨識欄位」、「不支援代理類型」或設定載入失敗。遷移時應將相容關係理解為從舊語法前往新核心較順暢，而非雙向完全一致。

mihomo：Clash.Meta 的後續名稱

Clash.Meta 後續更名為 mihomo，專案由 MetaCubeX 社群繼續維護。名稱變更並未讓它成為另一套完全不同的設定體系：不少客戶端、設定轉換工具與日誌頁面仍會保留 Meta、Clash Meta 或 Meta Core 等舊稱。看到這些詞時，通常需要搭配具體版本號判斷，而不是將它們視為三個互不相關的核心。

因此，目前常見的發展鏈路可以概括為：原始 Clash 提供基礎設定模型，Clash.Meta 在相容基礎上擴充能力，mihomo 延續 Clash.Meta 的開發。客戶端若標示「mihomo 核心」，通常表示它面向這條仍持續更新的分支。

Verge、ClashX 與 Clash for Windows 分別是什麼

專案	所在層級	典型平台	核心關係	選擇時的注意事項
Clash	核心	命令列、多平台建置	原始專案	已停止持續維護，主要用於理解基礎相容性
Clash.Meta / mihomo	核心	Windows、macOS、Linux、行動裝置	Meta 後續更名為 mihomo	版本更新、設定擴充、TUN 與 DNS 能力
Clash Verge	桌面圖形化客戶端	Windows、macOS、Linux	透過核心執行代理功能	原專案維護狀態與後續分支需分開判斷
Clash Verge Rev	桌面圖形化客戶端	Windows、macOS、Linux	通常搭配 mihomo	核心版本、服務模式、TUN 權限與系統相容性
ClashX	macOS 圖形化客戶端	macOS	封裝 Clash 系列核心	系統版本、核心年代與設定欄位相容性
Clash for Windows	桌面圖形化客戶端	Windows、macOS、Linux	過去整合 Clash 系列核心	最終常見版本為 0.20.39，專案已停止更新

Clash Verge 與 Clash Verge Rev

Clash Verge 是採用桌面 Web 技術建構的跨平台圖形化客戶端，負責訂閱、策略選擇、系統代理與設定編輯。原 Clash Verge 專案停止活躍後，Clash Verge Rev 作為後續維護分支，延續了相近的操作方式。兩者名稱相近，但發布儲存庫、版本序列與維護狀態並不相同，下載時不能只看應用程式圖示。

在 Clash Verge Rev 中，使用者通常可以從「設定」→「Clash 設定」查看連接埠、外部控制器與核心相關參數，從「設定」→「系統設定」管理開機啟動或服務模式。不同版本的翻譯可能略有調整，但「設定頁中的核心版本」比安裝套件名稱更能說明實際能力。啟用 TUN 時，Windows 通常還需要安裝並啟動服務模式；macOS 則需要完成系統權限授權。

ClashX：面向 macOS 的選單列客戶端

ClashX 的重點是 macOS 選單列體驗。它將設定切換、策略群組選擇、系統代理與日誌入口放進狀態列選單，適合以系統代理作為主要接管方式的使用情境。ClashX、ClashX Pro 以及社群延續版本不能只憑名稱判斷功能，需要分別確認其核心類型、最後更新時間，以及對目前 macOS 的支援情況。

舊版 ClashX 能讀取許多經典 Clash 設定，但遇到僅由 mihomo 支援的協定、規則集行為或 DNS 欄位時，可能無法完整載入。若訂閱說明明確要求 Meta 或 mihomo 核心，應選擇明確整合對應核心的客戶端，而不是反覆刪除欄位讓舊客戶端勉強啟動。

Clash for Windows：歷史影響深遠，但已停止更新

Clash for Windows 常縮寫為 CFW，是許多使用者最早接觸的桌面客戶端。它提供 Profiles、Proxies、Connections、Logs 與 Settings 等頁面，並推廣了「匯入訂閱後直接切換策略」的桌面操作方式。其最終常見發布版本為 0.20.39，專案已於 2023 年停止更新。

還需要釐清一點：Clash for Windows 並不是完整開源的圖形化客戶端，不能因為名稱中包含 Clash，就將它與原始開源核心視為同一個專案。如今繼續使用舊安裝套件，會面臨新系統適配、核心能力與問題修正停滯等限制。新安裝環境更適合選擇仍有維護紀錄，並明確說明所使用核心的客戶端。

為什麼同一份訂閱在不同客戶端中的表現不同

訂閱能否匯入只是第一關。客戶端取得訂閱內容後，還要交由核心解析。即使兩個介面都顯示「Clash 設定」，底層核心版本、覆寫邏輯、DNS 實作與流量接管方式不同，最終結果也可能不同。常見差異主要集中在以下四個方面。

設定欄位與代理協定支援

基礎欄位如 mixed-port、proxies、proxy-groups 與 rules 的相容範圍較廣。
新協定參數、規則集合行為與進階 DNS 選項通常需要較新的 mihomo 核心。
客戶端可能在訂閱原文之外追加本機覆寫，例如更換連接埠、啟用區域網路存取或插入 TUN 設定。
同名策略群組可能由訂閱產生，也可能被客戶端腳本修改；排查時要區分遠端原文與最終執行設定。

系統代理與 TUN 的接管範圍不同

系統代理通常會將 HTTP 與 SOCKS 代理位址寫入作業系統設定。常見的本機混合連接埠是 127.0.0.1:7890，應用程式必須讀取系統代理或手動指定該連接埠，流量才會進入核心。遊戲、部分命令列程式與自行實作網路堆疊的應用程式可能繞過系統代理。

TUN 模式則透過虛擬網路裝置接管更多 IP 流量。它更依賴系統權限、路由表、DNS 劫持與網路堆疊設定。兩個客戶端即使使用相同的 mihomo 版本，只要其中一個成功安裝服務元件、另一個沒有取得權限，TUN 的表現就會不同。判斷問題時，應先查看日誌是否出現 TUN 裝置建立成功，再檢查規則命中，不要將權限失敗誤判為節點失效。

mixed-port: 7890
external-controller: 127.0.0.1:9090
secret: "change-this-controller-secret"

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

上面的 7890 是代理入口，9090 是外部控制介面，兩者用途不同。外部控制介面用於客戶端介面查詢連線與切換策略，不應被瀏覽器當作 HTTP 代理連接埠。若客戶端已自動產生控制密鑰，應保留其產生值，避免介面與核心失去連線。

DNS 策略會改變規則比對結果

Clash 系列核心可根據網域、IP 位址與規則順序決定流量去向。在 fake-ip 模式下，核心會先向應用程式回傳保留位址，再維護網域對映以完成後續規則比對。若客戶端修改了 enhanced-mode、nameserver 或 fake-ip-filter，相同規則也可能呈現不同結果。

排查時可以在客戶端的「日誌」頁面將層級調整為 info，分別造訪一個中國大陸網域、一個需要代理的網域與一個純 IP 位址。持續觀察至少 30 秒，確認三類請求分別命中預期策略。若網域規則正常而純 IP 流量繞過，優先檢查 TUN 或系統代理的接管範圍；若全部進入兜底策略，再檢查規則順序與 DNS 對映。

如何判斷一個專案目前是否值得使用

專案名稱只能說明來源，不能直接代表目前狀態。選擇客戶端時，應同時檢查發布紀錄、核心來源、系統適配與設定相容性。介面仍能開啟，不代表它能妥善處理目前訂閱中的所有欄位。

查看最近的發布紀錄。確認正式版本的發布日期、版本說明與支援系統，不要只看儲存庫是否仍可存取。
確認核心名稱與版本。優先選擇能在「設定」→「關於」或「設定」→「Clash 設定」中明確顯示 mihomo 版本的客戶端。
核對作業系統架構。Windows 常見為 x64 與 ARM64，macOS 需要區分 Apple Silicon 與 Intel，Linux 還要確認 AppImage、deb、rpm 或命令列部署方式。
檢查權限機制。需要 TUN 時，確認客戶端是否提供服務模式、系統管理員權限說明，或 macOS 網路延伸功能的授權流程。
確認訂閱需求。如果設定提供者註明需要 mihomo、Meta 或特定協定支援，就不要選用只整合舊版原始 Clash 的客戶端。
保留可回復的設定。更新客戶端或核心前，匯出目前可用的設定，記錄系統代理連接埠、覆寫項目與 DNS 設定。

從舊客戶端遷移至 mihomo 客戶端

從 Clash for Windows、舊版 ClashX 或早期 Verge 遷移時，最穩妥的方式是將訂閱與本機設定分開處理。先在新客戶端匯入原始訂閱，確認基礎代理可用，再逐項恢復覆寫、TUN、區域網路存取與自訂規則。直接複製整個舊設定目錄，容易將快取、舊核心路徑與已失效的控制器設定一併帶過去。

遷移前記錄五項參數

目前的訂閱位址與更新時間，同時確認訂閱仍可正常重新整理。
代理入口連接埠，常見為混合連接埠 7890，也可能分別使用 HTTP 7890 與 SOCKS 7891。
目前模式是 Rule、Global 還是 Direct，以及預設策略群組的選擇。
是否啟用 TUN、區域網路連線、IPv6 與自訂 DNS。
本機新增的規則、腳本或設定覆寫，這些內容通常不會包含在遠端訂閱中。

透過三輪測試確認遷移結果

第一輪只啟用系統代理。關閉 TUN，選擇 Rule 模式，分別開啟中國大陸網站與需要代理的網站，確認日誌出現對應規則與策略群組。
第二輪測試訂閱重新整理。手動更新一次設定，等待頁面顯示更新時間，再確認策略群組選擇沒有被意外重設。
第三輪啟用 TUN。啟動服務模式或完成系統授權，測試一個不讀取系統代理的命令列程式。可使用 curl --connect-timeout 10 https://example.com 將連線逾時限制為 10 秒，並對照客戶端的連線清單。

若第一輪成功而第三輪失敗，問題通常出在 TUN 權限、路由或 DNS，不必重新更換訂閱。若設定匯入階段已經報錯，則應查看第一筆解析錯誤，確認具體欄位是否要求 mihomo。若只有個別節點失敗，再比對協定參數與伺服器端狀態。

用一張關係圖記住整個生態

Clash 生態並不是「同一個軟體換了很多名稱」，而是一組共享設定理念、又由不同團隊維護的專案。原始 Clash 是基礎核心；Clash.Meta 在其設定模型上擴充能力；Clash.Meta 後續以 mihomo 的名稱持續開發。Clash Verge Rev、ClashX 等專案位於圖形化客戶端層，透過整合核心完成實際代理工作。訂閱則位於設定層，可以在相容的客戶端之間遷移。

訂閱與 YAML 設定
        │
        ▼
圖形化客戶端
Clash Verge Rev / ClashX / 其他客戶端
        │
        ▼
代理核心
mihomo（原 Clash.Meta）
        │
        ▼
規則比對 / DNS / 系統代理 / TUN / 連線轉送

選擇時可以將問題濃縮成三個：客戶端是否仍在維護、它整合了什麼核心，以及目前訂閱是否依賴該核心的擴充能力。回答這三個問題後，由名稱相似帶來的混亂會明顯減少。對於新安裝環境，優先關注仍有發布紀錄、明確整合 mihomo，並能適配目前作業系統權限機制的客戶端；對於既有穩定環境，則應先記錄設定與連接埠，再分階段遷移。