Clash 原版、Meta 與 mihomo 核心差異：功能範圍與用戶端選擇

判斷一個 Clash 用戶端是否適合目前環境，不能只看軟體名稱和介面截圖。實際負責接管連線、比對規則、處理 DNS 與解析代理協定的是核心。桌面用戶端通常只是提供設定、系統匣選單、系統代理開關與日誌檢視介面；核心版本才會決定能否辨識設定欄位、TUN 如何運作，以及新協定能否建立連線。

「Clash 原版」、「Clash.Meta」和「mihomo」經常被並列討論，但三者並不是持續同步開發、功能對等的三個產品。原版 Clash 是設定模型與規則體系的重要來源；Clash.Meta 是後續擴充分支曾使用的名稱；mihomo 則是該擴充分支更名後目前使用的專案名稱。許多用戶端、設定檔目錄和訂閱轉換範本仍保留 Meta 字樣，因此介面名稱與實際執行的核心可能不一致。

專案關係：原版、Meta 與 mihomo 不是三條平行產品線

Clash 原版建立通用設定模型

通常所說的 Clash 原版，是指由 Dreamacro 維護的 Go 語言規則代理核心及其設定體系。它確立了代理節點、策略群組、規則、DNS、入站連接埠與外部控制器等核心概念。大量用戶端與訂閱服務沿用了這些欄位，因此即使目前執行的是其他相容核心，設定檔仍常被統稱為 Clash 設定。

原版開源專案目前已封存，不再處於持續功能迭代狀態。歷史上也存在功能範圍不同的 Premium 建置版本，部分舊文件會把開源版、Premium 版與圖形用戶端混在一起說明。閱讀舊教學時，需先確認它描述的是哪一種建置版本，尤其不要把舊版 Premium 的行為直接視為所有原版核心都具備的能力。

Clash.Meta 是擴充分支的舊名稱

Clash.Meta 沿用 Clash 的主要設定結構，並持續擴充代理協定、規則能力、DNS、TUN、流量嗅探與執行控制等功能。它的目標之一，是讓常見的 Clash 設定能以較低成本遷移，同時允許設定檔使用更多欄位。由於相容基礎較廣，許多桌面與行動裝置用戶端曾直接將「Meta」寫入產品名稱、核心切換選項或設定目錄。

mihomo 是 Meta 分支更名後目前使用的名稱

mihomo 並不是在 Clash.Meta 之外重新出現的另一套平行核心。更準確地說，Clash.Meta 專案更名為 mihomo，程式碼與維護關係也延續下來。截至本文日期，面對新版本、問題修正與新的設定能力時，應優先查閱 mihomo 的現行文件。舊介面顯示「Meta 核心」時，也應繼續檢查版本輸出，因為它實際上可能打包的是 mihomo，只是用戶端尚未更新顯示文字。

功能範圍：差異集中在接管方式、協定與規則處理

基礎的 HTTP、SOCKS、混合連接埠、代理群組與網域規則，並不足以區分核心。多數一般訂閱都能產生這些內容。真正影響選擇的是系統流量如何進入核心、DNS 請求由誰解析、訂閱是否包含新代理協定，以及規則集是否依賴 mihomo 的擴充語法。

TUN 與系統流量接管

系統代理只會影響主動讀取代理設定的應用程式。瀏覽器與部分桌面軟體通常可以使用系統代理，但命令列程式、遊戲、虛擬機器、部分商店應用程式，以及自行實作網路堆疊的軟體，可能會繞過這項設定。TUN 模式透過虛擬網路介面接收更廣泛的 IP 流量，適合需要統一接管的環境，但同時涉及管理員權限、路由表、DNS 劫持、網卡衝突與防火牆規則。

原版開源核心、歷史 Premium 建置版本與現代 mihomo 的 TUN 能力，不能視為同一版本處理。mihomo 目前提供較完整的 TUN 設定，並包含不同協定堆疊與自動路由相關選項。用戶端能否成功啟用，仍取決於作業系統、服務模式與權限。選擇支援 mihomo 的用戶端，只代表核心具備相應能力，不代表用戶端已自動完成驅動程式、服務與路由設定。

代理協定與傳輸參數

