Clash 開源生態全景：mihomo、Clash Verge、ClashX 與各分支專案的關係

先區分核心、客戶端與設定

Clash 生態最容易混淆的地方，在於許多專案名稱都含有 Clash，但它們並不屬於同一層。原始 Clash、Clash.Meta 與 mihomo 主要是代理核心；Clash Verge Rev、Clash Nyanpasu、ClashX 等則是圖形化客戶端；訂閱連結、YAML 檔案與規則集則是交由核心讀取的資料。判斷專案用途時，先確認它所處的層級，比比較介面截圖更有效。

核心負責實際的網路處理

核心會監聽本機代理連接埠、建立與代理伺服器的連線，並依照規則決定流量走向。常見工作包括解析 YAML 設定、管理代理群組、比對網域與 IP 規則、執行 DNS 策略、提供 REST API，以及在支援的平台上接管 TUN 流量。以下是一段典型的核心基礎設定：

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

external-controller: 127.0.0.1:9090
secret: "change-this-controller-secret"

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16

這裡的 7890 是 HTTP 與 SOCKS5 共用的混合連接埠，9090 是控制介面連接埠，1053 是範例 DNS 監聽連接埠。圖形化客戶端通常會透過控制介面讀取節點清單、切換代理群組與查看連線記錄。介面上的「選擇節點」最後會轉換為對核心 API 的呼叫。

圖形化客戶端負責生命週期與系統整合

下載、更新與切換訂閱設定。
啟動、停止並監控核心程序。
設定系統代理，或建立 TUN 虛擬網卡。
提供代理群組、規則、連線、日誌與流量統計介面。
儲存客戶端本身的設定，例如開機啟動、系統匣行為與核心路徑。

因此，同一份訂閱在兩個客戶端中的表現不同，不一定代表訂閱內容發生變化。差異可能來自核心版本、DNS 預設值、TUN 實作、客戶端寫入的覆寫欄位，或客戶端只顯示部分設定項目。

原始 Clash、Clash.Meta 與 mihomo 的承襲關係

原始 Clash 奠定設定與 API 結構

Dreamacro 維護的原始 Clash 以 Go 撰寫，建立了這套生態最重要的相容基礎：YAML 設定、代理群組、依序比對的規則系統、HTTP 與 SOCKS 監聽連接埠，以及外部控制 API。許多客戶端最初都是圍繞這些介面開發。原始儲存庫已於 2023 年停止維護並進入封存狀態，此後繼續依賴原始核心，將不再取得上游協定適配、平台相容性與網路堆疊修正。

歷史上的 Clash Premium 是具備額外功能的獨立發行線，曾提供規則集、腳本與更完整的 TUN 能力。它不是今天選擇新客戶端時仍應追蹤的活躍開源主線。舊教學中出現的 rule-providers、tun 或 script 欄位，需要配合實際核心判斷，不能只憑「Clash 設定」四個字推測相容性。

Clash.Meta 擴充原有能力

Clash.Meta 由 MetaCubeX 社群維護，起點是相容 Clash 設定與控制介面，同時擴充協定、DNS、規則、監聽器與 TUN 功能。過去許多設定提供者會將相應訂閱標記為「Clash Meta」。這類訂閱可能包含原始 Clash 不認識的代理類型或欄位，因此直接匯入舊版 ClashX、舊版 Clash for Windows 或原始 Clash 核心，可能發生解析失敗，也可能靜默忽略部分選項。

mihomo 是 Clash.Meta 的後續名稱

Clash.Meta 後來更名為 mihomo。名稱變更不代表設定體系被全面推翻：常見的 proxies、proxy-groups、rules、proxy-providers 與 rule-providers 結構仍然沿用。實際遷移重點在於客戶端是否使用活躍的 mihomo 核心、核心版本是否符合設定要求，以及客戶端是否在啟動前修改設定。

mihomo 的版本通常以 v1.x.x 格式發布。排查問題時應記錄完整版本號，而不是只寫「Meta 核心」。客戶端的「設定」→「核心」或「設定」→「版本」頁面通常可以查看這項資訊；不同專案的選單名稱略有差異。日誌開頭通常也會列出版本、Go 執行環境與目標架構，例如 linux-amd64、windows-amd64 或 darwin-arm64。

桌面客戶端分支各自解決哪些問題

Clash Verge 與 Clash Verge Rev

