mihomo 內核與原版 Clash 有什麼區別?Meta 分支特性一覽

從 Clash 到 Clash Meta 再到 mihomo:一段內核演進史

原版 Clash 內核由 Dreamacro 發起,採用 Go 語言實作,確立了 config.yaml 的基本結構、代理群組抽象與規則比對引擎,是後續所有分支的起點。隨著協定演進(如 Hysteria2、TUIC、WireGuard 陸續出現)與使用者對更細緻控制的需求增長,社群在原版基礎上開出了 Clash Meta 分支,持續合併新協定、新規則類型與效能優化。原版倉庫自 2022 年之後更新趨緩,而 Clash Meta 在活躍維護下逐步反超原版的功能覆蓋面,並最終改名為 mihomo,作為獨立專案繼續演進。

目前「mihomo 內核」這個說法,在語境上基本等同於早期的「Clash Meta 內核」——兩者是同一條開發脈絡的不同階段命名,協定前綴、設定欄位大體相容,只是包體、版本號與部分預設行為隨迭代發生了變化。理解這段脈絡,有助於判斷某個客戶端所標註的「內核版本」到底對應哪一套能力集。

出站協定支援:mihomo 新增了哪些協定

協定支援是兩套內核最直觀的差異。原版 Clash 內核聚焦於 Shadowsocks、ShadowsocksR、VMess、Trojan、Snell 等較早成熟的協定,設定欄位相對固定,長期沒有大的擴充。mihomo 在此基礎上補齊了近年新增的出站類型,常見的包括:

• Hysteria / Hysteria2:基於 QUIC 的壅塞控制協定,在弱網、高丟包連線下表現優於傳統 TCP 類協定。
• TUIC:同樣構建在 QUIC 之上,專注於低延遲場景,適合對互動延遲敏感的使用情境。
• WireGuard:作為出站協定直接接入,不再需要額外的系統層級 WireGuard 客戶端配合。
• VLESS / VMess 的流量控制擴充,以及 ShadowTLS 前置層,用於進一步混淆流量特徵。
• Snell v4 等協定的新版本欄位支援。

這意味著如果訂閱節點使用了上述較新協定,只有 mihomo 內核能正確解析並建立連線;原版內核遇到未知協定類型時,通常會直接跳過該節點或報錯,導致代理群組裡出現「節點數量對不上」的現象。

規則集與 GEO 資料:更新機制的差異

規則分流依賴 GEOIP、GEOSITE 資料庫與規則集(rule-provider)判斷網域或 IP 歸屬。原版內核的 GEO 資料格式相對固定,更新頻率取決於內核自身發布節奏;mihomo 支援更靈活的規則集來源與格式:

1. 支援 rule-set 引用遠端規則集,並可指定 behavior(domain / ipcidr / classical)與更新間隔,規則內容與內核版本解耦,不需要等內核發新版本就能取得最新分流規則。
2. 支援 MRS(mihomo 專用二進位規則格式),比傳統文字規則載入更快,尤其在規則條目達到數萬級別時,啟動與比對效能差異明顯。
3. GEO 資料庫來源可自訂,允許指向社群維護的 GeoIP2/GeoSite 資料倉庫,而不必依賴內核內建的固定版本。

對一般使用者而言,直觀的體現是:使用 mihomo 內核的客戶端在「規則提供者」設定裡,通常能看到更豐富的行為選項與更短的更新週期;而基於原版內核的客戶端,規則更新往往要跟隨整個客戶端版本一起發布。

TUN 模式與網路堆疊:mihomo 的底層改進

TUN 模式讓 Clash 能接管系統層級流量,而不僅是瀏覽器等支援代理設定的應用程式。原版內核對 TUN 的支援相對基礎,依賴系統路由表手動設定;mihomo 在這一層做了較多改進:

• 內建 自動路由管理,建立虛擬網卡後自動寫入並在退出時清理路由表項目,減少手動設定出錯的機率。
• 支援在 gVisor 使用者態堆疊與 系統原生堆疊(system stack)之間切換,前者相容性更好,後者在部分平台上效能更優,可依需求取捨。
• 增強了 DNS 劫持與 Fake-IP 池與 TUN 模式的配合,減少因 DNS 解析路徑不一致導致的連線失敗。
• 對 Android、macOS 等平台的虛擬網卡權限處理進行了適配優化,降低系統層面被中斷連線的機率。

這也是為什麼絕大多數需要「全域透明代理」「接管系統全部流量」場景的客戶端,都會優先選擇 mihomo 內核——TUN 模式的穩定性直接影響日常使用體驗。

RESTful API 與設定能力增強

兩套內核都提供基於 HTTP 的外部控制介面(通常監聽在 127.0.0.1:9090 一類位址),供客戶端介面查詢代理狀態、切換節點、查看日誌。mihomo 在這套 API 之上做了擴充:

• 新增更細緻的介面,例如按分組查詢延遲、按規則提供者單獨觸發更新,而不必重新載入整份設定。
• 支援 Script 規則與 Lua 邏輯判斷等進階比對方式,允許在規則檔案裡寫簡單腳本邏輯,而不是只能羅列靜態規則。
• 對 Provider 覆寫(override)能力做了增強,可以在不修改訂閱本身的前提下,透過本地覆寫規則調整某些欄位(如強制啟用 UDP、修改測速 URL)。

這些能力主要面向進階使用者與客戶端開發者,一般使用者不需要直接呼叫 API,但客戶端介面上「測速方式可自訂」「某個代理群組支援腳本選擇器」這類設定項,背後往往就是內核 API 擴充帶來的。

主流客戶端內建的是哪套內核?

選客戶端時,內核版本決定了功能上限。下表列出常見客戶端與其對應內核情況,供快速核對:

需要注意的是,同一個客戶端專案也可能隨版本遷移內核,例如從早期依賴原版內核轉向內建 mihomo。下載前查看客戶端發布說明或設定頁裡的「內核版本」欄位,是確認實際能力的最可靠方式,比單看客戶端名稱更準確。

該如何選擇?

如果訂閱節點使用了 Hysteria2、TUIC、WireGuard 等較新協定,或者需要穩定的全域 TUN 模式、更靈活的規則集更新,選擇內建 mihomo 內核的客戶端幾乎是唯一合理選項。如果只是使用 Shadowsocks、VMess 等經典協定,並且客戶端介面、操作習慣已經比較熟悉,原版內核的客戶端也能滿足基礎的分流與切換需求,不必強行遷移。

兩套內核都遵循 GPL-3.0 開源授權,設定檔語法高度相容,大多數 config.yaml 可以在兩者之間直接遷移,只是涉及新協定或新規則語法的部分,原版內核會無法識別,這一點在切換客戶端前值得提前確認。