核心解析 預計閱讀 10 分鐘

Clash 原版、Meta 與 mihomo 核心版本差異比較

整理 Clash 原版核心、Clash.Meta 與 mihomo 的演進脈絡，比較協定支援、規則類型、TUN 實作與設定欄位差異，協助確認現有設定是否能直接沿用。

先說結論：Meta 與 mihomo 屬於同一條演進脈絡

遷移前，先確認用戶端實際執行的核心，再檢查訂閱格式。Clash.Meta 後來更名為 mihomo，兩者並非彼此無關的設定體系。大多數基礎 Clash YAML 設定都能作為遷移起點；反過來說，使用 mihomo 擴充欄位的設定交給舊版 Clash，則不保證能正常運作。

核心負責解析設定、比對規則及建立代理連線；用戶端則負責介面、訂閱管理與系統授權等操作。同一款用戶端的不同發行版本，也可能搭載不同核心。因此，只知道「安裝了 Clash」，不足以判斷是否支援某個協定。

名稱、維護狀態與設定相容範圍

名稱 定位與狀態 遷移時的檢查重點
Clash 原版開源核心 原始開源實作，原專案已停止維護 基礎協定與基礎規則；不應預期支援後續新增的協定
Clash Premium 過去的閉源增強版，已停止維護 TUN、規則提供者及指令碼等舊功能的遷移方式
Clash.Meta 由 Clash 演進而來的分支，也是 mihomo 的舊名稱 舊版是否支援設定中使用的新欄位
mihomo 延續 Meta 路線，持續擴充協定、規則與網路功能 具體版本、作業系統平台及用戶端的覆寫行為

如何確認目前執行的核心

  1. 開啟用戶端的「關於」、「核心」或啟動記錄頁面。選單名稱依用戶端而異，沒有適用於所有手機的固定路徑。
  2. 記下核心名稱、完整版本號、裝置系統及用戶端版本，不要只記錄應用程式商店顯示的版本。
  3. 若桌面環境能直接執行核心，可執行 mihomo -v 查看版本。這個指令查詢的是指定的執行檔，不代表手機應用程式內建的版本。

舊設定的備註若標示「Meta 專用」，通常表示它依賴增強功能，不代表一定得找名為 Meta 的舊安裝套件。判斷依據應是目標 mihomo 版本是否支援所用欄位，而非名稱是否一致。

協定差異：成功匯入節點不代表連線正常

協定是用戶端與代理伺服器之間的通訊約定。原版 Clash 常見設定包含 Shadowsocks、VMess、Trojan、SOCKS5 和 HTTP 代理。mihomo 在此基礎上擴充 VLESS、Hysteria2、TUIC、WireGuard 等協定支援，但實際功能仍視核心版本與平台而定。

新協定還得核對傳輸參數

遇到「不支援的代理類型」時，先查看設定中的 type 和核心版本。若是交握失敗或逾時，則繼續檢查伺服器位址、連接埠、裝置時間、驗證參數與網路狀況。別把所有連線失敗都歸咎於核心不相容，也不要以關閉憑證驗證來代替問題排查。

規則差異：基礎語法相近，擴充規則須逐項確認

規則會由上而下比對，符合後便交由對應策略處理。DOMAIN 比對指定網域，DOMAIN-SUFFIX 比對網域及其子網域，IP-CIDR 比對 IP 網段，MATCH 則作為最後的兜底規則。這些基礎概念在不同分支間大致相同。

規則提供者不只是規則連結

rule-providers 用來宣告外部規則集合，再由 RULE-SET 引用。過去的 Premium 與 mihomo 都具備相關功能，但不能因此推斷所有原版開源版本都能讀取。遷移時要一併檢查提供者類型、檔案格式與內容類型。

從 Premium 遷移時，尤其要單獨檢查 script。舊版指令碼設定不能視為 mihomo 通用的相容介面；較穩妥的做法是先整理指令碼實際執行的條件判斷，再依目標版本支援的規則、邏輯規則或子規則改寫，並逐項測試。

TUN 與手機 VPN：分清核心功能和系統接管

