Clash 原版、Meta 與 mihomo 核心差異對照:功能、協定與設定相容性

一條演進線:從 Clash 到 Clash Meta 再到 mihomo

要理清三個名字的關係,先看時間順序。最早的 Clash(通常稱為「原版」或「Clash Premium」)由個人開發者維護多年,奠定了規則分流、策略組、Provider 訂閱這套基礎架構,幾乎所有後續用戶端的設定語法都以它為藍本。原作者在 2023 年停止更新並刪除程式碼儲存庫,原版核心就此定格,不再獲得新協定、新欄位的支援。

停更之後,社群裡最活躍的分支專案是 Clash Meta(也叫 Clash.Meta),它在原版程式碼基礎上繼續維護,補齊了原版一直缺失的一些能力,同時保持設定語法高度相容,老用戶幾乎不用改設定就能切換過去。Clash Meta 運營一段時間後,專案正式改名為 mihomo,名字變了但儲存庫、維護團隊與技術路線是連續的,可以理解為「Clash Meta 的延續」,而不是另起爐灶的新專案。

所以現在市面上大多數還在更新的 Clash 系用戶端(桌面端、路由器韌體插件、部分 Android 用戶端),底層跑的核心基本是 mihomo,只是外殼套了不同的圖形介面和品牌名。理解這條演進線,再看後面的功能對照會更容易對號入座。

協定支援差異:原版停更前的能力邊界

協定支援是三代核心最直觀的差異點。原版核心在停更時支援的協定以 Shadowsocks、ShadowsocksR、VMess、Trojan、Snell 為主,這些協定覆蓋了當時絕大多數訂閱場景,但停更之後就再沒有增量。Clash Meta 接棒後陸續加入了 VLESS、Hysteria、Hysteria2、TUIC、WireGuard 等較新的協定,mihomo 延續這條路線持續更新,新增協定特性與交握參數支援的速度明顯快於原版停更前的節奏。

換個角度看這張表:如果你的訂閱節點裡出現了 VLESS 或 Hysteria2 協定,原版核心根本無法解析這類節點,用戶端會直接報錯或跳過該節點;這也是很多人升級用戶端卻發現「節點全部失效」的直接原因——不是訂閱壞了,是核心跟不上協定。

TUN 模式與核心架構:Meta/mihomo 的關鍵升級

TUN 模式(虛擬網卡模式)決定了用戶端能不能接管系統層面的全部流量,而不只是瀏覽器或指定應用程式的流量。原版核心也帶 TUN 支援,但實作相對基礎,行程識別能力有限,遇到需要按應用程式做分流的場景(比如只讓某個遊戲走代理、其他應用程式直連)時經常力不從心。

Clash Meta 在 TUN 模式上做了系統性重寫,引入了更完整的行程比對機制,可以按行程名稱、路徑甚至套件名稱過濾流量,配合規則裡的 process-name、process-path 欄位實現精細分流。mihomo 繼續在這個基礎上優化效能和相容性,尤其是在 Windows 和 macOS 上的 TUN 穩定性、與系統防火牆的協同、IPv6 流量接管等方面都比原版成熟不少。

另外一個容易被忽略的架構差異是核心對多核並發和記憶體佔用的優化。mihomo 在長期運行、節點數量較多的場景下,記憶體增長曲線比原版更平穩,這對需要 7x24 小時常駐的路由器或 NAS 場景尤其重要。如果你的用法是常年背景執行、偶爾切換策略組,選新核心在穩定性上通常更有保障。

設定檔欄位相容性:哪些欄位能直接遷移

好消息是,三代核心的設定檔語法高度同源,核心結構沒有斷裂式變化。port、socks-port、mode、proxies、proxy-groups、rules 這些基礎欄位在原版、Meta、mihomo 裡寫法完全一致,一份寫給原版的設定,拿到 mihomo 上大概率能直接載入並正常運作。

差異主要出現在新增欄位和新協定專屬參數上。舉幾個實際例子:

• tun 段裡的 stack(選擇 gVisor 或 System 網路堆疊)、auto-route、dns-hijack 等子欄位,原版沒有對應實作,寫在原版設定裡會被直接忽略甚至報錯。
• proxies 清單裡 type: vless、type: hysteria2 這類節點宣告,原版核心無法識別 type 欄位的這些取值,載入時會跳過該節點或整段報錯。
• dns 段裡的 enhanced-mode: fake-ip 兩代核心都支援,但 mihomo 在 fake-ip-filter 的比對規則上做了細化,部分寫法在原版裡效果會有出入。
• 規則集(rule-provider)的 behavior 欄位取值在新核心裡支援更多類型,原版僅相容基礎的 domain、ipcidr、classical 三種。

實際操作建議是:從原版遷移到 mihomo 時,設定檔基本可以原樣搬過去,只需要額外補上 tun 段和新協定節點即可;反過來如果要把一份 mihomo 設定降級用在原版核心上,則必須先刪除新協定節點和 tun 進階欄位,否則會導致整份設定載入失敗。

該怎麼選:場景對照建議

結合上面的協定支援、TUN 能力和設定相容性差異,給出幾條實用的選型參考:

1. 訂閱節點包含 VLESS、Hysteria2、TUIC 等新協定:必須選 mihomo 核心,原版核心無法解析這些節點,不存在「勉強能用」的空間。
2. 需要按應用程式做全局代理(遊戲走代理、其他直連):選支援完整行程級 TUN 的 mihomo,原版的行程比對能力有限,規則寫了也可能不生效。
3. 長期掛在路由器或 NAS 上跑:優先 mihomo,記憶體與並發表現更穩定,長時間運行的可靠性更高。
4. 只用最基礎的 Shadowsocks/VMess 節點,設定從多年前就沒變過:兩代核心都能跑,但原版已停止更新,長期看仍建議遷移到持續維護的 mihomo,避免未來訂閱升級協定時無法相容。
5. 拿到別人分享的舊設定檔不確定相容性:先用文字編輯器搜尋設定裡是否出現 vless、hysteria、tuic 關鍵字,以及是否有 tun: 段,出現即說明這份設定是為新核心寫的。

目前主流的 Clash 系用戶端,不管介面叫什麼名字,底層絕大多數都已經切換到 mihomo 核心,這也是本站下載頁預設推薦的核心路線。選核心本質上是在選協定覆蓋面和長期維護保障,新核心在這兩點上都占優,原版更多是作為歷史參照存在。