Clash 開源生態圖譜：原版、Meta、mihomo 與各客戶端的關係一次看懂

先釐清核心、客戶端與設定檔

Clash 生態最常見的誤解，是把所有帶有 Clash 名稱的軟體都視為同一個專案。實際上，至少可分為三層：負責網路轉送的核心、提供圖形介面的客戶端，以及由訂閱服務或使用者維護的 YAML 設定檔。三者可以組合使用，但維護者、版本號與相容範圍並不相同。

核心負責實際處理流量

核心會讀取設定檔、監聽本機代理連接埠，執行 DNS、規則比對、策略組選擇與出站連線。經典設定常見的 HTTP 與 SOCKS 混合連接埠是 7890，外部控制介面通常設為 127.0.0.1:9090。系統代理、TUN 虛擬網卡與規則分流，最後都必須交由核心執行。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090
secret: change-this-secret

客戶端是操作核心的介面

FlClash、Clash Verge Rev、ClashX 等名稱通常指的是圖形客戶端。客戶端負責匯入訂閱、啟動或停止核心、修改系統代理、顯示連線記錄，也可能管理系統服務與 TUN 權限。客戶端本身能啟動，不代表核心已正常監聽；判斷執行狀態時，應同時檢查核心日誌、連接埠占用情況與控制介面。

訂閱不是客戶端安裝程式

訂閱連結通常回傳節點與策略設定。它不會安裝核心，也不會自動取得系統網路權限。同一份基礎訂閱可以匯入不同客戶端，但若設定使用了 rule-providers、sniffer、Hysteria2、TUIC 或 mihomo 專用的 DNS 欄位，經典 Clash 核心可能無法解析。

原版 Clash：生態系的設定與 API 基礎

原版 Clash 由 Dreamacro 發起，以 Go 語言編寫。它建立了至今仍被大量客戶端沿用的基本模型：將代理節點放入 proxies、策略組放入 proxy-groups，流量依照 rules 由上而下比對，並透過 RESTful 外部控制介面向圖形介面提供狀態、連線與策略切換功能。

經典欄位至今仍是生態系的共同語言，例如 mode: rule、mixed-port、dns.enable、external-controller。因此，即使使用 mihomo，設定檔看起來仍與原版 Clash 十分相似。這是相容性延續，並不代表兩個核心仍處於同一條維護線上。

原版停止維護後的實際影響

原版專案於 2023 年停止公開維護，常見的存檔版本為 v1.18.0。停止維護代表新協定、規則能力、作業系統網路堆疊變化與安全修正，不會再持續加入原版。已固定在舊裝置中的經典設定可能仍能運作，但不適合作為新部署的預設選擇。

設定層：基礎代理、策略組與網域規則仍具高度遷移價值。
核心層：不應再期待原版取得新的協定支援或 TUN 改進。
客戶端層：仍使用 Clash 名稱的軟體，可能早已替換為 mihomo，也可能仍綁定舊核心。
訂閱層：若服務端產生設定時啟用了 mihomo 擴充功能，匯入經典核心可能會直接回報欄位錯誤。

Clash.Meta 到 mihomo：一次更名與持續演進

Clash.Meta 最初是相容 Clash 設定體系的增強分支。它保留原版常用的設定結構與控制介面，同時加入更多代理協定、規則集、DNS 行為、流量嗅探與 TUN 能力。原版停止維護後，Clash.Meta 成為許多新客戶端採用的核心路線。

隨後，Clash.Meta 更名為 mihomo，專案由 MetaCubeX 社群維護。更名主要影響專案名稱、二進位檔名稱、映像檔名稱與文件入口，並不代表設定體系被全面推翻。舊資料中的「Meta 核心」與新資料中的「mihomo 核心」，通常指向同一演進路線的不同階段。

mihomo 相較經典核心增加了哪些功能

更多出站協定：除了經典的 Shadowsocks、VMess、Trojan 等類型，也持續擴充 VLESS、TUIC、Hysteria2、WireGuard 等實作。
規則集能力：rule-providers 可從本機檔案或遠端網址載入規則集合，方便拆分更新大型網域與 IP 規則。
TUN 改進：可透過虛擬網卡接管不遵循系統代理的軟體，並針對不同平台採用合適的網路堆疊。
流量嗅探：在條件允許時，從 TLS SNI 或 HTTP Host 還原目標網域，讓只能取得目標 IP 的連線也有機會套用網域規則。
DNS 擴充：提供 fake-ip、redir-host、依網域選擇解析器、規則跟隨與更細緻的 nameserver 策略。

