先區分核心、用戶端與設定體系
討論 mihomo 與原版 Clash 時，最容易出現的誤區，是把核心、圖形用戶端和訂閱設定視為同一個產品。原版 Clash 通常是指由 Dreamacro 維護的 Clash 開源核心；它負責監聽本機連接埠、建立代理連線、執行規則、處理 DNS，並透過外部控制介面向圖形介面提供執行狀態。原始專案停止持續維護後，原版核心仍能執行既有設定，但不會繼續跟進新的協定、規則能力與各平台的網路變化。
mihomo 是從 Clash.Meta 延續而來的核心專案。它保留 Clash 設定體系、策略群組與規則比對方式，同時擴充協定、DNS、TUN、規則集合及流量控制能力。名稱變更不代表設定體系重新設計：許多仍使用 Clash.Meta 標識的用戶端、設定目錄或文件，實際上已接入 mihomo；判斷時應查看用戶端設定中的核心名稱與版本，而不是只看應用程式標題。
圖形用戶端則是核心外部的管理層，通常負責下載訂閱、切換設定、編輯策略群組、控制系統代理與顯示連線記錄。同一個用戶端可以更換不同核心，同一份設定也可能被多個用戶端讀取。因此，「用戶端支援某欄位」實際上包含兩層含義：隨附的核心能否解析該欄位，以及介面能否正確顯示與修改它。核心可以正常執行，但介面沒有對應開關的情況並不少見。
協定支援差異：mihomo 涵蓋更廣，但仍受設定與網路環境限制
原版 Clash 已涵蓋 Shadowsocks、VMess、Trojan、Snell、HTTP 和 SOCKS 等常見代理類型，能滿足傳統 Clash 設定的基本需求。mihomo 在此基礎上持續加入並維護 VLESS、Reality 相關傳輸、Hysteria、Hysteria2、TUIC、WireGuard 等能力，也持續適配協定參數變化。實際可用範圍仍取決於已安裝的 mihomo 版本，較舊用戶端內建的核心可能無法辨識新欄位。
支援某種協定並不代表匯入後一定能連線。VLESS 節點可能同時依賴 TLS、Reality、WebSocket、gRPC 或其他傳輸參數；Hysteria2 與 TUIC 主要基於 UDP，在限制 UDP 的網路中可能出現握手逾時；WireGuard 設定還涉及位址、私鑰、公鑰、路由與 MTU。訂閱轉換過程若遺失欄位，即使核心支援該協定，也無法還原缺少的參數。
從原版 Clash 遷移到 mihomo 時，既有的 Shadowsocks、VMess 和 Trojan 節點通常最容易保持相容。反向遷移則不能以相同邏輯理解：含有 VLESS、Hysteria2、TUIC 或 mihomo 專屬選項的設定，交由原版核心處理時可能直接回報未知代理類型，也可能在解析到不支援的欄位時停止載入。設定相容性更接近「mihomo 對傳統 Clash 語法保持高度相容」，而不是兩個核心之間完全雙向等價。
切換協定前應檢查的項目
- 用戶端實際內建的核心版本，以及是否允許獨立更新核心。
- 節點協定、傳輸層、TLS、伺服器名稱與憑證驗證等欄位是否完整。
- 目前網路是否允許 UDP，以及路由器、防火牆或企業網路是否限制相關流量。
- 訂閱更新後是否經過轉換服務，以及轉換過程是否保留新協定參數。
- 同名策略群組是否仍引用有效節點，避免節點存在卻未被任何策略群組選取。
規則與策略群組：基本模型一致，擴充能力不同
兩者的核心分流模型相近：流量依序比對規則，命中後交由代理節點或策略群組處理；未命中的連線通常由最後的 MATCH 規則接管。DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD、IP-CIDR、GEOIP、PROCESS-NAME 等常見規則便於遷移，select、url-test、fallback、load-balance 等策略群組也延續 Clash 使用者熟悉的組織方式。
mihomo 擴充了規則表達能力，包括更豐富的規則類型、邏輯組合、入站條件、網路類型及規則集合能力。AND、OR、NOT 等邏輯規則適合表達「特定網域且來自某個入站」這類複合條件，但括號、逗號和子規則結構必須符合目前核心語法。複雜規則不會自動提高準確率；條件越多，排查命中結果時越需要結合連線記錄與規則追蹤資訊。
規則集合也要區分資料格式。傳統網域清單、IP CIDR 集合、經典規則文字以及二進位規則集，在 behavior、format 和載入方式上並不相同。若 rule-provider 宣告為 domain，內容卻放入完整的逗號分隔規則，即使更新成功，也可能無法依預期進行比對。mihomo 還可使用 GEOSITE 與 GEOIP 資料進行分類，但分類名稱受所使用的地理資料檔案影響，並非所有資料來源都包含相同標籤。
mode: rule
proxy-groups:
- name: 手動選擇
type: select
proxies:
- DIRECT
rule-providers:
local-direct:
type: file
behavior: domain
format: text
path: ./rules/direct.txt
rules:
- RULE-SET,local-direct,DIRECT
- MATCH,手動選擇上例只展示規則集合與策略群組之間的引用關係。遷移實際設定時，還要保留現有代理節點、代理提供者與完整策略群組，不能把片段單獨覆蓋到正在使用的檔案。若設定來自訂閱，優先使用用戶端提供的覆寫或合併功能新增自訂規則，避免下次更新訂閱時遺失修改。
DNS 與 TUN：功能更完整，也更依賴系統環境
Clash 系列核心的 DNS 模組不僅負責將網域解析為 IP，也會影響規則比對、代理伺服器位址解析，以及防止系統 DNS 遭到繞過。原版 Clash 已提供 fake-ip、redir-host、nameserver、fallback 和 fallback-filter 等機制。mihomo 持續擴充 nameserver-policy、proxy-server-nameserver、direct-nameserver、fake-ip-filter 等設定，讓代理節點網域、直連網域與一般查詢可以使用不同的解析路徑。
這些欄位各有明確分工。nameserver 負責一般查詢；proxy-server-nameserver 可用來解析代理伺服器本身的網域，避免建立代理前出現依賴循環；nameserver-policy 可以依網域指定解析器；fake-ip-filter 用於排除不適合回傳虛擬位址的網域。啟用 respect-rules 這類依賴規則選擇解析路徑的選項時，也要確保代理節點網域有可用的獨立解析器，否則 DNS 查詢可能需要透過代理，而代理連線又在等待 DNS 結果。
fake-ip 模式會為網域分配虛擬位址，再由核心在接管連線時還原網域，因此通常能提供較穩定的規則比對效果。區域網路裝置探索、某些遊戲、列印服務，以及依賴真實位址的應用程式，可能需要加入過濾清單。redir-host 回傳真實解析結果，行為更接近傳統 DNS，但在複雜分流與 DNS 污染環境下，需要更謹慎地規劃上游解析器。遷移時不應只複製 enhanced-mode 一行，還要一併檢查監聽位址、IPv6、過濾範圍與上游協定。
TUN 模式用於接管不遵循系統代理設定的流量，包括部分命令列程式、遊戲與使用自訂網路堆疊的應用程式。mihomo 提供較完整的 TUN 路由、DNS 劫持、自動路由與介面識別能力，但能否使用仍取決於作業系統權限、虛擬網卡驅動程式、防火牆與其他網路軟體。system、gVisor 等網路堆疊在效能、相容性與平台支援上有所差異，應先使用用戶端預設建議選項，再針對具體故障調整。
設定相容性不只看 YAML 能否載入
一份設定能被 mihomo 成功解析，只代表欄位語法通過檢查，不代表節點可用、規則正確命中或外部控制介面完全相容。遷移評估至少要分成四層：YAML 結構、核心欄位、執行資源與用戶端控制。縮排錯誤、重複鍵與錯誤資料型別屬於 YAML 層；未知代理類型、策略群組參數不相容屬於核心層；規則檔案遺失、地理資料庫未下載屬於資源層；外部控制位址、驗證金鑰與介面差異則會影響圖形用戶端。
mihomo 通常能讀取傳統的 proxies、proxy-groups、rules、proxy-providers 和 rule-providers 結構，也保留 mixed-port、socks-port、redir-port、allow-lan、mode、log-level 等常用欄位。不過，有些歷史設定依賴特定的 Clash Premium 行為，另一些設定則加入了用戶端專屬覆寫。看到相同欄位名稱時，還要核對欄位值的格式與目前版本文件，不能只根據檔案副檔名判斷相容性。
外部控制介面整體延續 Clash API 的使用方式，因此許多控制面板仍可查看流量、連線、策略群組與記錄。但如果介面尚未適配 mihomo 新增的代理類型或設定欄位，可能只顯示基本資訊，甚至在儲存設定時移除未知內容。重要的擴充項目應放在獨立設定或覆寫檔案中，並確認用戶端的儲存動作不會重寫原始訂閱。
常見不相容情況與排查方向
- 啟動時立即報錯：優先查看錯誤行號，檢查 YAML 縮排、欄位型別，以及目前核心是否支援對應的代理類型。
- 設定載入成功但節點全部逾時：檢查節點參數、代理伺服器 DNS、系統時間、UDP 條件與訂閱欄位是否完整。
- 策略群組為空：檢查 proxies、use、filter 與 exclude-filter，確認提供者名稱和篩選運算式能匹配節點。
- 規則未依預期命中：檢查規則順序、規則集合 behavior、解析結果，以及連線是否確實由 TUN 或系統代理接管。
- 介面可以連線但無法編輯：可能是用戶端尚未提供對應表單，應透過支援的覆寫方式維護擴充欄位。
從原版 Clash 遷移到 mihomo 的執行順序
穩定遷移的重點是縮小變數範圍。不要在更換核心的同時重寫 DNS、替換所有規則集並啟用 TUN，否則故障出現後很難判斷來源。先讓原有設定在新核心中完成解析與基本連線，再逐項啟用 mihomo 的擴充功能。
- 保留目前的設定與用戶端設定。記錄監聽連接埠、系統代理狀態、目前策略群組選擇、DNS 模式與外部控制位址。訂閱位址與本機覆寫應分開保存。
- 確認設定來源。區分本機 YAML、遠端訂閱、代理提供者與用戶端產生的設定。直接修改快取檔案通常會在重新整理訂閱後被覆蓋。
- 使用 mihomo 進行語法檢查。在命令列環境中可執行
mihomo -t -f config.yaml檢查設定。圖形用戶端則應查看核心記錄中的具體檔案與行號。 - 先測試基本代理。保留原有規則模式，選擇一個已知可用的節點，確認網頁瀏覽、DNS 查詢與策略切換正常。此階段先不要新增協定節點。
- 驗證規則與提供者。檢查遠端規則集能否下載、策略群組是否有成員、MATCH 最終規則是否存在，並透過連線記錄確認常用網域實際命中的項目。
- 單獨啟用 DNS 擴充功能。依需求設定代理伺服器解析、網域策略與 fake-ip 過濾。每次只調整一組欄位，並觀察是否出現解析逾時或循環依賴。
- 最後測試 TUN。關閉其他代理用戶端，確認虛擬網卡權限與路由復原機制，再測試不使用系統代理的程式。出現斷網時應先退出 TUN，而不是持續修改節點參數。
mihomo -t -f config.yaml語法檢查通過後，還應進行執行驗證。建議依序檢查核心記錄、代理群組選擇、DNS 查詢、連線詳情與系統路由。若舊設定包含大量自訂欄位，可以先複製出最小設定，只保留一個本機連接埠、一個節點、一個策略群組與最後規則；最小設定能夠連線後，再逐段恢復規則提供者、DNS 與 TUN 設定。
如何選擇：依設定需求與維護狀態判斷
仍在使用固定傳統節點、簡單網域規則且網路環境長期不變的裝置，原版 Clash 設定可能仍能運作。但原版核心已停止持續維護，遇到新協定、作業系統網路變化與長期相容性問題時，可用的修復途徑有限。對新安裝環境、需要更新協定、複雜規則集合、精細 DNS 或 TUN 接管的使用者而言，mihomo 通常是更合適的核心選擇。
選擇圖形用戶端時，應確認其內建 mihomo 版本、核心更新方式、設定覆寫機制與記錄入口。僅標示「支援 Clash 設定」不足以說明它能完整管理 mihomo 的擴充功能。需要長期維護的設定也應減少對用戶端私有欄位的依賴，將節點來源、策略群組、規則集合與本機覆寫分層管理。
最終判斷標準不是功能數量，而是目前設定是否可驗證、可更新且可回復。mihomo 擴充了 Clash 設定體系的邊界，但每項擴充也會增加相應的參數與環境條件。依照「先相容舊設定，再增加新能力」的順序遷移，可以分別處理協定、DNS、規則與系統接管問題，也更容易在更新核心後定位變化。