Clash Verge 是使用 Tauri 建構的跨平台桌面客戶端，介面層與代理核心分離。原專案停止維護後，Clash Verge Rev 作為社群延續分支，持續適配 mihomo。兩者名稱相近，但維護狀態與核心更新來源不同。新安裝時應確認專案名稱是否明確標示為 Rev，並在「設定」→「核心設定」查看實際載入的 mihomo 版本。

Clash Verge Rev 適合需要在 Windows、macOS 與 Linux 上維持近似操作方式的使用者。常見流程是「訂閱」→「新增」加入訂閱網址，更新後在「代理」頁面選擇策略群組，再到「設定」開啟系統代理或 TUN 模式。系統代理主要接管遵循作業系統代理設定的程式；TUN 模式則透過虛擬網卡處理更多類型的流量，通常還需要管理員權限，以及正確的路由與 DNS 設定。

Clash Nyanpasu

Clash Nyanpasu 同樣屬於跨平台圖形化客戶端，專案重點放在設定管理、核心管理與桌面互動。它不是 mihomo 的替代品，而是負責下載或呼叫核心、產生執行設定並顯示核心狀態。使用時應分別確認「客戶端版本」與「核心版本」，因為只更新介面程式不代表代理核心也已更新。

Nyanpasu 適合需要管理多份設定、覆寫與代理群組的使用者。訂閱更新後若行為發生變化，應依序檢查「設定」中的目前啟用項目、覆寫內容、核心選擇與執行日誌。若一份設定能在命令列 mihomo 中啟動，卻在 Nyanpasu 中失敗，應重點檢查客戶端合併後的最終設定，而不是只檢查原始訂閱檔案。

ClashX、ClashX Pro 與 ClashX.Meta

ClashX 是較早出現的 macOS 選單列客戶端，操作入口集中在狀態列圖示中。其經典版本圍繞原始 Clash 核心設計，適合用來理解許多舊版 macOS 教學中的選單結構，例如「設為系統代理」、「出站模式」與代理群組選擇。由於原始核心已封存，經典 ClashX 不適合用於依賴新協定、新規則集能力或新版 macOS 網路變化的設定。

ClashX Pro 屬於歷史上的增強發行線，不能只根據名稱中的 Pro 推斷它使用 mihomo。ClashX.Meta 則是因應 Meta 核心相容需求而出現的分支。三者的圖示與選單可能相似，但核心來源並不相同。匯入設定前，應開啟「說明」→「關於」或查看啟動日誌，確認核心名稱與版本。只比較應用程式檔名，無法判斷是否支援某種代理類型。

Clash for Windows

Clash for Windows 曾是使用範圍廣泛的桌面客戶端，但它不是開源專案，且已於 2023 年停止維護。許多舊教學仍以其「Profiles」「Proxies」「General」與「Connections」頁面作為範例。閱讀這些教學時，可以理解其中的設定概念，但不應將頁面路徑直接套用到 Verge Rev 或 Nyanpasu。

從 Clash for Windows 遷移時，優先遷移訂閱網址或原始 YAML，不要複製整個程式目錄。舊目錄中可能還包含客戶端產生的合併設定、快取規則集與本機覆寫。新客戶端重新匯入訂閱後，再逐項重建連接埠、區域網路存取、TUN 與 DNS 設定，會更容易定位差異。

行動裝置、路由器與網頁面板的定位

行動裝置客戶端是獨立實作

Android 與 iOS 上的應用程式即使支援 Clash 格式，也不一定直接執行與桌面端相同的核心二進位檔。行動作業系統對背景程序、VPN 介面、DNS 與電量管理有獨立限制。Android 客戶端通常透過系統 VPN API 建立 TUN；iOS 客戶端則依賴 Network Extension。桌面端的「系統代理」開關，在手機上沒有完全對應的運作方式。

Clash Meta for Android 曾是常見的 Meta 系行動客戶端，但判斷是否繼續使用時，應查看儲存庫封存狀態與近期發布記錄。FlClash 等專案也可以使用 mihomo 能力，但其介面設定、設定儲存與系統整合都是客戶端自行實作。跨裝置共用設定時，建議共用訂閱主體，將平台相關的 TUN、DNS 監聽位址與區域網路參數保留在各裝置本機。

OpenClash 是 OpenWrt 外掛層

OpenClash 執行於 OpenWrt 環境，負責核心部署、設定轉換、規則更新、防火牆與 DNS 整合。它不是桌面客戶端，也不是獨立的代理協定。路由器上的流量接管涉及 nftables 或 iptables、策略路由、DNS 劫持與區域網路位址範圍，複雜度高於桌面的系統代理開關。

