Clash 原版、Meta 與 mihomo 核心差異:版本演進與相容性比較

整理 Clash 原版核心、Clash Meta 到 mihomo 的演進脈絡,比較協定支援、規則類型與設定欄位差異,說明各用戶端採用的核心版本。

先分清核心、用戶端與設定檔

核心是負責代理連線、DNS 處理與規則比對的程式;用戶端則是管理這些功能的介面。用戶端可能在更新後更換核心,也可能讓使用者手動選擇核心。因此,軟體名稱中有 Clash,不代表它支援哪些協定。

設定檔則是核心讀取的輸入資料。副檔名同為 .yaml,只代表檔案採用 YAML 語法,不代表不同核心都能辨識其中的節點類型、規則類型與擴充欄位。

  • 用戶端版本:用來排查介面、系統代理開關、訂閱管理與安裝問題。
  • 核心名稱與版本:用來判斷 VLESS、Hysteria2、TUN 及特定設定欄位是否可用。
  • 設定檔產生目標:確認訂閱轉換器輸出的是 Clash 原版設定,還是適用於 Meta/mihomo 的設定。

演進脈絡:原版、Premium、Meta 與 mihomo

Clash 原版與 Clash Premium 是功能範圍不同的兩條分支

一般所說的 Clash 原版,指 Dreamacro 專案體系下的 Clash。討論相容性時,還要區分開源核心與 Premium 核心。Premium 曾提供 TUN、規則集與指令碼等擴充功能,不能把 Premium 的功能直接當成原版開源核心也具備的功能。

原專案體系於 2023 年 11 月停止公開維護。已安裝的舊版程式不會因此立刻失效,但不應期待它們持續支援新協定、新欄位或後續相容性修正。

Clash Meta 是擴充分支,後續更名為 mihomo

Clash Meta 以 Clash 為基礎,擴充協定、DNS、路由與連線處理能力,之後專案更名為 mihomo。兩者是同一專案的演進關係,不是必須串接執行的兩個程式,也不需要先安裝 Meta 才能使用 mihomo。

舊教學中的「Meta 核心」、設定檔註解中的 Meta,以及新用戶端顯示的 mihomo,通常都指向這條專案脈絡。不過,即使屬於同一脈絡,版本仍有差異:早期 Meta 版本不能直接視為較新的 mihomo 版本。

核心名稱定位相容性重點
Clash 開源核心原專案的開源基礎實作以傳統節點協定與基礎規則為主
Clash Premium原專案的擴充核心具備 TUN、規則集、指令碼等功能,不能與開源版混為一談
Clash Meta擴充協定與路由功能的分支許多設定與教學仍沿用 Meta 名稱
mihomoMeta 專案的後續名稱新協定與擴充欄位應以實際建置版本為準

協定支援:節點能否解析,比介面能否匯入更重要

節點協定由設定中的 type 欄位指定。用戶端可能成功儲存訂閱檔案,但直到啟動核心時才回報不支援該代理類型。此時更換代理模式或修改監聽連接埠,都無法解決協定解析問題。

協定或功能Clash 原版開源核心mihomo
HTTP、SOCKS5、Trojan、VMess屬於常見支援範圍支援;仍須逐項確認傳輸方式與 TLS 參數
Shadowsocks支援傳統實作範圍內的加密方式支援;實際加密方式依實作與版本而定
VLESS 與 REALITY不支援此組合支援相應的節點設定
Hysteria2不支援支援 type: hysteria2
TUIC不支援支援;須符合伺服器端的協定版本與參數

REALITY 並非獨立的代理類型

在常見的 mihomo 設定中,REALITY 是 VLESS 節點使用的安全握手相關設定,而不是將 type 設為 reality。請確認 type: vless、tls、servername、reality-opts 等欄位與伺服器端設定一致。支援 VLESS,也不代表任意傳輸組合與新增參數都適用。

訂閱轉換無法讓舊核心支援新協定

轉換器可以重新排列 YAML、建立策略群組,或將 URI 參數對應到欄位,卻無法讓原版核心具備 Hysteria2 實作。轉換後的節點清單若少了節點,應先確認轉換目標是否篩除了不支援的協定,而不是直接認定訂閱失效。

訂閱網址通常包含存取權杖。排查問題時,只提供已遮蔽敏感資訊的單一節點結構、錯誤訊息與核心版本;不要將完整訂閱連結貼到公開討論區。

規則與欄位:基礎語法相近,擴充功能不可反向套用

mixed-port、mode、proxies、proxy-groups 與 rules 是常見的設定項目。DOMAIN、DOMAIN-SUFFIX、IP-CIDR、MATCH 等基礎規則也廣泛沿用,但這不代表整份設定可以任意複製到不同核心使用。

  • 規則集:rule-providers 與 RULE-SET 都用於 Premium 和 mihomo,不能因此推論原版開源建置也支援。
  • 擴充規則:mihomo 的邏輯組合、程序路徑與入站相關規則等功能,須確認具體規則名稱及版本需求。
  • 規則檔案格式:純文字、YAML 與 mihomo 的 MRS 格式並不能只靠修改副檔名互相轉換。
  • 指令碼:Premium 的 script 設定不能視為 mihomo 通用的相容介面;遷移時通常需要改寫成規則或其他受支援的機制。
  • DNS 擴充:fake-ip、DNS 策略與流量嗅探屬於不同層次的設定;舊範例中的欄位名稱與預設行為,不能直接視為新版規範。

以下是一份刻意只保留基礎欄位的測試設定。它會監聽本機 7890 連接埠、採用規則模式,並將最後的流量交給 DIRECT。此設定用來確認核心能否載入並接受本機代理連線,不包含遠端代理節點。

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