較早期的 Clash 設定主要涵蓋當時常見的 Shadowsocks、VMess、Trojan 與 SOCKS 等類型。mihomo 在後續維護中增加或擴充了多種協定與傳輸參數。若訂閱中出現新協定、新加密方式或擴充傳輸欄位，舊版原版核心可能在載入階段直接報錯，也可能忽略不認識的欄位，最後表現為節點無法使用。

這裡不能只比較節點清單是否顯示。圖形介面可能先解析訂閱並繪製節點，但真正發起連線時才會把設定交給核心。節點出現在清單中卻測速失敗，常見原因之一就是前端接受了欄位，但核心版本不支援相應協定。診斷時應查看核心日誌中的解析錯誤、握手錯誤與未知欄位提示。

規則集、子規則與比對能力

經典 Clash 規則通常由規則類型、比對內容與目標策略組成，例如網域後綴、IP 網段、程序名稱及最終匹配。mihomo 在此基礎上提供更豐富的規則與規則集能力，可依設定需求組織遠端規則集、組合邏輯與子規則。大型設定可以藉此縮短主檔案，並依不同更新時間拆分資料。

擴充能力也會帶來遷移限制。設定一旦使用只有 mihomo 支援的規則類型，就不能再假設能直接退回原版。即使 YAML 語法正確，舊核心仍可能因未知規則而拒絕啟動。需要相容多種用戶端時，應以目標裝置中能力最低的核心為基準，或為不同核心分別產生設定。

DNS、嗅探與網域還原

Clash 系列核心的規則決策經常依賴網域，但進入 TUN 的連線可能只呈現目標 IP。DNS 對應、Fake IP 與流量嗅探可補充網域資訊，讓網域規則繼續命中。mihomo 為相關流程提供更多可調欄位，包括監聽、解析伺服器分組、Fake IP 範圍、過濾項目、回退與嗅探覆蓋範圍。

這些選項並非越多越好。企業內網網域、區域網路裝置、遊戲反作弊、瀏覽器加密 DNS 和系統內建解析快取，都可能改變實際路徑。核心選型只能確定可用工具，最終設定仍需配合網路環境。排查問題時應分別檢查系統 DNS、核心 DNS 日誌、規則命中結果與實際出口，避免一次同時修改 TUN、Fake IP 與回退伺服器。

設定相容性：基礎欄位通常可向前延續，擴充欄位無法反向保證

從原版設定遷移至 mihomo，基礎結構通常可以保留。連接埠、執行模式、日誌層級、代理清單、策略群組與常見規則，仍沿用熟悉的層級。以下是一個刻意維持基礎功能的範例：

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxies:
  - name: example-node
    type: socks5
    server: 127.0.0.1
    port: 1080

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - example-node
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.org,PROXY
  - MATCH,DIRECT

這類設定沒有引入特定分支的進階能力，遷移阻力較小。但實際訂閱還可能包含遠端規則提供者、健康檢查、介面綁定、流量嗅探、新協定參數與用戶端覆寫項目。只看檔案開頭幾行，無法判斷整份設定是否相容。

從原版遷移至 mihomo

遷移方向通常較順利。先使用原設定啟動 mihomo，觀察解析與執行日誌，再逐項啟用新功能。不要在第一次啟動時同時改用 TUN、替換 DNS 模式並重寫規則集。穩妥的順序是先確認節點能建立連線，再驗證策略群組切換，接著檢查規則命中，最後處理 TUN 與 DNS。

如果設定來自訂閱，用戶端還可能在下載後追加覆寫內容，例如變更連接埠、插入本機規則、替換策略群組或開啟區域網路存取。匯出的 YAML 與執行時設定不一定完全一致。遇到行為差異時，應使用用戶端提供的執行設定檢視功能，或從外部控制介面確認核心實際載入的內容。

從 mihomo 回退至原版

反向遷移需要逐項刪除擴充欄位，並確認每個節點協定仍受舊核心支援。刪除一個頂層欄位並不足夠，因為不相容內容可能藏在代理節點、規則、DNS、TUN、規則提供者與策略群組參數中。使用遠端訂閱時，下次更新仍會重新寫入這些內容，因此臨時手動修復不能取代訂閱範本調整。