例如桌面端常見的 mixed-port: 7890 只為本機應用程式提供代理入口；路由器的透明接管則還要處理來自 LAN 裝置的轉送流量。開啟 allow-lan: true 只代表允許其他裝置連線至代理監聽連接埠，並不會自動完成閘道轉送、DNS 接管或防火牆放行。

Yacd、MetaCubeXD 屬於 Dashboard

Yacd、MetaCubeXD 等專案是外部控制面板。它們連線至核心的 REST API 與 WebSocket，顯示代理群組、活動連線、規則命中與流量資料。面板本身不處理代理流量，也不會取代 mihomo。若核心控制位址為 127.0.0.1:9090，只有本機能直接存取；需要從區域網路管理時，應謹慎調整監聽位址，並設定強度足夠的 secret 與防火牆規則。

訂閱、設定與規則集如何在專案間流動

訂閱連結回傳的內容通常是一份 YAML 設定，也可能是經過編碼的節點清單。客戶端負責下載內容，必要時執行轉換或覆寫，再將最終設定交給核心。所謂「支援 Clash 訂閱」，至少包含三個層面：能辨識檔案格式、能辨識其中的代理協定，以及能正確執行其中的 DNS 與規則欄位。

完整設定與 Provider 設定

完整設定會把節點、代理群組與規則寫在同一個檔案中；Provider 方案則將節點或規則拆分為遠端資源，由核心定期更新。以下結構會每隔 3600 秒重新整理一次節點提供者，並透過健康檢查存取指定 URL：

proxy-providers:
  airport:
    type: http
    url: "https://example.invalid/subscription.yaml"
    path: ./providers/airport.yaml
    interval: 3600
    health-check:
      enable: true
      interval: 600
      url: "https://www.gstatic.com/generate_204"

proxy-groups:
  - name: PROXY
    type: select
    use:
      - airport

rules:
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

interval: 3600 控制訂閱更新週期，health-check.interval: 600 控制健康檢查週期，兩者不是同一項設定。測試 URL 回傳的速度只反映對該目標發出請求所需的時間，不等同於下載頻寬。規則會依序比對，MATCH 應放在最後作為兜底。

客戶端覆寫會改變最終結果

連接埠覆寫：客戶端可能會將訂閱中的 mixed-port 改為本機指定的連接埠。
DNS 覆寫：啟用 TUN 時，客戶端可能插入 dns-hijack、Fake IP 或 nameserver 設定。
規則覆寫：腳本或合併設定可能在原有規則前加入直連、攔截或程序規則。
代理群組覆寫：客戶端可能保留本機選擇，訂閱更新後仍指向原本的節點名稱。

排查相容性問題時，最有價值的是客戶端實際傳給核心的最終 YAML。若客戶端提供「設定」→「查看執行設定」或「設定」→「開啟設定目錄」，應匯出該檔案並與訂閱原文比較。日誌中記錄的設定路徑也能協助定位產生的檔案。

TUN、系統代理與核心差異

系統代理只涵蓋主動讀取代理設定的程式

開啟系統代理後，客戶端通常會將作業系統的 HTTP 與 HTTPS 代理指向 127.0.0.1:7890。瀏覽器與多數桌面應用程式會讀取這項設定，但遊戲、部分命令列程式、虛擬機器與自行實作網路堆疊的軟體可能繞過它。此時核心正常執行、瀏覽器可以連線，並不能證明所有程序都已進入代理。

TUN 透過虛擬網卡接管 IP 流量

mihomo 的 TUN 模式會建立虛擬網路介面，並配合路由與 DNS 設定接收流量。範例設定通常如下：

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

stack: mixed 表示使用核心支援的混合網路堆疊策略，auto-route 要求自動寫入路由，auto-detect-interface 用於辨識預設出口。不同作業系統對管理員權限、網卡驅動程式與防火牆的要求不同。在 Windows 上切換 TUN 後完全斷網，請先檢查客戶端是否以所需權限執行，再檢查其他 VPN、Hyper-V、WSL 或安全軟體建立的路由。

客戶端之間的 TUN 體驗差異，往往來自啟動順序、路由清理、DNS 注入與休眠恢復處理，而不只是 mihomo 本身。比較兩個客戶端時，應使用同一份設定、相同核心版本與相同網路環境。一次測試可記錄啟動耗時、首次 DNS 回應、預設路由變化與休眠恢復後的連線狀態，而不是只比較介面顯示的記憶體數字。

應如何判斷維護狀態

