mihomo 內核與原版 Clash 核心差異全覽:新增協議與規則能力解析
對比 mihomo(Clash Meta)與已封存原版內核在協議支援、規則類型、DNS 能力與 API 上的差異,說明主流客戶端為何全面轉向 mihomo,以及舊設定檔的相容情況。
內核是什麼,和客戶端介面是什麼關係
Clash 生態裡「客戶端」和「內核」是兩個獨立的部分。內核(core)是一個不帶圖形介面的可執行程式,負責解析設定檔、建立代理連線、執行分流規則、處理 DNS 查詢,並透過一個本機 HTTP API(通常監聽 127.0.0.1:9090)對外提供狀態與控制介面。客戶端(Clash Plus、Clash Verge Rev、FlClash 等)則是包裹在內核外面的圖形介面,負責訂閱管理、節點展示、開關切換,底層所有代理工作都是轉發給內核完成的。
這個分層結構決定了一個關鍵事實:客戶端換皮容易,內核換代不易。使用者平時感知到的「介面好不好用」是客戶端層面的差異,而「支不支援某個協議」「某條規則寫不寫得出來」則完全取決於內核版本。這也是為什麼在討論 Clash 生態時,把內核單獨拿出來分析是有必要的。
原版 Clash 內核的現況:已停止更新與封存
最早由社群維護的原版 Clash 內核(倉庫名稱通常寫作 Clash 或 Clash Premium)已經停止更新,倉庫處於封存(archived)狀態,不再接受新的 issue 和 PR,也不會再發布新版本。原因與 Clash for Windows 圖形客戶端下架的背景相似,均涉及原作者帳號與相關倉庫被下線處理。
原版內核在停更時的能力大致停留在以下水準:
- 協議支援:Shadowsocks、ShadowsocksR、VMess、Trojan、Snell 等主流協議,不含 Hysteria、TUIC 等後期出現的協議。
- 規則類型:DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD、IP-CIDR、GEOIP、MATCH 等基礎規則,沒有 rule-providers 遠端規則集機制,也沒有行程層級規則。
- DNS 能力:提供基礎的 DNS 轉發和污染防護,不含 Fake-IP 精細化管理和嗅探(sniffer)能力。
- TUN 模式:早期版本不支援或支援非常有限,跨平台一致性差。
對一般使用者而言,原版內核依然能執行現存的舊設定檔、依然能連上常見節點,不會突然失效。但它不會再取得新特性,遇到的任何 bug 也不會有官方修復,長期使用存在功能落後的風險。
mihomo(Clash Meta)是什麼,與原版是什麼關係
mihomo 的前身是社群分支專案 Clash Meta,在原版內核發展停滯後,由另一批貢獻者基於原版程式碼繼續開發,持續合併新協議、新規則類型和效能優化,後來正式獨立命名為 mihomo。目前市面上幾乎所有仍在活躍更新的桌面與行動客戶端——包括 Clash Plus、Clash Verge Rev、FlClash、Clash Meta for Android 的後續分支——底層跑的都是 mihomo 內核,而不是原版內核。
需要澄清一個容易混淆的地方:mihomo 不是另起爐灶的全新專案,它的設定檔語法與原版內核高度相容,絕大多數原版設定欄位(port、mode、proxies、proxy-groups、rules 等)可以原樣保留,mihomo 在此基礎上做的是「擴充」而非「取代」。這也是為什麼將舊設定檔遷移到搭載 mihomo 內核的客戶端時,大多數場景不需要重寫設定,只需要補充新增欄位即可享受到新能力。
協議支援差異:哪些協議是原版內核跑不了的
協議支援是兩者最直觀的差異。mihomo 在原版協議基礎上新增支援了多種後期出現的傳輸協議,這些協議在延遲和抗封鎖能力上各有側重:
| 協議 | 原版內核 | mihomo | 特點簡述 |
|---|---|---|---|
| Shadowsocks / VMess / Trojan | 支援 | 支援 | 主流協議,兩者均可用 |
| Snell | 支援 | 支援 | 輕量協議,私有實作 |
| Hysteria / Hysteria2 | 不支援 | 支援 | 基於 QUIC,弱網環境下吞吐表現較好 |
| TUIC | 不支援 | 支援 | 基於 QUIC 的低延遲協議 |
| WireGuard(作為出站) | 不支援 | 支援 | 可將 WireGuard 節點納入規則分流 |
| VLESS | 不支援 | 支援 | 較新的傳輸協議,常搭配 XTLS |
如果訂閱節點清單裡出現了 Hysteria2 或 TUIC 類型節點,在原版內核上會直接解析失敗或被跳過,表現為「節點清單裡少了幾個」或客戶端回報設定錯誤。這類問題的根本原因往往不是設定檔寫錯了,而是內核版本太舊,換成基於 mihomo 的客戶端即可解決。
規則能力差異:rule-providers 與更細粒度的比對
規則系統是 mihomo 相對原版內核提升最大的部分之一。原版內核的 rules 欄位只能逐條列出固定規則,規則數量一多,設定檔會變得極其臃腫且難以維護。mihomo 引入了 rule-providers 機制,允許把規則集抽取成獨立的遠端檔案,主設定裡只需引用:
rule-providers:
reject:
type: http
behavior: domain
url: "https://example.com/rules/reject.txt"
path: ./rules/reject.txt
interval: 86400
rules:
- RULE-SET,reject,REJECT
- GEOIP,CN,DIRECT
- MATCH,PROXY規則集檔案會依 interval 指定的週期自動刷新,規則維護者更新分類規則後,使用者端會在背景靜默同步,不需要手動替換整份設定檔。這也是目前主流「一鍵訂閱」設定方案能夠長期保持規則準確性的技術基礎。
除此之外,mihomo 還新增了原版沒有的規則類型:
PROCESS-NAME/PROCESS-PATH:依發起連線的行程名稱或路徑分流,可以做到「只讓某個應用程式走代理,其餘應用程式直連」。IP-CIDR6:IPv6 位址段比對,彌補原版對 IPv6 支援的缺口。SCRIPT(部分實作):允許用簡單腳本邏輯判斷分流條件,適合複雜場景。SUB-RULE:子規則集巢狀引用,便於把龐大規則表拆分成可重複使用的模組。
對絕大多數家庭使用者來說,行程層級規則的意義在於可以精確控制「哪個軟體走代理」,避免規則粒度只能到網域/IP 層面導致的誤判問題。
DNS 與 Fake-IP 能力差異
DNS 處理是另一個體感差異明顯的模組。原版內核的 DNS 模組功能較為基礎,主要解決「DNS 污染導致解析到錯誤 IP」的問題。mihomo 在此基礎上完善了 Fake-IP 機制與嗅探能力:
- Fake-IP 模式:為網域分配一個虛擬 IP 段內的位址,應用程式發起連線時先取得假 IP,真正建連階段再由內核還原出原始網域進行分流判斷,減少了傳統 DNS 模式下「先查詢解析,再判斷分流」的往返延遲,對基於網域分流的規則尤其友善。
- 嗅探(sniffer):對於設定了 IP-CIDR 或 GEOIP 規則卻缺少對應網域資訊的連線,mihomo 可以從 TLS SNI 或 HTTP Host 欄位裡嗅探出目標網域,再套用網域類規則,彌補部分場景下 Fake-IP 與規則不匹配的問題。
- DNS 分流:可以為不同網路環境(中國大陸/海外)設定不同的上游 DNS 伺服器,並結合
fallback-filter判斷結果是否可信,原版內核在這方面的可設定項明顯更少。
Fake-IP 模式下,如果某些應用程式需要取得真實 IP(例如某些下載工具或區域網路服務探索),需要在 fake-ip-filter 裡把對應網域排除,否則可能出現連線異常。這個欄位在原版設定檔裡通常不存在,遷移到 mihomo 後建議按需補充。
API 能力與客戶端聯動差異
內核對外提供的 HTTP API 決定了客戶端能實現哪些即時互動功能。原版內核的 API 涵蓋節點清單、連線狀態、日誌推送等基礎能力。mihomo 在此基礎上擴充了更多可查詢與可控制的介面,包括:
- 依代理群組查詢延遲測速結果,支援並行測速多個策略群組。
- 連線維度的詳細流量統計,區分上傳/下載位元組數與即時速率。
- 規則命中追蹤,可以查到某條連線具體命中了哪一條規則、走了哪個代理。
- 設定熱重載介面,客戶端切換訂閱或修改規則後可以不重啟內核直接生效。
這也解釋了為什麼現在的客戶端能做到「連線詳情頁即時刷新每條流量的規則命中情況」,這類介面能力完全依賴底層 API 是否提供對應資料,原版內核的 API 涵蓋範圍不足以支撐這類介面。
舊設定檔遷移到 mihomo 是否需要重寫
由於 mihomo 在欄位層面對原版保持了良好的向後相容,大多數舊設定檔可以直接匯入執行,常見的遷移動作只是「補充」而非「重寫」:
直接匯入測試
把訂閱連結或本機設定檔原樣加入基於 mihomo 的客戶端,先確認能否正常連線與分流,大部分基礎欄位無需更動。
檢查協議解析錯誤
如果日誌裡出現某個節點解析失敗,通常是協議類型太新或太舊導致的欄位不匹配,可以先跳過該節點排查其餘部分是否正常。
補充新增欄位
按需加入
rule-providers、sniffer、tun等 mihomo 特有欄位,充分利用新內核能力,而不是止步於「能跑起來」的最低標準。核對策略群組測速邏輯
mihomo 的
url-test和fallback策略群組在逾時判定和健康檢查上做了優化,建議核對interval和tolerance參數是否仍符合預期。
唯一需要重寫而非直接遷移的場景,是設定檔裡用到了原版從未支援、而是第三方魔改分支自訂的私有欄位,這類情況較為少見,遇到時以 mihomo 官方文件欄位說明為準逐條核對即可。
該如何選擇:內核層面的實際建議
把上述差異歸納成一句話:原版內核已經封存,功能停留在停更前的水準,不會再有新協議和新規則能力;mihomo 是目前活躍維護、協議與規則能力持續擴展的內核,且對原版設定保持相容。因此從內核選擇角度,沒有必要為了「用回原版」而放棄新特性,直接選擇底層基於 mihomo 的客戶端是更省心的路徑。
具體判斷上,可以按以下幾點快速核對目前使用的客戶端內核情況:
- 查看客戶端「關於」或「版本資訊」頁面,通常會標註內核名稱與版本號,標註 mihomo 或 Meta 字樣即為新內核。
- 嘗試加入 Hysteria2 或 TUIC 節點,若能正常識別並顯示延遲,說明內核支援新協議。
- 查看是否有
rule-providers或規則集自動更新的設定項,這是判斷規則系統是否為 mihomo 體系的直接依據。
對多數使用者來說,內核差異不需要手動介入,只需要在選擇客戶端時確認其底層依賴的是持續更新的 mihomo,後續協議和規則的演進都會隨客戶端更新自動落地,不必單獨關注內核本身的升級節奏。