· 選型參考 · 預計閱讀 9 分鐘

Clash 原版、Clash Meta 與 mihomo 核心差異：版本沿革與選擇指南

比較 Clash 原版、Clash Meta 與 mihomo 的沿革、協定支援、規則語法及維護狀態，並整理各款用戶端內建的核心。

先分清用戶端與核心

Clash 用戶端是用來匯入設定、切換節點及開啟系統代理的圖形介面；核心則負責解析 YAML 設定、比對規則，並實際處理連線。兩者可以由不同專案開發。因此，視窗標題寫著 Clash，不代表執行的就是 Clash 原版、Clash Meta 或 mihomo。要確認核心，請查看用戶端的「核心」或「關於」頁面，而不是只看應用程式名稱。

這三個名稱並非三種新舊版本並列。Clash 原版是較早期的專案；Clash Meta 從其生態系發展出擴充功能；mihomo 則是 Clash Meta 後續採用的專案名稱。資料、訂閱說明或用戶端介面仍可能標示「Meta」，但實際下載的核心檔案及版本資訊可能顯示「mihomo」。遇到這兩種稱呼時，先核對專案與版本資訊，不必急著找所謂的 Meta 轉 mihomo 設定檔。

名稱 與其他名稱的關係 選擇時的評估重點
Clash 原版 早期獨立開發的 Clash 核心專案 現有設定是否只使用基礎協定與規則；使用中的用戶端是否仍內建此核心
Clash Meta 擴充 Clash 功能的專案，也是至今常見的稱呼 設定是否使用 Meta 系列支援的協定、規則與 DNS 選項
mihomo Clash Meta 後續採用的專案名稱 目前用戶端實際封裝的核心版本與功能說明

如何查看版本沿革與維護狀態

Clash 原版已停止公開開發。它建立了常見的 YAML 設定結構，例如 proxies、proxy-groups 和 rules，因此不少教學仍以「Clash 設定」統稱這類檔案。但設定結構相似，不代表新欄位能在舊核心上運作。用戶端若多年未更新，也可能繼續使用發布時隨附的核心；只更新訂閱並不會自動更換核心。

Clash Meta 延續原有使用方式並加入新功能，後來以 mihomo 之名繼續發布。要確認目前的維護狀態，應查看用戶端提供的核心版本與更新紀錄：有些用戶端會隨安裝程式一併更新核心，有些則允許在設定中個別切換或更新核心。請勿把用戶端版本號當成核心版本號。例如「用戶端 2.0」只代表介面程式的版本，無法據此判斷是否支援某項 mihomo 規則。

在目前裝置上檢查三個位置

  1. 開啟用戶端的「設定」或「關於」頁面，尋找「核心」、「Core」、「Kernel」及其版本號。各款用戶端的選單名稱可能不同，請以頁面上的實際標示為準。
  2. 查看執行記錄的啟動內容。核心名稱、設定載入錯誤及監聽連接埠通常會在啟動時顯示；執行記錄比安裝檔名稱更能反映目前正在執行的程式。
  3. 若用戶端提供「切換核心」功能，先記下目前的選項，再確認目標核心與設定檔相容。切換後重新載入設定，並檢查記錄中是否仍有未知欄位或規則解析錯誤。

協定支援：檢查節點欄位與核心版本

選擇核心最直接的依據是訂閱中的節點類型。Clash 原版的常見設定主要使用 Shadowsocks、VMess、Trojan、SOCKS5 和 HTTP 等類型。mihomo 除了支援這些類型，也涵蓋更多協定及擴充寫法，常見需求包括 VLESS、Hysteria2 和 TUIC。不過，mihomo 支援某項協定，不代表所有版本都支援該協定的每個參數；仍應以已安裝的核心版本及其設定說明為準。

取得訂閱後，可以檢查 YAML 中 proxies 下各節點的 type。如果節點標示 type: vless，但用戶端使用較早期的 Clash 原版核心，匯入失敗或節點消失，通常是協定不相容，而非系統代理開關未開啟。若訂閱內容只有一長串 Base64 文字或單一節點分享連結，請先確認用戶端是否支援該匯入格式；核心支援某項協定，不代表圖形介面一定能直接解析所有分享連結。