TUN 是透過虛擬網路介面處理網路資料的方式，可讓不讀取系統代理設定的應用程式流量進入代理核心。過去，TUN 是 Clash Premium 與 Meta 等增強路線的重要功能，但不能因此認定每個原版開源 Clash 版本都具備相同實作。

Android 用戶端通常透過 VpnService，也就是系統提供的 VPN 介面，取得接管流量的權限。是否顯示 VPN 授權提示、哪些應用程式會進入通道，以及能否在背景持續執行，都會受到用戶端實作與系統限制影響。更換核心不會自動完成這些授權。

如何理解 mihomo 的 TUN 設定片段

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

這是常見桌面情境的欄位示意，並非手機端必須照抄的完整設定。auto-route 用於自動設定相關路由，auto-detect-interface 用於自動偵測對外網路介面，stack 則用來選擇網路堆疊實作。權限、路由處理方式與可用選項，仍須以目標系統及核心版本為準。

設定遷移：先確認基礎設定可用，再還原 DNS 與覆寫

YAML 是一種以縮排表示結構的設定格式。檔案能夠解析，只表示結構基本可讀；有些未知欄位可能會被忽略，不代表預期功能已生效。驗收遷移結果時，還要檢查啟動記錄、連線記錄及實際規則命中情況。

第一步：準備可還原的設定

  1. 保留原訂閱網址、目前設定的副本及用戶端覆寫內容。訂閱網址屬於敏感資訊，分享截圖與記錄前應先遮蔽驗證資訊。
  2. 在新用戶端新增一份設定，不要直接覆蓋舊用戶端正在使用的檔案。
  3. 確認訂閱服務回傳的是 Clash 或 mihomo 可辨識的 YAML，而非其他用戶端格式，或僅包含分享連結的文字。

第二步：用基本設定片段排除問題

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

proxies: []

proxy-groups:
  - name: MANUAL
    type: select
    proxies:
      - DIRECT

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

這份範例僅用來檢查設定載入、連接埠與規則流程；所有流量最後都會直接連線，不提供代理出口。mixed-port: 7890 表示同一個監聽連接埠同時接受 HTTP 與 SOCKS 代理連線。手機上的其他應用程式是否經過此連接埠，仍取決於 VPN 流量接管或應用程式本身的代理設定。

設定載入正常後，再透過用戶端的設定合併或覆寫功能，或在本機測試副本中加入實際節點與策略群組。策略群組名稱必須和規則引用的名稱完全一致。例如規則寫了 PROXY，但設定只有 MANUAL，就必須統一名稱，不能指望核心自動推測。

第三步：還原 DNS，避免一次變更多項設定

遷移驗收：依錯誤層級逐步排查

狀況 優先檢查項目 下一步
設定無法啟動 YAML 縮排、節點類型、策略名稱與核心版本 依記錄中的行號定位，再用最小設定重新測試
監聽連接埠失敗 7890 是否已被另一個執行個體占用 停止重複執行的執行個體，或同步修改監聽連接埠與應用程式代理設定
延遲測試成功，但應用程式無法開啟 測試 URL 與實際目標不同、規則出口、DNS、UDP 查看該應用程式的連線記錄，確認命中的規則與節點
瀏覽器可用，其他應用程式失敗 是否只設定了瀏覽器代理，以及 VPN 應用程式排除清單 檢查系統 VPN 狀態與用戶端的應用程式分流設定

在能直接執行核心的桌面環境，可使用 mihomo -t -f config.yaml 檢查指定檔案。檢查通過不代表伺服器可連線，也不代表用戶端最後執行的就是這份檔案。手機端還要確認「目前啟用的設定」，以及訂閱更新後覆寫是否仍然生效。

最後至少完成三項測試：開啟一個預期直連的網站、開啟一個預期透過代理連線的目標，以及鎖定螢幕後重新連線。分別確認規則命中、出口選擇與背景連線。若需要支援新協定或增強規則，優先選擇核心版本資訊清楚、更新記錄明確的用戶端；即使只使用基礎設定，也應保留原設定副本，逐步遷移，不要一次替換所有網路設定。

下載Clash