mihomo(Clash Meta)核心特性與原版 Clash 的差異
mihomo 核心比原版 Clash 多了哪些能力:新協定支援、規則增強、效能差異與遷移時的注意事項。一篇講清兩個核心的關係與取捨。
兩個核心是什麼關係
原版 Clash 由 Dreamacro 用 Go 語言撰寫,以 GPL-3.0 授權開源。2023 年 11 月,作者將倉庫封存並刪除,專案停止維護,版本號永遠停在 v1.18.0。開源版提供 HTTP 與 SOCKS 入站、Shadowsocks / ShadowsocksR / VMess / Trojan / Snell 出站,以及一套基礎分流規則;TUN 模式和腳本規則只出現在閉源的 Premium 版裡,並未隨開源版釋出。
mihomo 是社群在原版原始碼上延續開發的分支,一開始叫 Clash.Meta,2023 年底改名為 mihomo,由 MetaCubeX 組織維護,同樣以 GPL-3.0 開源,持續迭代更新。兩者的關係可以用一句話概括:原版是停更的基線,mihomo 是接棒延續的版本。
落到用戶端上來看:本站下載頁收錄的 Clash Verge Rev、Clash Nyanpasu、FlClash、ClashX Meta 等用戶端全都內建 mihomo;而 Clash for Windows 內建的是基於原版的閉源 Premium 核心,已隨用戶端一起停止更新。挑用戶端時,核心新舊才是比介面更關鍵的分水嶺。
協定支援:出站種類差了一代
原版開源 Clash 支援的出站協定清單在 2023 年之後就沒再變化:Shadowsocks、ShadowsocksR、VMess、Trojan、Snell、SOCKS5、HTTP。mihomo 在此基礎上補齊了近三年新出現的協定:
- VLESS,含 XTLS Vision 流控與 Reality 傳輸偽裝;
- Hysteria 與 Hysteria2,基於 QUIC 的壅塞控制協定;
- TUIC,QUIC 系的另一種實作;
- WireGuard,可直接對接標準 WireGuard 伺服端;
- SSH、AnyTLS 等較新的出站類型。
| 出站協定 | 原版 Clash | mihomo |
|---|---|---|
| Shadowsocks / ShadowsocksR | 支援 | 支援 |
| VMess | 支援 | 支援 |
| Trojan | 支援 | 支援 |
| Snell | 支援 | 支援 |
| VLESS(Reality / XTLS Vision) | 不支援 | 支援 |
| Hysteria / Hysteria2 | 不支援 | 支援 |
| TUIC | 不支援 | 支援 |
| WireGuard | 不支援 | 支援 |
實際影響很直接:訂閱裡出現帶 reality 參數的 vless:// 節點、或以 hysteria2:// 開頭的節點時,原版核心無法解析,這批節點會整批從清單裡消失;同一份訂閱匯入 mihomo 用戶端後則可以全部識別。現在新發布的機場訂閱多半按 mihomo 格式產生,這是換核心最常見的原因。
規則系統:從靜態清單到規則集
原版 Clash 的規則是寫在設定檔裡一條條的靜態項目,類型有 DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD、GEOIP、IP-CIDR、MATCH 等。想更新一份廣告過濾清單,只能整份替換設定檔。
mihomo 把規則系統擴充成了三層:
- RULE-SET 規則集:透過 rule-providers 引用遠端或本地的規則檔,behavior 分 domain、ipcidr、classical 三種,搭配 interval 欄位定時自動更新,不用再手動替換設定檔;
- GEOSITE 站點分類:開啟 geodata-mode 後,可用 GEOSITE 規則按站點分類庫比對,粒度比按國家劃分的 GEOIP 細得多;
- 邏輯規則與子規則:AND、OR、NOT 可以把多個條件組合成一條規則,SUB-RULES 讓命中某條件的流量進入第二套規則鏈再做一次分流。
一段典型的 mihomo 規則設定長這樣:
rule-providers:
adblock:
type: http
behavior: domain
url: "https://example.org/rules/adblock.yaml"
path: ./ruleset/adblock.yaml
interval: 86400
rules:
- RULE-SET,adblock,REJECT
- GEOSITE,category-ads-all,REJECT
- AND,((NETWORK,UDP),(DST-PORT,443)),REJECT
- MATCH,PROXY另外 mihomo 內建了 sniffer 嗅探器:對只帶目標 IP 的連線嗅探 TLS SNI 或 HTTP Host,把網域名稱還原出來後再走一次規則比對,解決應用程式直連 IP 繞過網域規則的老問題。原版核心沒有對應能力。
效能與資源占用
兩個核心同樣以 Go 撰寫,單連線轉發效能在同一量級,日常瀏覽網頁感受不到差別。差異體現在長期維護帶來的細節上:mihomo 提供 tcp-concurrent 並行撥號、unified-delay 統一延遲測試口徑,以及更細緻的記憶體回收調校,並持續修復新版 Windows 與 macOS 上的相容性問題。
代價是功能變多之後記憶體基線略高。尤其掛載多個 behavior 為 classical 的規則集時,占用會明顯上升;domain 與 ipcidr 行為的規則集內部做了索引優化,占用低得多。挑選規則集時優先用前兩種,是控制記憶體占用的有效做法。
原版核心自 2023 年起就沒有任何修復與更新。在新系統上遇到相容性問題完全沒有官方解法,唯一出路就是換用仍在維護的核心。TUN 模式也是同樣道理:原版開源程式碼裡根本沒有 TUN,mihomo 內建 TUN 並提供 system、gvisor、mixed 三種堆疊可選,這也是很多使用者遷移的直接動機。
遷移到 mihomo 要改哪裡
設定結構大致相容:port、mixed-port、proxies、proxy-groups、rules 的寫法兩邊一致,多數舊設定可以直接跑起來。需要動手改的有幾處:
- DNS 增強模式:新版 mihomo 移除了 redir-host,只保留 fake-ip,舊設定裡的 enhanced-mode: redir-host 要改成 fake-ip;
- 節點欄位:proxies 裡的 interface-name 與 routing-mark 已被移除,寫著不改會在啟動時跳出警告甚至被拒絕,直接刪掉即可;
- 地理資料庫:mihomo 預設使用自己的 geoip 資料檔,支援 geo-update-interval 自動更新;要用 GEOSITE 規則需另外開啟 geodata-mode;
- 用戶端私有欄位:Clash for Windows 設定裡的 cfw-* 欄位屬於用戶端私有,換用戶端時不需要帶過去。
訂閱方向是單向暢通的:新協定節點(VLESS Reality、Hysteria2)只會出現在 mihomo 格式的訂閱裡;而舊的 Clash 訂閱在 mihomo 上基本可以原樣使用。也就是說,換核心不會丟失現有訂閱,只會解鎖更多節點。
遷移前先備份
換核心或換用戶端之前,先備份舊的設定目錄,尤其是自己修改過的規則、覆寫設定與本地規則檔。新用戶端首次匯入後再逐項核對 DNS 與規則段落。
怎麼確認自己跑的是哪個核心
有三處可以查證:
- 用戶端介面:打開設定或關於頁面查看核心版本。停在 2023 年的 v1.18.0 是原版;版本號帶 Meta 或 mihomo 字樣、且日期持續更新的是 mihomo。
- 外部控制器:用瀏覽器開啟 http://127.0.0.1:9090/version,回傳的 JSON 裡 meta 欄位為 true 即為 mihomo,例如
{"version":"v1.19.0","meta":true}。 - 命令列:直接執行核心檔案加上 -v 參數,輸出以 Mihomo Meta 開頭的就是 mihomo。
結論:新裝機直接選內建 mihomo 的用戶端,本站下載頁收錄的現役用戶端都符合這一點。舊機器上的原版核心可以留著對照參考,但新協定、新規則語法、新系統相容性都只在 mihomo 這一側持續更新。