內核發展脈絡:為什麼會出現 mihomo
原版 Clash 內核由 Dreamacro 主導開發,長期是 Clash 生態事實上的標準實作,協定支援涵蓋 Shadowsocks、Vmess、Trojan 等主流方案,規則引擎與設定格式也成為後續眾多用戶端的基準。2023 年前後,原作者帳號與相關程式碼儲存庫被下架,原版內核的更新隨之停止。
社群隨即以 Clash Meta 分支延續開發,後重新命名為 mihomo。這不是單純的改名,而是在原有程式碼基礎上持續合入新協定、新特性,逐漸形成一套功能範圍明顯超出原版的實作。目前主流的 Clash 類用戶端,包括 Clash Verge、Clash for Windows 的後續替代品、多數行動端用戶端,底層內核基本都已切換為 mihomo,原版內核僅作為歷史版本存在於部分老舊用戶端中。
理解這段脈絡有一個直接的現實意義:如果你正在使用某個仍標注「Clash 內核」卻長期不更新的用戶端,大概率用的是原版內核,協定支援範圍會明顯落後於目前主流節點服務商提供的協定種類。
協定支援範圍對比
協定支援是兩者最直觀的差異。原版內核支援的協定種類基本停留在停止維護前的狀態,mihomo 在此基礎上持續新增,目前的支援範圍明顯更廣。
| 協定 | 原版 Clash 內核 | mihomo |
|---|---|---|
| Shadowsocks | 支援 | 支援,含更多加密方式 |
| Vmess | 支援 | 支援 |
| Trojan | 支援 | 支援 |
| VLESS | 不支援 | 支援 |
| Hysteria / Hysteria2 | 不支援 | 支援 |
| TUIC | 不支援 | 支援 |
| WireGuard(作為出站) | 不支援 | 支援 |
| SSH(作為出站) | 不支援 | 支援 |
其中 VLESS 與 Hysteria2 是近兩年節點服務商端使用率上升較快的兩類協定。VLESS 常搭配 XTLS 或 Reality 傳輸層用於對抗特徵識別;Hysteria2 基於 QUIC,在弱網、高延遲或存在丟包的連線上表現出比傳統 TCP 類協定更好的吞吐穩定性。如果訂閱裡包含這兩類協定節點,原版內核會直接解析失敗或節點不可用,必須切換到 mihomo 內核的用戶端才能正常連線。
判斷自己使用的用戶端是哪個內核,可以查看用戶端的「內核版本」或「關於」頁面。標注 mihomo 或 Clash.Meta 的即為新內核;僅標注純數字版本號且長期停留在舊版本的,多半是原版內核。
TUN 模式:從外部外掛到內建能力
TUN 模式(也稱虛擬網卡模式)是指內核在系統層建立一個虛擬網路介面,攔截全部或指定範圍的系統流量並交由代理規則處理,不再依賴應用層的系統代理設定。這種方式的優勢在於覆蓋面更廣:不支援系統代理設定的程式、部分遊戲用戶端、系統層服務的網路請求,都能被納入分流範圍。
原版 Clash 內核本身不包含 TUN 能力,早期實作依賴額外的輔助程式或系統層驅動配合才能實現類似效果,設定門檔較高,且跨平台一致性差,Windows、macOS、Linux 各自需要不同的適配方案。
mihomo 將 TUN 模式作為內核原生功能內建,設定項直接寫在核心設定檔的 tun欄位下,不再需要額外驅動或外掛配合(部分平台仍需要系統授予虛擬網卡建立權限,這屬於系統層的正常授權流程)。一個典型的 mihomo TUN 設定片段:
tun:
enable: true
stack: system
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53stack欄位可選 system、gvisor等不同網路堆疊實作,分別在相容性與效能上有所取捨;auto-route開啟後由內核自動接管系統路由表,避免手動設定路由規則。這部分能力是原版內核完全不具備的,也是許多使用者從原版切換到 mihomo 的直接原因之一。
規則引擎與規則集能力強化
規則分流是 Clash 類用戶端的核心機制,透過比對網域、IP 段、行程名稱等條件,決定每一條連線走哪個代理節點或是否直連。原版內核的規則類型集中在 DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD、IP-CIDR、GEOIP等基礎類型上,規則集(Rule Provider)機制也相對簡單。
mihomo 在此基礎上做了幾方面強化:
- 規則集格式擴充:除原有的 YAML 列表格式外,新增對 MRS(mihomo 專屬二進位規則集格式)的支援,體積更小、載入更快,適合體量較大的規則庫。
- 邏輯規則:支援
AND、OR、NOT等邏輯組合規則,可以將多個比對條件組合成一條規則,減少規則數量、提升可維護性。 - 行程比對規則:
PROCESS-NAME、PROCESS-PATH等依發起連線的行程名稱或路徑分流的規則類型,在原版中支援範圍有限,mihomo 下更完整,尤其在桌面端按應用分流的場景中很實用。 - 子網規則與腳本規則:進一步細化了比對維度,便於處理複雜的分流策略。
對於已經在用規則集(而非把全部規則寫在主設定檔裡)的使用者,這部分變化通常是無感的——規則集網址本身不受內核切換影響,但如果規則集作者開始使用 mihomo 專屬的規則類型或 MRS 格式,原版內核解析該規則集時就會出錯或規則失效。
設定檔相容性與遷移要點
mihomo 在設計上保持了對原版 Clash 設定格式較高的向後相容,基礎欄位結構(proxies、proxy-groups、rules等頂層欄位)基本一致,這意味著大多數原版設定檔可以直接在 mihomo 用戶端下正常載入執行。但從原版切換到 mihomo 時,仍有幾個需要留意的地方:
- 新協定節點需要用戶端支援才能生效:設定檔裡出現 VLESS、Hysteria2 等原版不支援的協定節點時,原版內核會跳過該節點或直接報錯,切換到 mihomo 後節點才會正常出現在代理群組列表中。
- 欄位名稱存在部分差異:少數欄位在 mihomo 中有更精確的命名或新增了選用參數,例如 TUN 相關設定整體是 mihomo 新增欄位,原版設定檔中不存在,需要根據 mihomo 文件補充,而不是從舊設定裡「複製」過來。
- Provider 拉取行為略有不同:mihomo 對 Proxy Provider、Rule Provider 的健康檢查與更新策略做了最佳化,拉取失敗時的重試邏輯更穩健,但基礎欄位(
url、interval、path)保持一致,無需改動。 - GEOIP 資料庫格式:mihomo 預設使用 mihomo geoip 資料庫,與原版使用的 GeoLite2 系列資料庫格式不完全相同,首次切換時用戶端通常會自動下載適配的資料庫檔案,若網路環境導致下載失敗,GEOIP 類規則會暫時不生效,直連與代理判斷退化為按其他規則處理。
遷移前建議先備份原有設定檔。切換內核後如果發現代理群組為空或規則大量失效,優先檢查設定檔裡是否引用了 mihomo 才支援的欄位或規則集格式,而不是懷疑訂閱本身失效。
對絕大多數一般使用者而言,遷移路徑其實很簡單:直接更換支援 mihomo 內核的用戶端安裝包,設定檔或訂閱連結原樣匯入即可,無需手動改寫欄位。只有在自行編寫複雜規則或使用了邏輯規則等 mihomo 專屬語法時,才需要額外關注格式細節。
該如何選擇:是否需要切換到 mihomo 內核
結合前面的對比,提供幾條判斷依據:
- 如果訂閱節點包含 VLESS、Hysteria2、TUIC 等新協定,必須使用 mihomo 內核,原版內核無法解析這些節點。
- 如果需要 TUN 模式實現全域透明代理,尤其是需要覆蓋遊戲、系統層服務等不支援系統代理的場景,mihomo 內核是唯一原生支援的選擇。
- 如果只使用 Shadowsocks、Vmess、Trojan 等基礎協定,且不需要 TUN 模式,原版設定在兩種內核下都能正常運作,但由於原版內核已停止更新,長期使用仍建議切換到持續維護的 mihomo,以取得安全更新與穩定性改進。
- 規則集作者若已遷移到 mihomo 專屬語法或 MRS 格式,繼續使用原版內核會導致規則集載入失敗,這種情況下切換內核是唯一解決方式。
目前主流 Clash 類用戶端已普遍預設整合 mihomo 內核,並在用戶端設定中提供內核版本管理入口,允許在多個 mihomo 版本之間切換,而不必額外單獨下載內核檔案。對於新使用者,直接選擇目前維護中的用戶端安裝,基本不會遇到內核選擇的問題;對於長期使用原版內核老用戶端的使用者,建議評估節點協定與功能需求後,盡快遷移到基於 mihomo 的替代用戶端。