這些能力不會因為安裝採用 mihomo 的客戶端就自動啟用。例如，TUN 仍需要系統權限與正確路由；嗅探需要設定 sniffer.enable: true；遠端規則集需要有效的下載網址與更新間隔。核心提供能力，設定決定是否啟用。

如何確認目前執行的是 mihomo

最直接的方法是查看客戶端的「關於」、「核心」或「版本」頁面。若客戶端未顯示，可在已啟用外部控制介面的前提下請求 /version。以下指令對應控制連接埠 9090，並使用前文設定的控制密鑰：

curl -H "Authorization: Bearer change-this-secret" \
  http://127.0.0.1:9090/version

回傳內容通常包含版本字串與實作識別資訊。若介面連線遭拒，先確認核心正在執行，並檢查 external-controller 是否只繫結至本機位址。若回傳 401 Unauthorized，表示控制介面可連線，但請求中的密鑰不相符。

FlClash、Verge、ClashX 分別位於哪一層

客戶端之間最重要的差異，不只是介面風格，而是採用哪條核心維護線、如何管理系統代理與 TUN，以及設定能否原樣遷移。以下按專案家族分別說明。

FlClash：Flutter 客戶端與 mihomo 核心

FlClash 是以 Flutter 建構的跨平台圖形客戶端，核心執行層採用 mihomo。它負責訂閱管理、策略切換、連線檢視、日誌顯示與系統代理等操作，協定解析與規則執行則由 mihomo 完成。因此，討論 FlClash 是否支援某個代理協定時，應同時核對 FlClash 整合的核心版本，以及該協定對應的設定欄位。

FlClash 的跨平台介面有助於維持一致的操作邏輯，但 Windows、macOS、Linux 與 Android 的權限模型仍不相同。例如，桌面系統代理主要影響遵循代理設定的應用程式；TUN 模式則需要建立虛擬網路介面。Android 還會透過系統 VPN 授權視窗接管流量，不能直接套用桌面端的權限步驟。

Clash Verge 與 Clash Verge Rev：名稱相近，維護線不同

原 Clash Verge 是一款桌面圖形客戶端，曾廣泛用於 Windows、macOS 與 Linux。原專案停止維護後，社群延續專案 Clash Verge Rev 成為新的維護分支。搜尋「Verge 下載」時，經常會同時看到舊版、復刻包與 Rev 版本，必須核對完整專案名稱、發布日期與核心資訊。

Clash Verge Rev 採用 mihomo 路線，適合需要桌面系統匣、系統代理、TUN、訂閱管理與連線檢視的使用者。舊 Clash Verge 的設定資料可以作為遷移來源，但不應直接假設資料庫、服務安裝方式與應用程式設定完全相容。遷移時較穩妥的做法，是匯出訂閱網址與自建 YAML，再於新客戶端重新匯入。

ClashX：經典 macOS 客戶端家族

ClashX 是 macOS 上較早流行的選單列客戶端，歷史版本主要圍繞經典 Clash 核心運作。它與原版 Clash 的設定結構關係密切，但主要維護線已停滯。繼續使用舊版 ClashX 時，基礎 HTTP、SOCKS 與一般策略組可能仍可運作；mihomo 新增的欄位與新協定則不能預設相容。

ClashX Pro、ClashX.Meta 等相近名稱也曾出現，但它們不是同一個儲存庫的連續版本。尤其是 ClashX.Meta，代表將 macOS 圖形介面與 Meta 核心結合的分支思路。看到「ClashX」三個字時，仍需進一步確認具體分支、最後發布日期、CPU 架構與實際核心。

Clash for Windows：常見但已停止維護的桌面客戶端

Clash for Windows 常縮寫為 CFW，曾支援 Windows、macOS 與 Linux。它是圖形客戶端，不等同於原版 Clash 核心專案；而且客戶端本身也不是整個 Clash 開源生態的統一上游。CFW 已於 2023 年停止維護，舊安裝程式中的介面與核心不會再獲得一般更新。

從 CFW 遷移時，重點是保存訂閱 URL、自建設定、覆寫規則與策略偏好，而不是複製整個應用程式目錄。舊設定中的 parsers、腳本或客戶端專屬覆寫功能，可能無法由另一款客戶端直接辨識，需要改寫成目標客戶端支援的覆寫方式或標準 mihomo YAML。

其他仍常見的 mihomo 客戶端

