Clash 原版、Meta 與 mihomo 核心差異對比：協議支援與選擇建議
三種核心名稱相近但能力差距明顯。本文從協議支援、規則語法、TUN 實現與維護狀態四個維度逐項對比，並給出不同用戶端與使用情境下的核心選擇結論。
下載用戶端時經常會在設定裡看到「核心版本」或「核心類型」這一項，選項通常是 Clash Premium、Clash Meta、mihomo 三者之一，偶爾還能見到停止更新的原版 Clash。這幾個名字看起來只是版本號的差異，實際背後是完全不同的程式碼分支，功能集合、協議支援範圍、更新頻率都不一樣。選錯核心最直接的後果是某條規則語法解析失敗、某個協議節點連不上，或者 TUN 模式啟動後系統流量沒有被正確接管。這篇文章把四條主線捋清楚，幫助判斷目前用戶端用的是哪一種核心，以及要不要手動切換。
核心譜系：一個專案分出的三條分支
要理解差異，先要理清歷史脈絡。最早的 Clash 由 Dreamacro 用 Go 語言編寫，長期是事實標準，規則引擎簡潔、資源占用低，但作者在 2023 年停止了公開維護，倉庫封存後不再合併新協議的支援。這就是通常說的「原版 Clash」或 Clash Premium（早期曾有付費核心 Premium 分支，提供規則測速等增強功能，但底層協議集合與開源版基本一致）。
原版停更後，社群在其基礎上發起了 Clash.Meta 分支，加入了原版一直缺席的協議與功能，例如 TUN 模式的完整實現、Hysteria、TUIC、WireGuard 出站等。這個分支後來正式改名為 mihomo，目前是社群維護最活躍、更新最頻繁的核心，多數主流用戶端（Clash Verge Rev、FlClash、Clash Meta for Android 等）預設內建的都是 mihomo，只是用戶端介面上仍習慣稱呼為「Meta 核心」，容易讓人以為 Meta 和 mihomo 是兩個不同的東西——實際上 mihomo 就是 Clash.Meta 改名後的延續版本，二者是同一條分支的不同階段。
提示：如果用戶端設定頁寫的是「Meta 核心」而版本號形如 v1.18.x 或更高，基本可以確認實際執行的就是 mihomo，只是命名沿用了舊稱。
協議支援對比：差距集中在新協議
三者在 Shadowsocks、VMess、Trojan 這幾個「老三樣」協議上沒有實質差異，都能正常解析和連線。差距主要體現在近幾年新出現的協議和傳輸方式上：
| 協議/特性 | 原版 Clash | Clash Meta | mihomo |
|---|---|---|---|
| Shadowsocks / VMess / Trojan | 支援 | 支援 | 支援 |
| Hysteria / Hysteria2 | 不支援 | 支援 | 支援 |
| TUIC | 不支援 | 支援 | 支援（含 v5） |
| WireGuard 出站 | 不支援 | 部分支援 | 支援 |
| VLESS + XTLS/Vision | 不支援 | 部分版本支援 | 支援 |
| ShadowTLS | 不支援 | 支援 | 支援 |
| TUN 完整接管 | 受限 | 支援 | 支援並持續優化 |
可以看出，凡是 2021 年之後出現的協議，原版 Clash 基本一律不支援，這也是它逐漸被淘汰的直接原因。Clash Meta 作為過渡階段的分支覆蓋了大部分新協議，但部分實現停留在早期版本，遇到協議規範更新（比如 TUIC 從 v4 升級到 v5）時可能滯後。mihomo 作為目前活躍分支，新協議的跟進速度最快，通常協議標準發布後一到兩個小版本內就會合併支援。
訂閱節點解析失敗的常見原因
如果訂閱裡出現 Hysteria2 或 TUIC 節點，匯入後顯示「未知協議」或直接被過濾掉，多半是用戶端內建的還是原版 Clash 核心。此時不需要重新下載用戶端，檢查一下設定裡是否有「核心切換」選項，切到 Meta 或 mihomo 核心後重新匯入訂閱通常就能解決。
規則語法差異：Meta 系新增的匹配類型
規則集（Rule Provider）與規則語法上，mihomo/Meta 相對原版新增了幾類原版不認識的匹配規則，直接寫進原版核心的設定檔會導致啟動失敗或規則被靜默忽略：
- RULE-SET：引用外部規則集檔案，原版早期版本不支援增量更新的規則集格式。
- GEOSITE / GEOIP（配合 mmdb/dat 資料庫）：按網域或 IP 歸屬地打包分類，原版對新格式資料庫的相容性較差。
- SCRIPT：允許用簡單腳本邏輯做分流判斷，僅 Meta/mihomo 支援。
- SUB-RULE：子規則集巢狀引用，mihomo 後期版本才加入，用於精簡大型規則檔案。
- process-name / process-path 行程級匹配：按發起請求的應用行程分流，依賴 TUN 模式取得行程資訊，原版不具備這類能力。
rules:
- RULE-SET,private,DIRECT
- RULE-SET,reject,REJECT
- GEOSITE,cn,DIRECT
- GEOIP,CN,DIRECT
- MATCH,PROXY上面這段常見的規則片段裡，RULE-SET 和 GEOSITE 都要求核心具備對應解析能力。如果把這類設定檔塞進只支援原版語法的用戶端，日誌裡通常會報「unsupported rule type」或者規則整體不生效，退回到預設策略組，表現就是明明設定了分流規則，但所有流量還是走了同一條路徑。
TUN 模式實現：接管完整度決定使用體驗
TUN 模式指的是核心在系統層建立一個虛擬網卡，把裝置上所有應用的流量都強制導入代理處理流程，不再依賴單個應用主動設定代理位址。這也是三種核心差距最直觀的地方：
- 原版 Clash：TUN 支援在專案後期才補上，實現比較基礎，對 IPv6、DNS 劫持的處理不完整，實際使用中經常出現部分應用繞過代理的情況。
- Clash Meta：重寫了 TUN 實現，支援自動路由表設定、DNS 劫持、行程級過濾，覆蓋了 UWP 應用、系統服務等原版處理不了的流量類型。
- mihomo：在 Meta 的基礎上持續打磨，對 Android 平台的 VpnService 整合、iOS 平台的 NetworkExtension 適配都做了針對性優化，同時修復了大量因系統版本升級引發的 TUN 相容性問題。
對安卓使用者來說，這一點尤其關鍵：Clash for Android 系用戶端能不能穩定接管全域流量、能不能正確處理 DNS 請求走向，核心取決於內建的是不是 mihomo 核心。如果發現某些應用（尤其是有網路隔離機制的系統級應用）始終繞過代理，先確認用戶端核心版本，再排查具體應用的網路設定。
維護狀態與更新頻率：決定長期可用性
協議和語法層面的靜態對比只能反映當下的狀態，實際選擇時更該關注的是維護活躍度——代理協議本身在持續演進，核心如果停止更新，用不了多久就會跟不上伺服器端的協議版本。
| 維度 | 原版 Clash | Clash Meta | mihomo |
|---|---|---|---|
| 倉庫狀態 | 已封存，不再更新 | 已併入 mihomo，獨立分支停止推進 | 活躍維護 |
| 版本發布節奏 | 無 | 歷史遺留 | 數週一個小版本 |
| 安全修復 | 不再提供 | 不再提供 | 持續跟進 |
| 新協議合併速度 | 不適用 | 不適用 | 較快 |
簡單說，Clash Meta 這個名字目前更多是歷史遺留的稱呼，實際程式碼演進已經全部轉移到 mihomo 倉庫，繼續維護「Clash Meta」這個分支名稱的用戶端，本質上用的也是 mihomo 編譯產物，只是命名沒有及時更新。真正意義上還在使用原版 Clash 核心、且從未升級過的用戶端已經比較少見，一旦遇到，規則語法和協議支援都會明顯落後。
不同情境下的核心選擇建議
結合上面四個維度，給出幾種典型情境的判斷依據：
- 日常使用、訂閱節點較新：優先選擇內建 mihomo 核心的用戶端，新協議相容性和 TUN 穩定性都更有保障，遇到問題社群也能更快得到修復。
- 依賴複雜分流規則、大型規則集：確認用戶端支援 RULE-SET 與 SUB-RULE 語法，這類情境基本排除原版核心。
- 純靜態設定、長期不換節點：如果訂閱只用 Shadowsocks/VMess 這類基礎協議，且不需要 TUN 全域接管，即使用戶端仍標註為「Meta 核心」也通常夠用，不必頻繁折騰切換。
- 安卓裝置上需要全域代理與分應用規則：務必確認用戶端 TUN 實現基於 mihomo，否則行程級分流和部分系統應用的流量接管會不完整。
判斷目前用戶端具體使用哪種核心，最直接的方式是查看設定頁的「關於」或「核心資訊」欄目，通常會顯示類似 mihomo v1.18.x 這樣的版本字串；如果只寫著一個不帶來源說明的版本號，也可以在設定檔裡加入一條新語法規則（例如 RULE-SET）測試是否報錯，作為間接驗證手段。
注意：切換核心後原有設定檔建議重新校驗一遍，部分策略組寫法（如出站分組的 type 欄位取值）在不同核心間存在細微差異，直接複用舊設定有小機率觸發解析報錯。
排查核心問題的簡明步驟
遇到「規則不生效」「協議連不上」「TUN 開啟後部分應用無法存取網路」這類問題時，可以按下面順序排查，通常幾分鐘就能定位是不是核心不匹配導致的：
- 查看用戶端日誌，搜尋是否出現 unsupported、unknown rule type、protocol not supported 一類關鍵字。
- 在設定裡確認目前核心版本號與來源，判斷是不是原版 Clash 或過舊的 Meta 分支。
- 若用戶端提供核心切換選項，切換到 mihomo 分支後重新載入設定檔。
- 規則和協議仍有問題，檢查設定檔裡對應欄位的寫法是否和目前核心版本的文件一致，尤其注意規則集格式（YAML/文字）與欄位命名的變化。
總體而言，三種核心並非平級的可選項，而是一條技術演進鏈條：原版 Clash 是起點但已經停止前進，Clash Meta 是中間過渡階段，mihomo 是目前的延續與終點。除非有明確的相容性理由（例如某些老舊設定檔嚴格依賴原版行為），日常使用沒有必要堅持舊核心，選擇內建 mihomo 的用戶端能省去大部分因協議或語法不相容引發的排查工作。