先釐清名稱：用戶端、核心與專案沿革
討論 Clash 原版、Clash.Meta 與 mihomo 之前，先把「用戶端」與「核心」分開。核心負責讀取 YAML 設定、建立代理連線、執行規則比對、處理 DNS，並向圖形介面提供控制介面。桌面用戶端則負責訂閱管理、設定切換、系統代理開關、日誌檢視與更新操作。使用者看到的應用程式名稱不一定等於實際呼叫的核心名稱，同一個圖形用戶端也可能在不同版本中更換核心。
通常所說的 Clash 原版，是指由 Dreamacro 維護的經典 Clash 開源核心及其設定體系。它確立了代理節點、策略群組、規則、外部控制器等核心結構，許多訂閱轉換服務與圖形用戶端都以這套格式為基礎。歷史上也存在功能範圍不同的 Premium 建置版本，因此只看到「Clash」字樣時，不能僅憑名稱判斷具體支援哪些欄位。
Clash.Meta 最初是相容於 Clash 設定思路的擴充核心，加入更多代理協定、DNS 選項、規則能力與透明代理功能。後來專案正式改用 mihomo 這個名稱。可以把 Clash.Meta 與 mihomo 理解為同一條專案演進路線中的前後稱呼，而不是兩個完全獨立、需要二選一的新核心。舊教學中的 Meta 設定、舊用戶端裡的 Meta Core，很多時候對應的就是今天的 mihomo 系列。
原版 Clash 專案停止活躍維護後，生態系並未隨著名稱一同停擺。訂閱格式、規則語法與控制介面仍被大量軟體沿用，而持續更新的用戶端則逐漸轉向 mihomo。現在進行新安裝或長期部署時，重點不應是尋找名稱最早的版本，而應確認維護狀態、平台支援、所需協定與設定欄位是否相符。
功能範圍：共同基礎與 mihomo 擴充
兩類核心的共同基礎包括 YAML 設定、代理節點、策略群組、網域與 IP 規則、DIRECT 與 REJECT 動作、HTTP/SOCKS 混合連接埠，以及外部控制介面。對於只包含常見節點、簡單策略群組與基本規則的設定，使用者可能感受不到明顯差異。差異通常會在訂閱包含新協定、啟用複雜 DNS、使用 TUN 模式或載入遠端規則集時出現。
代理協定與傳輸參數
原版 Clash 支援其維護期間涵蓋的主流協定，但後續出現的新協定、加密方式與傳輸擴充不會自動獲得支援。mihomo 在相容傳統設定的基礎上持續增加協定實作與參數選項。若訂閱中的節點被標示為「不支援的類型」，或日誌提示無法解析代理欄位，首先應核對核心，而不是反覆重新匯入同一份訂閱。
協定數量並不是唯一的判斷標準。即使節點類型相同，不同核心對 TLS 指紋、UDP、多路複用、傳輸層與憑證相關參數的支援範圍也可能不同。選擇時應依照實際訂閱產生的欄位進行檢查，而不是只看節點名稱是否出現在清單中。節點能顯示在介面裡，也不代表連線參數已完整辨識。
DNS 與規則系統
經典 Clash 設定已具備網域規則、IP 規則、GEOIP、規則提供者等常用結構。mihomo 在此基礎上提供更豐富的 DNS 處理方式、規則集合能力與比對選項，適合需要區分中國大陸與其他地區解析、處理 Fake IP 例外、載入大型規則集或精細控制流量的設定。具體欄位會隨核心版本調整，因此應以目前的核心文件與啟動日誌為準。
規則能力增加後，設定錯誤也更容易藏在冗長檔案中。例如規則集名稱已宣告，但引用路徑無法存取；DNS nameserver 可以連線，卻被目前的路由規則再次送入代理而形成迴圈；規則順序正確，卻因前方的廣泛比對而永遠無法到達後面的細分項目。升級核心不能取代規則檢查，日誌中的比對結果仍是主要依據。
TUN 與透明代理
系統代理主要影響會主動讀取作業系統代理設定的應用程式。TUN 模式則透過虛擬網路介面接管更廣泛的 IP 流量，適合不遵循系統代理、需要 UDP，或希望統一處理應用程式流量的情境。不同原版建置版本的 TUN 能力並不完全一致，而 mihomo 持續維護 TUN 堆疊、路由、DNS 劫持與平台相關選項，因此現代桌面用戶端與閘道部署通常更傾向使用 mihomo。
TUN 不代表安裝後就會自動變快。它會引入權限、路由表、虛擬網卡、防火牆與 DNS 鏈路等額外變數。只瀏覽網頁且應用程式遵循系統代理時，系統代理通常更容易維護；需要接管遊戲、命令列程式、沙盒應用程式，或無法個別設定代理的軟體時，再啟用 TUN 會更合適。
設定相容性：基礎設定通常可讀取，擴充欄位不保證反向相容
mihomo 的設計目標之一是承接 Clash 設定生態，因此傳統的連接埠、節點、策略群組與規則結構通常可以直接讀取。這種相容關係更接近「新核心讀取舊格式」，而不是任意方向都完全等價。設定一旦使用 mihomo 專屬協定、規則類型、DNS 欄位或 TUN 參數，再交給原版核心時，可能發生啟動失敗、未知欄位遭忽略、節點缺少或行為改變。
以下是一段偏基礎的結構範例，展示節點、策略群組與規則之間的引用關係，不代表可直接投入正式環境；伺服器位址與驗證資訊需由實際訂閱提供。
mixed-port: 7890
mode: rule
log-level: info
proxies:
- name: example-node
type: socks5
server: 192.0.2.10
port: 1080
username: demo
password: demo
proxy-groups:
- name: PROXY
type: select
proxies:
- example-node
- DIRECT
rules:
- DOMAIN-SUFFIX,example.org,PROXY
- GEOIP,CN,DIRECT
- MATCH,PROXY遷移這類設定時，最先檢查的不是縮排以外的視覺差異，而是引用鏈：策略群組中的節點名稱必須與節點定義完全一致，規則結尾的策略名稱必須確實存在，遠端提供者的名稱也要與策略群組或規則引用相符。YAML 對縮排十分敏感，混用 Tab 與空格、冒號後缺少空格、同層欄位縮排不一致，都會導致載入失敗。
訂閱連結不等於固定的核心格式
訂閱服務可能根據用戶端請求標頭、連結參數或轉換範本回傳不同內容。同一個訂閱網址，在一個用戶端中可能取得 Clash 基礎格式，在另一個用戶端中則可能取得包含 mihomo 擴充欄位的設定。遷移用戶端後出現節點數量變化，不能直接判定訂閱失效，應先匯出設定並比較節點類型、代理提供者、策略群組與規則集欄位。
部分用戶端只儲存訂閱入口，更新時會覆寫本機編輯內容。若需要新增規則，應確認用戶端是否提供覆寫、擴充腳本或合併設定功能。直接修改快取檔案通常只能維持到下一次訂閱更新。核心負責解讀最終設定，用戶端則決定訂閱如何下載、轉換與合併，這兩個環節需要分開排查。
控制介面通常相近，管理介面仍需相互配合
許多 Clash 管理面板會透過外部控制器讀取代理、連線、規則與日誌。mihomo 延續了大量常用介面，因此舊面板可能仍能運作，但新增功能未必能在舊介面中完整顯示。若核心正常運作而介面看不到某類設定，可能是用戶端或面板尚未實作對應的控制項，並非核心設定無效。
情境選擇：分別判斷桌面、伺服器與舊設定
全新安裝桌面用戶端
在 Windows、macOS 或 Linux 桌面環境進行全新安裝時，優先選擇仍在維護且明確採用 mihomo 核心的用戶端。這樣更容易獲得新協定支援、近期系統相容性調整與持續修正。選擇安裝包時也要核對作業系統版本與 CPU 架構，例如 x64 與 ARM64 不能只根據檔案大小判斷。
桌面使用者若只需要匯入訂閱、選擇策略群組並開啟系統代理，不必為了「功能更多」就立即修改進階設定。先使用用戶端產生的預設連接埠與 DNS 設定，確認瀏覽器存取、規則切換與中斷後恢復正常，再依需求啟用 TUN。減少首次設定的變數，故障定位會更直接。
伺服器、路由器與容器部署
伺服器或旁路閘道通常沒有完整圖形介面，因此核心本身的架構建置、啟動參數、設定路徑與服務管理方式更為重要。mihomo 適合需要規則集、透明代理、遠端控制與持續更新的部署，但也必須同時處理執行權限、轉送規則、DNS 入口與日誌輪替。在容器中啟用 TUN 時，還需要為容器提供相應的裝置與網路權限。
閘道情境應避免直接照搬桌面設定。桌面上的監聽位址可能只繫結本機，部署到區域網路後需要明確允許的介面與存取控制；外部控制器也不應在缺乏驗證與網路限制的情況下對外公開。規則數量較多時，還要留意啟動時間、記憶體用量，以及遠端規則更新失敗後的行為。
仍在穩定運作的原版設定
一份原版 Clash 設定若功能簡單、執行環境固定且目前連線穩定，不需要只因名稱改變就立即重寫。較穩妥的做法是在隔離目錄中準備 mihomo，複製設定進行語法檢查與平行驗證，確認節點、策略群組、DNS 結果與規則命中一致後，再切換服務。
繼續使用舊核心的主要限制，是後續協定與系統變化無法獲得持續相容。訂閱提供方一旦更換節點類型，舊核心可能突然無法解析；作業系統升級後，舊用戶端也可能出現權限、系統匣、虛擬網卡或簽章相容性問題。因此可以保留可用設定，但也應同時準備遷移方案。
必須依賴舊欄位或舊用戶端
某些自動化腳本、控制面板或嵌入式裝置只針對固定的 Clash API 與檔案配置開發。此時應先確認依賴點：是設定語法、控制介面、二進位檔名稱，還是啟動參數。mihomo 透過適當的參數與路徑安排，可以相容不少流程，但不能假設所有周邊工具都不需要調整。先在測試連接埠上執行，避免與現有控制器和監聽連接埠衝突。
從 Clash 原版遷移至 mihomo：逐項檢查
- 記錄目前狀態。保存原始設定、訂閱網址、用戶端版本、核心版本、監聽連接埠與目前啟用的代理模式。若發生問題，就能準確回復並進行比較。
- 選擇相符的建置版本。核對作業系統與 CPU 架構。桌面用戶端應確認內建核心類型；命令列部署則確認下載的是對應平台的 mihomo 可執行檔。
- 先進行設定驗證。不要第一步就替換正在執行的服務。使用新核心檢查 YAML，處理未知代理類型、重複連接埠、缺少策略群組與無法讀取的提供者。
- 查看啟動日誌。重點留意設定解析、規則集下載、DNS 監聽、外部控制器、TUN 裝置與連接埠占用。日誌顯示「已啟動」不代表所有遠端資源都載入成功。
- 驗證策略群組。逐一檢查手動選擇、自動測速、故障轉移等策略群組是否包含預期節點。訂閱轉換後，節點名稱變更可能使舊有引用失效。
- 驗證 DNS。分別檢查台灣本地域名、代理目標網域與純 IP 連線。若瀏覽器可以開啟而命令列失敗，或網域連線失敗但 IP 可通，應優先檢查 DNS 監聽與劫持鏈路。
- 最後啟用 TUN。確認系統代理模式正常運作後，再測試虛擬網卡接管。若出現全域斷網，請檢查管理員權限、預設路由、DNS 劫持、其他 VPN 軟體與防火牆規則。
常見遷移錯誤
- 用戶端升級了，但實際核心仍停留在舊版本，介面版本號與核心版本號被混為一談。
- 把 Meta 與 mihomo 當成兩套互不相關的格式，重複轉換訂閱，導致策略群組或規則遭到二次處理。
- 直接把 mihomo 專屬欄位複製回原版 Clash，載入設定時才發現類型或參數不受支援。
- 只測試首頁能否開啟，卻沒有檢查規則命中、UDP、DNS、區域網路存取與中斷後的網路恢復。
- 系統代理與 TUN 同時啟用後發生異常，卻沒有分別測試兩條接管路徑。
若新核心啟動後完全無法連網，先將模式切回規則模式的基礎設定，並暫時關閉 TUN。確認混合連接埠監聽、節點握手與策略群組選擇無誤後，再逐項恢復 DNS 增強功能與規則集。分層啟用比一次匯入所有進階選項更容易定位問題。
結論：新部署優先選擇 mihomo，舊設定依需求遷移
Clash 原版奠定了至今仍廣泛使用的設定與規則基礎；Clash.Meta 是擴充路線的舊稱，mihomo 則是這條路線目前使用的專案名稱。三者並不是簡單的版本號高低關係，而是維護階段、功能範圍與生態承接關係。
全新安裝桌面用戶端、需要現代協定、複雜 DNS、規則集或 TUN 的使用者，通常應選擇明確採用 mihomo 且持續維護的用戶端。已有的原版設定若長期穩定，可以先保留，再透過測試環境完成遷移。判斷是否適合的可靠標準不是名稱，而是目前核心能否完整解析訂閱、正確執行規則、相容作業系統，並提供可持續的更新途徑。
安裝完成後，先核對核心資訊，再匯入訂閱；先驗證系統代理，再依情境啟用 TUN；先閱讀啟動日誌，再修改進階欄位。依照這個順序操作，原版、Meta 與 mihomo 的名稱差異就不會成為排除故障的障礙。