Clash Nyanpasu：面向桌面平台的圖形客戶端，採用 mihomo 核心路線，提供設定、代理與連線管理。
Mihomo Party：以 mihomo 為核心的桌面客戶端，名稱直接反映其核心關係。
OpenClash：面向 OpenWrt 的管理與整合方案，透過路由器端服務執行 Clash.Meta 或 mihomo，並結合防火牆規則接管區域網路流量。
命令列 mihomo：不依賴圖形客戶端，可透過 YAML、系統服務與外部控制面板組成伺服器或閘道方案。

維護狀態不能只看「還能開啟」

客戶端能夠啟動，只能表示目前的安裝程式與系統暫時可以運作。判斷維護狀態應查看版本發布、提交活動、核心升級速度與系統相容紀錄。尤其在作業系統大版本更新後，TUN 驅動程式、網路延伸功能、系統服務權限與程式碼簽署都可能改變。

四項檢查比專案名稱更可靠

檢查最近發布：記錄最新穩定版的發布日期，而不只是查看儲存庫最近一次文件修改時間。
檢查核心版本：客戶端更新不一定會同步更新 mihomo；查看關於頁面或核心日誌中的實際版本。
檢查系統相容性：確認安裝程式支援目前的 CPU 架構，例如 macOS 的 Apple Silicon 與 Intel、Windows 的 x64 與 arm64。
檢查問題處理：觀察安裝失敗、TUN 無法啟動、訂閱解析錯誤等問題是否仍有維護者處理。

截至本文日期 2026 年 7 月 28 日，原版 Clash、原 Clash Verge、ClashX 主線與 Clash for Windows 應視為已停止維護的專案；mihomo 仍是活躍的核心路線；FlClash、Clash Verge Rev 等客戶端則是圍繞 mihomo 建構的獨立專案。客戶端維護狀態可能隨時間變化，安裝前仍應以該專案最新正式發布紀錄為準。

設定遷移：相容基礎欄位，不代表完全通用

從經典 Clash 客戶端遷移至 mihomo 客戶端通常相當順利，因為基礎節點、策略組與規則語法都有延續。反向遷移則更容易失敗：經典核心無法辨識 mihomo 後續新增的協定與欄位。遷移前應先區分「標準基礎設定」、「核心擴充設定」與「客戶端專屬設定」。

通常可以直接遷移的內容

訂閱 URL 與本機 YAML 檔案。
常見的 proxies、proxy-groups 與 rules。
DOMAIN、DOMAIN-SUFFIX、IP-CIDR、GEOIP、MATCH 等基礎規則。
常用連接埠、區域網路存取開關與基礎 DNS 位址。

需要重新核對的內容

客戶端專屬覆寫、腳本、設定合併與訂閱預處理功能。
TUN 網路堆疊、自動路由、嚴格路由與介面名稱。
GeoData 模式、規則集格式與遠端資源更新網址。
fake-ip 過濾清單、DNS 分流與系統 hosts 行為。
VLESS、Reality、TUIC、Hysteria2 等擴充協定欄位。

完成遷移後，可先維持 mode: rule，依序驗證訂閱更新、節點連通性、DNS 解析、規則命中與系統代理。最後再啟用 TUN，避免同時修改過多變數。若日誌出現 field not found、unsupported proxy type 或 YAML 解析錯誤，應先定位欄位相容性，而不是反覆重新安裝客戶端。

選型結論：先選維護線，再選介面

新安裝應優先選擇採用活躍 mihomo 核心、持續發布且明確支援目前系統的客戶端。需要在 Windows、macOS、Linux 或 Android 間維持相近操作邏輯時，可以考慮 FlClash；偏好桌面系統匣與系統服務管理時，可比較 FlClash、Clash Verge Rev、Clash Nyanpasu 與 Mihomo Party；若要在 OpenWrt 路由器上集中接管區域網路流量，則應評估 OpenClash 與命令列 mihomo。

即使舊客戶端仍能運作，也應先記錄訂閱網址、匯出自建規則並確認目前使用的連接埠。常見的 7890、7891 與 9090 可能已被舊程序占用，導致新客戶端核心啟動失敗。遷移期間只保留一個客戶端接管系統代理或 TUN，可以減少代理迴圈與預設路由衝突。

整張生態圖可以歸納成一條清晰的關係：原版 Clash 建立設定與控制介面的基礎；Clash.Meta 在相容基礎上擴充能力；Clash.Meta 後續更名為 mihomo 並持續維護；FlClash、Clash Verge Rev 等專案是呼叫 mihomo 的圖形客戶端；ClashX、原 Clash Verge 與 CFW 則屬於不同歷史階段的客戶端專案。理解這幾個層次後，名稱相近便不再是選型障礙。