Clash 核心版本差異：原版、Meta 與 mihomo 功能相容性比較

一、原版 Clash、Clash.Meta 與 mihomo 的關係

Clash 並不等同於某個桌面視窗或行動應用程式。完整使用鏈路通常包含三層：負責網路處理的核心、提供操作介面的用戶端，以及由本機檔案或訂閱服務產生的 YAML 設定檔。核心會解析代理節點、規則與策略群組，並執行 DNS、系統代理或 TUN 接管；用戶端則負責啟動核心、更新訂閱、顯示日誌與切換策略。

原版 Clash 奠定了常見的設定結構，例如 proxies、proxy-groups、rules、proxy-providers 與 rule-providers。大量訂閱轉換工具至今仍以此結構為基礎。不過，原版專案已停止持續維護，因此不會繼續跟進新協定、作業系統網路變化與長期累積的問題修復。它能執行舊設定檔，不代表適合作為新環境的預設核心。

Clash.Meta 最初是在 Clash 設定體系上擴充功能的維護分支，加入更多代理協定、規則能力、DNS 選項與透明代理相關功能。此專案後來使用 mihomo 作為目前名稱。由此可見，「Meta 核心」與「mihomo 核心」通常不是兩個完全獨立、同時演進的現代核心：前者較常出現在歷史版本、用戶端相容性標籤與舊文件中，後者則是目前的維護名稱。

部分用戶端仍會顯示「Clash Meta」，但核心檔名、日誌啟動行或專案文件卻寫作 mihomo。這種命名差異本身不代表用戶端過時。判斷依據應是核心版本日期、發布來源、支援的設定欄位，以及更新是否正常，而不能只根據介面中的單一標籤下結論。

比較項目	原版 Clash	Clash.Meta	mihomo
專案定位	基礎設定體系的原始實作	擴充分支的歷史名稱	Meta 分支目前的維護名稱
維護狀態	停止持續維護	名稱仍廣泛用於舊版本與介面	持續發布與修復
適用情境	重現舊設定、相容性驗證	辨識歷史文件與舊用戶端	新安裝、現代協定、複雜分流
設定關係	提供基礎欄位	在基礎結構上擴充	延續擴充並持續調整

二、協定支援差異：先辨識訂閱節點類型

協定支援是選擇核心時最直接的判斷條件。原版 Clash 可處理其維護期間已實作的常見代理類型，例如 Shadowsocks、SOCKS、HTTP、VMess 與 Trojan 等，但無法涵蓋後來加入 Meta 系列的所有協定與擴充參數。若訂閱包含 VLESS、Reality、Hysteria2、TUIC 或較新的 WireGuard 用法，通常需要使用近期版本的 mihomo 核心，並同時確認目前版本是否支援節點提供者指定的欄位。

即使只看到相同的協定名稱，也不能保證相容。例如 Shadowsocks 還涉及加密方式；VMess 與 VLESS 可能搭配 WebSocket、gRPC、TLS、Reality 等傳輸參數；Hysteria2 與 TUIC 也會受到憑證、壅塞控制、連接埠範圍及 UDP 網路條件影響。核心必須同時認得節點類型，並能解析該節點使用的參數組合。

匯入訂閱後若節點直接消失、設定載入失敗或日誌出現欄位解析錯誤，應先查看原始設定中的 type、network、cipher、reality-opts 等欄位，再核對核心版本。不要先反覆切換系統代理，因為設定尚未成功載入時，系統代理狀態無法修復協定解析問題。

依協定需求選擇核心

只有傳統節點與基礎規則：舊核心可能仍可執行，但新裝置沒有必要主動選擇已停止維護的原版。
訂閱包含 VLESS 或 Reality：選擇較新的 mihomo，並確認用戶端確實呼叫該核心，而不只是支援匯入連結。
需要 Hysteria2、TUIC 等 UDP 相關協定：除了核心支援外，還應檢查本機網路、路由器與伺服器端的連接埠策略。
設定由訂閱轉換產生：轉換目標應符合 mihomo 或 Clash.Meta 格式，避免工具為原版 Clash 刪除擴充欄位。

三、規則、策略群組與 DNS 能力的差異

基礎規則寫法在這三個名稱所代表的核心體系中仍保有高度延續性。常見的 DOMAIN、DOMAIN-SUFFIX、IP-CIDR、GEOIP 與 MATCH 仍是設定骨架，select、url-test、fallback 與 load-balance 等策略群組也延續 Clash 的設計思路。因此，多數基礎訂閱都能從原版結構遷移至 mihomo。

