三個名字,一條主線:Clash 核心的演進時間軸
第一次接觸 Clash 生態,最容易卡住的不是設定,而是名字:教學裡寫 Clash,下載頁寫 Clash Meta,新版用戶端的介面裡又冒出 mihomo。這三者不是三個彼此競爭的專案,而是同一個核心在不同階段的稱呼。先把時間軸摸清楚,後面怎麼選就順理成章了。
| 時期 | 名稱 | 維護方 | 狀態 |
|---|---|---|---|
| 2018 – 2023 | Clash(原版) | Dreamacro | 已停止維護 |
| 2022 – 2024 | Clash Meta | MetaCubeX 團隊 | 已改名 |
| 2024 年至今 | mihomo | MetaCubeX 團隊 | 持續維護中 |
一句話記法:原版 Clash 是共同的前身,Clash Meta 是接棒者,mihomo 是 Meta 的新名字。現在新安裝的用戶端,內建核心幾乎都是 mihomo。
原版 Clash:規則代理的奠基者,已停止維護
原版 Clash 由 Dreamacro 以 Go 語言撰寫,2018 年發布。它確立了沿用至今的運作模式:用一份 YAML 設定檔描述節點、策略群組與分流規則,進站流量依規則被送往直連、代理或拒絕。混合埠、外部控制器 API、依網域與 IP 分流,這些設計都是原版打下的基礎。
原版分兩條線:開源核心,以及閉源的 Clash Premium。Premium 獨佔 TUN 模式與腳本能力,Clash for Windows、ClashX 等早期用戶端內建的正是它。
2023 年 11 月,作者將倉庫封存並清空發布頁,原版正式停止維護。這意味著:新協定不會再加入,既有實作的缺陷不會修復,建立在其上的用戶端也陸續停更。現在再安裝一個原版核心的用戶端,多數情境仍能跑,但協定支援停留在 2023 年,之後不會再有變化。
Clash Meta:接棒的增強分支
在原版停更之前,MetaCubeX 團隊已基於原版 fork 出 Clash Meta 持續開發;原版停更後,Meta 順勢成為實質上的主線。相對原版,它的關鍵增量集中在四個方面:
- 協定面:新增 VLESS(含 XTLS Vision、Reality)、Hysteria 與 Hysteria2、TUIC、WireGuard、ShadowTLS、AnyTLS,原版之後出現的主流協定基本都涵蓋。
- TUN 模式:內建且免費開放,不再依賴閉源 Premium,可接管系統全域流量。
- 規則面:
rule-providers與proxy-providers向所有用戶開放,支援網域嗅探(sniffer)與 GEOSITE 規則集。 - 體驗面:
unified-delay統一測速口徑,tcp-concurrent併發建連,find-process-mode依處理程序分流。
設定層面,Meta 大體上是原版的超集:為原版寫的設定大多可以直接執行;反過來,帶 Meta 專屬欄位的設定拿到原版核心上,啟動就會報錯。
mihomo:Clash Meta 的現行名稱
2024 年,Clash Meta 改名為 mihomo,倉庫遷移至 MetaCubeX/mihomo,版本號沿舊有路線持續遞增。改名不改代碼:同一批維護者、同一份設定語法、同一套發布節奏,文件站 wiki.metacubex.one 同時涵蓋新舊兩個名字。
實際使用中會遇到名稱混用的情況:舊版本日誌印出 Clash Meta,新版本印出 Mihomo;有些用戶端介面寫 Meta 核心,有些寫 mihomo 核心——指的都是同一個程式。看到 mihomo v1.18、v1.19 這類版本號,就能確認是這條線的現行版本。
用戶端與核心對照表
用戶端是外殼,核心才是實際處理流量的程序。常見用戶端的內建核心如下:
| 用戶端 | 內建核心 | 維護狀態 |
|---|---|---|
| Clash Verge Rev | mihomo(原 Clash Meta) | 持續維護中 |
| FlClash | mihomo | 持續維護中 |
| mihomo party | mihomo | 持續維護中 |
| Clash for Windows | Clash Premium(原版) | 已停更 |
| ClashX 系列 | 原版或 Meta | 已停更 |
| Clash Meta for Android | Clash Meta | 已停更 |
判斷一個用戶端值不值得安裝,先看核心:基於 mihomo 的用戶端能跟上協定演進;基於原版核心的用戶端,功能停留在停更那一刻。詳細的用戶端橫向比較請見本站用戶端比較頁。
確認目前執行的核心版本
以 Clash Verge Rev 為例,有三種方式可查:
- 設定頁:「設定」裡的「Clash 核心」區塊會顯示目前核心類型與版本號,並可在正式版與 Alpha 通道之間切換。
- 日誌頁:核心啟動時會把名稱與版本寫進日誌第一行,把日誌等級調到 Info 即可看到。
- 外部控制器:核心執行期間,直接查詢版本介面即可。
$ curl http://127.0.0.1:9097/version
{"premium":true,"version":"Mihomo Meta v1.18.7"}9097 是 Clash Verge Rev 的預設外部控制器埠;若在設定裡改過埠號,以實際值為準。回傳的 version 欄位以 Mihomo 開頭,就代表跑在 mihomo 這條線上。
換核心前的設定相容性檢查
手上有一份舊設定、打算從原版核心遷到 mihomo,依三個方向核對即可:
- 原版欄位在 mihomo 上幾乎全部相容:
port、mixed-port、proxies、proxy-groups、rules原樣可用。 - mihomo 專屬欄位不要寫進要給原版用的設定:
unified-delay、tcp-concurrent、sniffer、tun設定區塊、geodata-mode等,原版解析到未知欄位會直接退出。 - 規則集寫法以 mihomo 文件為準:
RULE-SET、GEOSITE依賴 rule-providers 與 geodata,原版開源核心不支援。
訂閱與核心要配對
目前訂閱服務大多依 mihomo 語法下發。把訂閱交給原版核心的用戶端使用,常見結果是啟動報錯或節點全部失效。新安裝用戶端,直接選 mihomo 核心即可。欄位細節可對照本站設定參考頁逐項核對。
遷移時的常見疑問速答
第一問:舊設定要不要重寫?多數情況不用。mihomo 對原版欄位向下相容,直接匯入即可運作;真正需要動手的只有一種情境——你想用上 sniffer 網域嗅探、tun 虛擬網卡這類新能力,才需要在設定裡補上對應欄位。第二問:換核心會不會影響訂閱?不會,訂閱連結本身與核心無關,拉取下來的 YAML 由用戶端交給核心解析,只要核心認得欄位就能跑。第三問:延遲測速結果為什麼和以前不一樣?mihomo 預設啟用統一延遲(unified-delay),把握手耗時從測速中剔除,數值普遍比原版核心測出來的低,這是統計口徑變化,不代表節點變快,橫向比較節點優劣時不受影響。第四問:用戶端介面上沒寫核心版本怎麼辦?按上文的 curl 方法查外部控制器介面即可,任何 Clash 系用戶端都適用。把這四個問題弄清楚,遷移基本不會踩坑。
總結一句話:原版 Clash 是歷史,Clash Meta 是曾用名,mihomo 是現在進行式。選用戶端就認 mihomo 核心,設定寫法、協定支援、文件範例都以它為準。