專案名稱延續不代表維護活動也延續。選擇客戶端時，應同時檢查程式碼儲存庫、發布頁面與依賴的核心，而不是只看下載頁面上的版本字串。原始 Clash、Clash for Windows、經典 ClashX 與各類社群分支的狀態並不相同。

四項可驗證的訊號

近期發布：查看正式版本發布時間、變更記錄，以及各平台安裝包是否同步產生。
核心來源：確認使用的是原始 Clash、mihomo，還是客戶端自帶的其他相容核心。
問題處理：檢查與目前 Windows、macOS、Linux 版本相關的問題是否有人分類與修復。
升級路徑：確認客戶端升級是否涵蓋核心升級，以及失敗後能否手動回復。

版本號不能跨專案直接比較。Clash Verge Rev 2.x、Nyanpasu 2.x 與 mihomo v1.x.x 分別屬於不同軟體，數字大小沒有承襲關係。回報故障時，應同時寫明客戶端完整版本、mihomo 完整版本、作業系統版本、CPU 架構、目前模式與關鍵日誌。例如「Windows 11 24H2、x64、客戶端 2.x、mihomo v1.x.x、TUN mixed 堆疊」比「最新版不能用」更容易定位問題。

不要依靠應用程式名稱推斷架構

macOS 安裝包可能同時提供 x64 與 arm64，Apple 晶片裝置應優先選擇 arm64 建置版本。Windows 裝置常見 x64，部分新裝置使用 arm64。Linux 還需要區分 AppImage、deb、rpm 以及系統函式庫要求。架構不相容時，即使應用程式能透過轉譯啟動，TUN 輔助程式或核心二進位檔仍可能失敗。

依使用情境選擇專案

Windows、macOS、Linux 統一操作

需要三類桌面作業系統維持近似的設定管理方式，可優先考察 Clash Verge Rev 或 Clash Nyanpasu。選擇時應重點比較目前系統上的 TUN 支援、設定覆寫能力、核心更新機制與日誌入口。只使用瀏覽器代理的情境，系統代理的穩定性比複雜的 TUN 選項更重要。

macOS 選單列的輕量操作

偏好選單列互動時，可以考察仍在維護且明確使用 mihomo 的 macOS 客戶端。若繼續使用經典 ClashX，應明確了解其核心能力界線，並避免匯入包含 mihomo 專屬欄位的設定。升級 macOS 大版本前，先確認客戶端對新系統網路權限與背景啟動機制的適配狀況。

路由器統一接管家中裝置

電視、遊戲機與物聯網裝置無法單獨安裝客戶端時，OpenWrt 搭配 OpenClash 是常見方案。部署前應確認路由器 CPU 架構、可用記憶體、快閃記憶體空間與防火牆體系。規則集較大、連線數較高或啟用複雜 DNS 時，資源需求會明顯高於簡單的本機連接埠代理。

只需要核心與遠端面板

伺服器或精簡 Linux 環境可以直接執行 mihomo，透過 systemd 管理程序，再使用 MetaCubeXD 等 Dashboard 連線至控制連接埠。此方案需要自行處理設定目錄、檔案權限、日誌輪替與升級。控制介面不應直接暴露在不受信任的網路上，遠端存取可透過防火牆、反向代理驗證或安全通道加以限制。

遷移舊客戶端的操作順序

記錄目前參數：保存訂閱網址、目前代理群組選擇、本機覆寫、監聽連接埠與區域網路設定。
匯出原始設定：優先保存訂閱 YAML，不要把快取、日誌與客戶端資料庫當作可攜式設定。
安裝新客戶端：確認系統架構，再在「設定」→「核心」檢查 mihomo 版本。
先測試系統代理：使用預設 7890 或客戶端顯示的實際連接埠，確認基本規則與 DNS 正常。
再啟用 TUN：記錄啟用前後的路由與 DNS 變化，發生斷網時即可快速回復。
重建覆寫：逐項加入規則、DNS 與區域網路設定，每次修改後重新載入並查看日誌。

如果舊設定包含腳本模式、Premium 專屬欄位或過時的代理類型，應先查明相應功能在 mihomo 中的替代寫法。不要一次複製舊客戶端的全部合併設定，因為其中可能包含絕對路徑、舊連接埠、舊網卡名稱與平台專屬欄位。

遷移完成後，可進行三組檢查：瀏覽器透過系統代理存取、命令列明確指定 http://127.0.0.1:7890 存取，以及啟用 TUN 後測試不讀取系統代理的程式。三組結果能區分訂閱問題、系統代理問題與 TUN 路由問題。