差異主要出現在擴充規則、規則集合格式、嗅探、DNS 分流與策略群組附加參數。mihomo 支援更豐富的規則表達方式，可結合規則集合、程序資訊、網路類型與邏輯條件來組織分流。具體欄位會隨版本演進，使用複雜規則時應依照對應版本的文件，而不是直接複製多年前的範例到目前設定中。

DNS 方面，原版 Clash 已具備 fake-ip 等基礎能力；mihomo 則在網域名稱解析策略、指定 DNS 伺服器、規則聯動與 Fake IP 排除等方面提供更多控制選項。設定越複雜，就越需要明確 DNS 請求由誰處理、網域名稱何時解析，以及規則比對使用網域名稱還是目標 IP。否則可能出現節點本身可以連線，但特定網站解析異常、區域網路網域失效或應用程式繞過預期策略等問題。

proxy-groups:
  - name: 自動選擇
    type: url-test
    use:
      - provider-main
    url: https://www.gstatic.com/generate_204
    interval: 300

rules:
  - DOMAIN-SUFFIX,example.com,自動選擇
  - GEOIP,CN,DIRECT
  - MATCH,自動選擇

上例使用的是常見基礎結構，但仍取決於名為 provider-main 的代理集合已在 proxy-providers 中定義。測速網址、間隔與策略名稱也應依實際網路調整。若從舊設定遷移，先保留簡單規則驗證連線，再逐步加入規則集合、DNS 策略與邏輯條件，比一次載入完整複雜設定更容易定位問題。

規則遷移時需要核對的項目

檢查每個規則目標是否對應到已存在的策略群組或代理節點。
確認遠端規則集合的格式、類型與下載網址符合目前核心的要求。
查看策略群組引用的代理集合是否成功更新，避免群組內實際沒有可用節點。
將 MATCH 保留在規則清單末尾，接手未被前置規則比對的連線。
修改 DNS 模式後清除必要的系統 DNS 快取，再分別測試網域名稱與 IP 存取。

四、設定檔相容性：基礎相容不等於雙向相容

mihomo 延續了大量原版 Clash 欄位，因此從原版設定遷移至 mihomo 通常相當順利；反向則不能如此推論。只要設定使用新協定、擴充規則、增強 DNS 欄位或新版 TUN 參數，原版核心就可能拒絕載入，或忽略無法辨識的部分。所謂「相容 Clash 設定」，通常只表示相容基礎結構，並不代表任意版本都能無差別讀取同一份檔案。

還要區分核心設定與用戶端設定。YAML 中的代理連接埠、規則與 DNS 通常由核心讀取；開機啟動、系統匣行為、訂閱更新週期、介面主題與系統服務權限則屬於用戶端設定。將某個用戶端的整個設定目錄複製到另一個用戶端，可能同時帶入路徑、資料庫與服務狀態問題。遷移時較穩妥的方式是重新匯入訂閱，或只遷移經過檢查的核心 YAML。

某些用戶端會在訂閱檔案外再產生一層覆寫設定，用來插入 TUN、DNS、控制連接埠或本機規則。使用者在介面中看到的設定，可能與最終送入核心的設定不同。排查相容性問題時，應尋找用戶端提供的「執行設定」、「合併後設定」或核心日誌，而不是只查看訂閱原文。

從舊核心遷移至 mihomo 的順序

記錄目前可用的用戶端、核心版本、監聽連接埠與系統代理狀態。
匯出必要的本機規則與策略群組設計，不要直接複製用戶端的執行目錄。
在新用戶端中匯入原始訂閱，先關閉自訂覆寫並驗證節點連線。
逐項恢復規則、DNS 與 TUN 設定，每次修改後檢查啟動日誌。
分別測試瀏覽器、命令列程式、商店應用程式與需要 UDP 的應用程式，確認接管範圍符合預期。

五、TUN 模式與作業系統接管範圍

系統代理主要影響遵循作業系統代理設定的應用程式，通常適合瀏覽器與一般桌面軟體。部分遊戲、命令列工具、商店應用程式或自行建立網路堆疊的程式，可能不會讀取系統代理。TUN 模式透過虛擬網路介面處理更廣泛的流量，因此經常用於需要統一接管 TCP 與 UDP 的情境。

mihomo 對 TUN、DNS 劫持、路由自動設定與流量嗅探提供了較完整的現代實作，但最終效果仍取決於用戶端如何申請權限、安裝服務與設定系統路由。Windows 上可能需要服務模式或系統管理員權限；macOS 會要求網路延伸功能相關授權；Linux 則涉及裝置權限、路由表與防火牆。行動端用戶端通常透過系統 VPN 介面執行，背景限制也可能影響連線持續性。