如果某個服務端只提供舊核心不支援的協定，設定轉換也無法自動將它變成另一種協定。訂閱轉換主要負責欄位重組、節點篩選與規則拼接，不能改變服務端實際提供的握手方式。此時應繼續使用支援該協定的 mihomo 核心，或從設定來源取得相容節點。

用戶端選型：先看系統整合，再看核心版本

一般使用者通常不會單獨執行核心，而是安裝附帶圖形介面的用戶端。選型時應分開判斷「前端是否方便操作」與「核心是否符合設定需求」。介面成熟但核心長期未更新的用戶端，可能無法載入新訂閱；核心更新及時但缺少系統服務管理功能的用戶端，也可能不適合長期啟用 TUN。

Windows 桌面環境

Windows 用戶端應重點檢查 mihomo 核心版本、服務模式、TUN 權限處理、系統代理復原功能與日誌入口。只使用瀏覽器與一般辦公軟體時，系統代理模式通常較容易維護。需要接管遊戲、命令列、商店應用程式或不讀取系統代理的軟體時，再評估 TUN。啟用前應記錄原有 DNS、其他虛擬網卡與安全軟體狀態，便於斷網時回退。

部分 Windows 用戶端允許切換多個核心。切換後不能只重新啟動介面，還應確認執行日誌中的核心名稱與版本已經變更。舊設定若帶有 Premium 專用欄位，也要檢查用戶端是否會自動轉換。系統代理連接埠必須與核心監聽連接埠一致，否則介面雖顯示已啟用，應用程式仍會連線至空連接埠。

macOS 桌面環境

在 macOS 上應注意用戶端是否支援目前的處理器架構、系統擴充功能或網路權限，以及退出時能否復原代理設定。許多名稱較早的用戶端仍可能透過更新打包 mihomo，因此產品名稱不能直接代表核心。Apple Silicon 裝置優先使用相符架構的建置版本，避免將架構相容層問題誤判為代理核心故障。

使用系統代理時，應核對 HTTP、HTTPS 與 SOCKS 項目是否由用戶端正確設定。使用 TUN 時，則需檢查虛擬介面、預設路由與區域網路存取。企業管理裝置可能限制網路擴充功能或管理員授權，這屬於系統策略範圍，單純更換設定檔無法解決。

Linux 桌面與伺服器

Linux 桌面可以選擇帶有介面的 mihomo 用戶端，也可以直接執行核心。伺服器更適合使用命令列設定與 systemd 服務，方便固定工作目錄、限制權限、自動重新啟動，並透過 journal 檢視日誌。請注意，在 shell 中設定 HTTP_PROXY 和 HTTPS_PROXY 只會影響讀取這些環境變數的程式，不等同於全域接管。

TUN 部署還涉及網路命名空間、路由規則、轉送開關與容器網路。Docker 容器中的請求是否經過主機 mihomo，取決於網路模式與路由設計。伺服器上不宜直接複製桌面用戶端產生的設定，因為其中可能包含僅供介面使用的相對路徑、控制器位址或本機規則檔案。

Android 與 iOS

行動作業系統通常透過系統 VPN 介面接管流量，前端應用程式對核心生命週期與背景執行的控制，比桌面端更重要。應確認應用程式實際整合的核心、支援的代理協定、按應用程式分流能力與系統版本要求。行動用戶端顯示的「VPN」代表本機流量入口，不表示流量一定連線至傳統企業 VPN；後續仍由規則與代理群組決定直連或轉送。

在 iOS 上不能將桌面端核心檔案直接放入應用程式執行。應用程式能使用哪些核心功能，取決於其打包版本與系統審核下的實作方式。Android 也存在廠商背景限制、省電最佳化與 VPN 常駐策略。節點在桌面端正常但在行動端頻繁斷線時，應同時檢查系統背景限制，而不是只更換訂閱。

依使用情境形成選擇結論

對於新部署，選擇持續維護的 mihomo 通常更合理。依據不在於名稱是否更新，而在於設定生態、協定變化與作業系統網路堆疊都會持續演進。仍在穩定運作的舊環境，不必在沒有備份與測試的情況下立即替換，但應記錄目前核心、用戶端版本、設定來源與啟動參數，避免故障發生後找不到可重現的條件。