依照錯誤發生順序排查匯入問題

  • 設定尚未載入：檢查 YAML 縮排、欄位拼字，以及用戶端顯示的錯誤行號。YAML 使用空格縮排；同一層級的清單項目應對齊。
  • 無法識別節點類型：核對 type 與目前執行的核心，不要只修改節點顯示名稱。協定參數也必須符合節點伺服器提供的資訊。
  • 設定載入成功但無法連線：先檢查節點位址、連接埠與網路連線，再檢查驗證參數。此時單純更換核心未必能解決問題。

訂閱服務若提供「Clash」、「Clash Meta」、「mihomo」等多種設定格式，請優先選擇與目前核心相符的格式。切換格式前先備份原設定；轉換工具可能會改寫策略群組或規則集參照，匯入成功後仍須確認實際分流結果。

規則、DNS 與 TUN：設定相似，行為未必相同

基礎規則的讀法大致相同：DOMAIN-SUFFIX,example.com,DIRECT 代表符合該網域時直接連線；MATCH,DIRECT 則處理未符合前面規則的連線。規則通常依序比對，由第一條符合的規則決定連線去向。若設定檔包含規則集參照、GEOSITE 等寫法，應確認目標核心是否識別相應的規則類型及其資料來源；不能只因副檔名同為 .yaml 就直接共用。

以下是簡化範例，只用來說明基礎規則與監聽連接埠的關係。mixed-port: 7890 表示本機的 HTTP/SOCKS 混合代理連接埠；external-controller 使用本機位址與連接埠 9090。範例中的規則全部指向 DIRECT，沒有代理節點，不能當成已設定完成的代理訂閱。

mixed-port: 7890
mode: rule
external-controller: 127.0.0.1:9090
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,DIRECT

DNS 與 TUN 更需要分開檢查。DNS 設定決定網域名稱的解析方式；TUN 模式則透過虛擬網路介面接管符合條件的裝置流量。啟用 TUN 後，用戶端可能需要取得系統授予的網路介面權限，但 TUN 本身無法修復失效的節點，也不會自動補上缺少的規則集。若遇到「網頁能開啟，某個應用程式卻沒有走代理」，請先確認該應用程式的連線是否出現在核心記錄中，再檢查系統代理與 TUN 的啟用狀態、路由設定及規則比對結果。

依目前的用戶端與設定選擇

現有設定運作正常

先記下用戶端名稱、核心名稱、核心版本及設定來源。若訂閱只包含目前核心支援的節點類型，規則模式下的網站分流也符合預期，就可以繼續使用現有組合。若打算更換用戶端，請先匯出或備份 YAML，再匯入新用戶端並檢查策略群組選擇；群組名稱相同，不代表新用戶端會保留先前選取的節點。

新訂閱使用擴充協定或規則

優先選擇明確標示使用 mihomo 核心，且版本支援所需欄位的用戶端。匯入後檢查三處：節點是否完整顯示在清單中、策略群組是否有引用這些節點，以及連線記錄是否顯示預期的規則比對結果。節點名稱出現在清單中，不代表協定交握或分流已成功。比較不同用戶端時，應分別評估「介面是否適合裝置」與「核心是否能讀取設定」這兩項條件。

用戶端只顯示 Clash，未說明核心

先查看「關於」頁面與啟動記錄；仍無法確認時，可查閱用戶端的發布說明或專案文件。不要因介面上有 TUN 開關就認定它採用 mihomo，也不要因檔名包含 Meta 就認定執行時已成功切換。確認核心後，再依照相應文件檢查訂閱中的協定、rule-providers、DNS 欄位及 TUN 設定。

選擇核心時，應以現有設定與使用情境為準：基礎規則及舊訂閱要留意遷移成本；使用 VLESS、Hysteria2、TUIC 等節點時，要核對具體版本；若需要接管整台裝置的流量，也要確認用戶端在該作業系統上的 TUN 設定與授權流程。選定後，分別測試常用網站與需要特定規則的網站，並對照連線記錄確認實際連線出口。

查看用戶端安裝檔