TUN 模式並非啟用後就一定更快。它擴大的是接管範圍，也增加 DNS、路由與迴路處理的複雜度。若瀏覽器使用系統代理已能滿足需求，維持簡單設定通常更容易維護；若遊戲 UDP、終端程式或特定應用程式無法通過系統代理，再啟用 TUN 並逐項檢查會更合適。

從原版核心遷移時，不應直接照抄舊版 TUN 範例。不同版本的網路堆疊選項、自動路由欄位與 DNS 搭配方式可能有所變化。若用戶端已提供 TUN 開關，應優先使用用戶端產生的設定，再根據日誌補充排除網段、區域網路存取或 DNS 策略。

需求	建議模式	重點檢查
瀏覽器與一般辦公軟體	系統代理	代理連接埠、規則命中、瀏覽器本身的代理設定
命令列與不讀取系統代理的程式	TUN 或個別設定環境變數	路由、DNS、權限與區域網路存取
遊戲及 UDP 應用程式	依應用程式選擇 TUN	節點 UDP 能力、協定支援、網路封包遺失
僅排查訂閱是否可用	先使用系統代理	減少變數，先確認設定成功載入

六、資源占用與效能：以實際設定測量

不能簡單將「功能更多」等同於「資源占用一定更高」。核心負載通常由並行連線數、規則數量、規則集合大小、日誌層級、DNS 快取、協定加密方式、TUN 流量與用戶端介面共同決定。同一台裝置上，精簡的 mihomo 設定可能比載入大量規則並持續輸出除錯日誌的舊設定更穩定。

桌面用戶端顯示的記憶體占用還包含圖形介面、WebView、訂閱資料庫與更新服務，不應全部歸因於核心。若要比較核心，應在相同節點、相同規則、相同接管模式與相近流量下觀察獨立核心程序。測速時同時記錄啟動後閒置狀態、持續下載、連線數增加及規則更新後的變化，才具備參考價值。

行動裝置更應關注持續喚醒、弱網重新連線與背景執行時間。過短的策略群組測速間隔會週期性存取測試網址；大量自動更新的代理集合與規則集合也會增加網路活動。合理延長健康檢查與更新週期、關閉長時間除錯日誌、刪除不使用的規則集合，通常比退回舊核心更有效。

常見效能最佳化順序

先將日誌層級恢復為日常使用所需的程度，只在排錯期間啟用詳細日誌。
減少重複規則與不使用的遠端規則集合，避免每次更新都處理多份相同資料。
適度延長 url-test、代理集合健康檢查與訂閱更新間隔。
確認異常占用來自核心程序還是用戶端介面，再決定升級、重設或更換用戶端。
在 TUN 與系統代理之間進行對照測試，判斷問題是否與接管範圍有關。

七、情境化選型建議

新使用者或新裝置：選擇內建近期 mihomo 核心、能顯示核心版本並提供設定日誌的用戶端。這樣可以涵蓋現代訂閱常見的協定與規則格式，也方便後續更新。用戶端名稱是否包含 Clash 並非核心條件，實際核心與維護狀態更重要。

仍在使用原版 Clash 的舊環境：如果目前設定穩定且業務需求不變，可以先記錄執行環境，再規劃遷移，不必在工作期間倉促替換。但只要需要新協定、新作業系統適配，或需要安全性與穩定性修復，就應轉向仍在維護的 mihomo。遷移前應重點檢查策略群組名稱、DNS、規則集合與 TUN 欄位。

看到 Clash.Meta 下載項目：先查看發布日期與核心日誌。較新的用戶端可能為了方便使用者辨識而繼續使用 Meta 名稱，實際執行的卻是 mihomo；長期未更新的安裝包則可能包含舊版 Meta 核心。同名不代表維護狀態相同。

只使用基礎訂閱與系統代理：mihomo 依然適合。選擇新核心不代表必須啟用所有進階功能，可以繼續使用簡單的節點、策略群組與規則。維持清楚的設定邊界，比為了使用新功能而堆疊不理解的選項更可靠。

需要複雜分流、現代協定或 TUN：優先使用近期 mihomo，並選擇能正確管理系統服務、權限與設定覆寫的用戶端。遇到問題時，依照「設定是否載入、節點是否連線、規則是否命中、系統是否接管」的順序檢查，避免同時修改多個環節。