proxies: []

proxy-groups:
  - name: 出口選擇
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,出口選擇
  - MATCH,DIRECT

基礎設定能順利啟動後,再逐步加入節點、DNS、規則集與 TUN。若一次匯入數百行擴充設定,錯誤可能同時來自欄位、檔案路徑與外部資源,排查成本會大幅增加。

TUN 與 DNS:核心支援只是啟用條件之一

TUN 透過虛擬網路介面接收經路由轉送的流量,適合接管未遵循系統代理設定的程式。它不是第四種代理模式:啟用 TUN 後,後續流量仍可由 rule、global 或 direct 決定如何處理。

Clash 原版開源核心與 Premium 在這方面有明顯差異;mihomo 也支援 TUN,但仍需搭配作業系統權限、路由設定與用戶端整合。桌面系統通常需要管理員權限或服務模式;Android 用戶端通常透過系統 VPN 授權接入。

mihomo 的 TUN 欄位範例

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

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

這是設定片段,並非適用於所有平台的獨立設定。1053 是範例中的核心 DNS 監聽連接埠,any:53 則是常規 DNS 流量的攔截目標;兩者不必設定為相同連接埠。範例中的上游 DNS 必須能從目前的網路連線,否則請改用可用的解析器。

  • stack: mixed 是 mihomo 提供的選用網路堆疊設定之一,不可直接複製到所有舊版核心。
  • auto-route 用來自動設定相關路由,不代表一定能繞過其他 VPN、路由器策略或防火牆限制。
  • auto-detect-interface 用來自動偵測出口介面;在多網卡環境中仍須確認實際選用的出口。
  • 應用程式自行發出的 HTTPS DNS 請求不一定會被 any:53 攔截,還需檢查應用程式的安全 DNS 設定與連線紀錄。

若啟用 TUN 後完全無法連線,請先關閉 TUN,確認只使用本機 7890 連接埠時能否正常連線。若基礎代理可用、TUN 卻無法使用,再檢查權限、路由與 DNS,不要立刻更換訂閱。

確認用戶端對應的核心與版本

用戶端名稱只能作為初步線索,最後仍應以目前安裝套件實際執行的核心為準。部分用戶端提供核心切換、測試版更新管道或自訂二進位檔路徑;安裝套件的介面版本與核心版本也不一定同步更新。

用戶端或系列常見核心對應關係確認重點
Clash for Windows 舊版官方舊版常見搭載 Premium 核心不要只因介面相似,就直接套用 mihomo 設定
Clash for Android 舊版存在不同的建置分支記下完整版本、建置來源與核心記錄
Clash Verge Rev採用 mihomo查看目前選用的核心及其版本
FlClash以 mihomo 為基礎分辨應用程式版本與核心版本
其他名稱中含有 Clash 的用戶端無法只憑名稱判斷查看關於頁面、啟動記錄或核心檔案

若可使用命令列,直接查詢二進位檔

# Linux 或 macOS:在實際核心所在目錄執行
./mihomo -v
./mihomo -t -f ./config.yaml

# Windows PowerShell:在實際核心所在目錄執行
.\mihomo.exe -v
.\mihomo.exe -t -f .\config.yaml

-v 用來輸出版本資訊,-t 用來測試設定。用戶端可能會重新命名檔案,請使用實際檔名。測試包含相對路徑的規則集或憑證時,工作目錄也應與用戶端的執行環境一致;必要時可用 -d 指定設定目錄。

測試通過只代表這次檢查沒有發現會阻止載入的問題,不代表遠端節點可連線,也不代表 TLS 參數正確。若無法使用命令列,可在用戶端的「關於」或「核心」頁面,以及啟動記錄中尋找核心名稱與版本;各用戶端的選單路徑不盡相同。

遷移檢查順序:先載入,再連線,最後確認規則

  1. 備份目前設定。備份現有設定、訂閱來源、策略群組選擇,以及 DNS 和 TUN 設定,並保留可還原的用戶端環境。
  2. 選擇正確的訂閱目標。若節點包含 VLESS、REALITY、Hysteria2 等協定,優先使用服務提供者明確標示的 Meta/mihomo 設定,不要只看「Clash」字樣。
  3. 測試最終設定。用戶端可能會合併訂閱、覆寫檔案及介面設定,應盡可能檢查實際交由核心使用的設定,而不只是下載的原始 YAML。
  4. 確認基礎連線。暫時關閉 TUN,使用明確指定的本機連接埠進行測試。系統代理、應用程式代理與核心監聽連接埠必須一致。
  5. 確認規則比對結果。檢查連線紀錄中的網域、命中規則與出口策略,避免把選錯策略群組誤判為核心不相容。
  6. 逐項恢復擴充功能。依序啟用 DNS 策略、規則集、流量嗅探與 TUN;每新增一項,就重複相同的連線測試。

例如,本機混合連接埠為 7890 時,可使用下列命令明確指定 HTTP 代理,避免測試結果受到系統代理開關影響。系統必須已安裝 curl。

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 -I https://example.com

範例將連線逾時設為 10 秒,只用來限制等待時間,不代表實際測得的延遲。收到 HTTP 回應代表這次請求經過本機代理入口;是否經由遠端節點,仍須查看核心連線紀錄。若使用前述基礎設定,請求最後會走 DIRECT。

安裝前可先查看用戶端選型指南;核對欄位時可參閱設定參考。判斷相容性時,應依序確認「實際核心 → 設定欄位 → 執行結果」,不要先根據用戶端名稱下結論。

Clash 下載