Clash 原版、Meta 與 mihomo 內核差異對照:功能差異與選擇依據
梳理三代內核的來龍去脈:原版停更後的現狀、Meta 分支的擴充協議支援、mihomo 的更名與延續,依協議相容性與維護狀態,提供目前該選哪個內核的判斷依據。
內核譜系:從 Clash 原版到 mihomo 的演進脈絡
市面上能查到的「Clash」其實指向三條不同的程式碼線,理解它們的先後關係是判斷該用哪一個的前提。最早的 Clash 由原作者以 Go 語言撰寫,發布方式是命令列內核加第三方圖形介面,長期是各平台客戶端的預設底層。這一版本通常被稱作「原版」或「Clash Premium/Core」,它奠定了規則分流、代理群組、訂閱連結這套現在已成為業界預設的互動模型。
2023 年前後,原作者的相關儲存庫從程式碼託管平台被整體移除,原版內核停止了公開的原始碼更新與版本發布。此後能下載到的原版執行檔,基本都是社群在停更前保存的歷史版本,或第三方鏡像倉庫的存檔,不再有新的協議支援或問題修復進入這條程式碼線。
在原版仍活躍的階段,已經有開發者基於其程式碼拉出分支進行擴充,這個分支當時命名為 Clash Meta,重點補齊了原版沒有跟上的新協議與 TUN 模式細節。原版停更之後,大量圖形客戶端把預設內核切換到了 Meta 分支,這也是「Meta 內核」這個說法在教學和論壇裡高頻出現的原因。Meta 分支後續經歷了一次正式更名,專案繼續以 mihomo 的名字維護,程式碼脈絡和發布節奏是連續的,並非另起爐灶。也就是說,目前看到的「mihomo」,在功能定位上就是升級換代後的 Meta,兩者不是並列關係,而是同一條線的新舊稱呼。
三代內核功能與協議支援對照
三條程式碼線在協議涵蓋範圍、運作模式和設定語法上都存在差異,下表列出實際使用中影響最大的幾項。
| 能力項目 | 原版(停更快照) | Meta / mihomo |
|---|---|---|
| 基礎協議(Shadowsocks、VMess、Trojan) | 支援 | 支援 |
| VLESS | 不支援 | 支援 |
| Hysteria / Hysteria2 | 不支援 | 支援 |
| TUIC | 不支援 | 支援 |
| ShadowTLS / WireGuard 出站 | 不支援 | 支援 |
| TUN 模式(系統層接管流量) | 早期實驗性,問題較多 | 作為穩定功能長期維護 |
| 規則提供者遠端更新語法 | 基礎版本 | 擴充欄位更豐富,支援行為策略細分 |
| 設定覆寫 / 腳本策略 | 不支援 | 支援 |
可以看到,分歧的核心不是「誰更快」或者「誰介面好看」,而是協議清單和運作模式的代差。原版停更時新一代加密協議還沒有普及,自然不會寫進當年的程式碼。Meta 分支和後續的 mihomo 出現的價值,正是把這些新協議和更精細的流量控制能力補上,並持續跟進上游代理軟體生態的變化。
維護狀態與更新頻率:能不能用得放心
選內核不只是看功能清單,更要看這條程式碼線現在是否還有人在改。三者的維護狀態差異很直接。
- 原版:儲存庫已不再更新,現存的執行檔是歷史存檔。不會有新的協議支援,也不會再收到針對已知問題的修復。如果某個訂閱商換用了原版不認識的新協議,原版會直接連線失敗,沒有升級路徑。
- Meta(歷史名稱):作為一個過渡階段的名字,目前已不再是活躍發布管道,相關標籤和說明在新版本中已併入 mihomo 專案下,單獨尋找「Clash Meta」最新版本通常會被引導到 mihomo。
- mihomo:是目前實際持續發布的程式碼線,版本號按常規節奏迭代,新協議、新平台適配、問題修復都在這裡落地。絕大多數還在活躍維護的圖形客戶端,底層內核都已指向 mihomo,只是客戶端介面上可能仍沿用「Meta 內核」這個歷史說法。
判斷一個客戶端到底用的是哪條內核線,不要只看介面文案,以實際內核版本號或啟動日誌裡的專案標識為準。部分教學和下載頁仍沿用舊稱呼,容易造成「到底是不是同一個東西」的困惑。
依情境給出的選型建議
結合協議相容性和維護狀態,提供幾條可以直接照做的判斷依據。
-
訂閱只使用基礎協議,且不需要 TUN 模式
如果上游節點全部是 Shadowsocks、VMess 或 Trojan,不涉及新協議,也不打算用系統層接管流量,理論上原版存檔仍能連通。但要清楚這是在用一個不會再修復問題的歷史版本,長期看存在協議淘汰或客戶端適配脫節的風險,不建議作為長期方案。
-
訂閱包含 VLESS、Hysteria2、TUIC 等新協議
這類協議原版完全不認識,連線會直接失敗。必須選擇基於 mihomo 內核的客戶端,沒有繞過空間。
-
需要 TUN 模式接管全域流量或做行程層級分流
TUN 模式在 mihomo 上作為長期維護的穩定功能存在,設定欄位和行為都更完整。原版的相關實作停留在早期階段,不建議依賴其做精細分流。
-
不確定該選哪個,追求少踩坑
直接選用目前主流圖形客戶端預設整合的 mihomo 內核。它涵蓋的協議範圍最廣,更新節奏穩定,遇到問題有持續修復的可能,不需要額外判斷內核來源是否已經停更。
從原版設定遷移到 mihomo 的注意事項
如果手上的設定檔是早年基於原版規則寫的,遷移到 mihomo 內核基本可以直接複用,但有幾個欄位差異值得核對一遍,避免規則群組行為跟預期不一致。
- proxy-groups 裡的分組類型在 mihomo 上擴充了更多策略選項,原版沒有的欄位會被忽略,不會導致設定報錯,但也不會生效,建議逐條確認。
- rule-providers 的行為欄位在新內核上更細,原有的簡單規則集依然可以正常載入。
- 涉及新協議節點的條目,原版設定檔裡通常不會出現,遷移後可以按需補充,不影響已有的其他節點。
一個簡單的自我檢查方式是先用新內核載入舊設定,觀察啟動日誌是否有未識別欄位的提示,再逐條比對官方文件裡的欄位說明,確認沒有遺漏關鍵策略。
mihomo -d ./config -f ./config.yaml命令列方式啟動時,日誌會直接印出內核版本、載入的規則數量以及是否有解析失敗的條目,這是核對內核版本和設定相容性最直接的手段,比只看客戶端介面上的名稱更可靠。
結論:當下該怎麼選
把上面的資訊壓縮成一句可執行的結論:原版內核已經停止維護,只適合明確知道自己在用舊版本、且訂閱協議範圍極其有限的場景;Meta 這個名字目前已併入 mihomo,單獨尋找已經沒有意義;新裝客戶端或更換內核時,優先確認底層是否為 mihomo,這是協議涵蓋最全、維護最活躍的選擇,也是目前各平台圖形客戶端的主流預設配置。