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 名稱 |
| mihomo | Meta 專案的後續名稱 | 新協定與擴充欄位應以實際建置版本為準 |
協定支援:節點能否解析,比介面能否匯入更重要
節點協定由設定中的 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 參數正確。若無法使用命令列,可在用戶端的「關於」或「核心」頁面,以及啟動記錄中尋找核心名稱與版本;各用戶端的選單路徑不盡相同。
遷移檢查順序:先載入,再連線,最後確認規則
- 備份目前設定。備份現有設定、訂閱來源、策略群組選擇,以及 DNS 和 TUN 設定,並保留可還原的用戶端環境。
- 選擇正確的訂閱目標。若節點包含 VLESS、REALITY、Hysteria2 等協定,優先使用服務提供者明確標示的 Meta/mihomo 設定,不要只看「Clash」字樣。
- 測試最終設定。用戶端可能會合併訂閱、覆寫檔案及介面設定,應盡可能檢查實際交由核心使用的設定,而不只是下載的原始 YAML。
- 確認基礎連線。暫時關閉 TUN,使用明確指定的本機連接埠進行測試。系統代理、應用程式代理與核心監聽連接埠必須一致。
- 確認規則比對結果。檢查連線紀錄中的網域、命中規則與出口策略,避免把選錯策略群組誤判為核心不相容。
- 逐項恢復擴充功能。依序啟用 DNS 策略、規則集、流量嗅探與 TUN;每新增一項,就重複相同的連線測試。
例如,本機混合連接埠為 7890 時,可使用下列命令明確指定 HTTP 代理,避免測試結果受到系統代理開關影響。系統必須已安裝 curl。
curl --proxy http://127.0.0.1:7890 --connect-timeout 10 -I https://example.com
範例將連線逾時設為 10 秒,只用來限制等待時間,不代表實際測得的延遲。收到 HTTP 回應代表這次請求經過本機代理入口;是否經由遠端節點,仍須查看核心連線紀錄。若使用前述基礎設定,請求最後會走 DIRECT。
安裝前可先查看用戶端選型指南;核對欄位時可參閱設定參考。判斷相容性時,應依序確認「實際核心 → 設定欄位 → 執行結果」,不要先根據用戶端名稱下結論。