如果多部裝置由同一個訂閱管理，最好統一核心大版本，並為桌面與行動端分別保留少量平台覆寫。通用部分保留節點、策略群組與規則，平台部分處理 TUN、監聽位址、介面綁定與區域網路存取。如此可避免為了配合單一裝置，而將平台專用欄位寫入所有設定。

執行遷移：以最少變數逐步驗證

1. 記錄目前狀態。保存用戶端版本、核心名稱、核心版本、設定來源、系統代理連接埠與是否啟用 TUN。截圖只能輔助定位，文字日誌與設定更適合比較。
2. 備份本機覆寫。訂閱網址通常只提供遠端主體，本機規則、策略群組調整與 DNS 例外可能儲存在用戶端資料庫中。升級前應使用用戶端的匯出功能保留這些內容。
3. 先測試基礎代理。關閉 TUN 與複雜的 DNS 覆寫，透過系統代理或明確的 SOCKS 連線驗證一個節點。確認節點握手成功後，再檢查策略群組與規則。
4. 檢查規則命中。分別造訪應直連與應代理的目標，在日誌中確認目標網域、規則類型與最終策略。僅憑網頁能否開啟，無法判斷是否經由預期出口。
5. 啟用 DNS 設定。確認核心監聽連接埠沒有衝突，再檢查網域解析是否由預期伺服器處理。使用 Fake IP 時，應個別驗證區域網路裝置、內網網域與不相容的應用程式。
6. 最後啟用 TUN。檢查管理員權限、虛擬介面、自動路由與 DNS 劫持。若發生斷網，先關閉 TUN 並復原系統代理，再讀取日誌，不要連續切換多個網路工具。
7. 完成重新啟動驗證。重新啟動系統或服務，確認用戶端能復原設定、訂閱不會覆蓋關鍵設定，且系統代理與路由能依預期建立。

常見誤判與定位方法

介面寫著 Meta，所以一定是舊核心：並非如此。Meta 可能只是用戶端沿用的歷史命名。應讀取啟動日誌或核心版本介面，確認實際執行的二進位檔。

訂閱匯入成功，所以設定完全相容：並非如此。前端匯入、核心解析、節點握手與規則執行是不同階段，需要逐層檢視日誌。

切換至 mihomo 後就必須啟用 TUN：並非如此。mihomo 同樣支援 HTTP、SOCKS 與混合連接埠。系統代理能滿足需求時，可以繼續使用較簡單的接管方式。

設定轉換能解決所有協定差異：並非如此。轉換器可以重新排列設定，卻不能改變服務端協定，也不能讓舊核心取得缺少的實作。

同名策略群組在所有裝置上的行為都一致：不一定。健康檢查間隔、延遲測試位址、網路權限與核心版本，都可能改變自動選擇結果。需要比較群組類型、候選節點與測試參數。

結論：新部署以 mihomo 為基準，舊環境依相容性遷移

Clash 原版提供了廣泛沿用的設定與規則模型，但其專案已經封存。Clash.Meta 是擴充分支曾使用的名稱，mihomo 則是該分支更名後目前使用的專案。若將 Meta 與 mihomo 視為兩個同時競爭的新舊核心，會造成版本判斷錯誤；正確做法是結合專案沿革、用戶端打包版本與執行日誌，確認實際核心。

選型時，基礎系統代理、簡單規則與傳統節點協定對核心要求較低；新協定、複雜規則集、精細 DNS、流量嗅探與 TUN 接管則更依賴目前 mihomo 的能力。新安裝應優先選擇持續維護且明確整合 mihomo 的用戶端。現有舊環境則應先記錄狀態，使用最小設定完成遷移測試，再逐步恢復 DNS、規則集與 TUN。

最終判斷標準不是用戶端名稱，也不是訂閱檔案能否匯入，而是核心能否完整解析設定、穩定建立節點連線、依預期命中規則，並在系統重新啟動後恢復網路狀態。圍繞這四項驗證，可以將核心升級從一次整體替換，拆分為可觀察、可回退的工程步驟。