本文目錄
閱讀教學時看到不同的專案名稱，很容易把介面程式、代理核心與舊名稱當成互相替代的工具。判斷設定是否適合目前的裝置，真正要看實際執行的核心與版本。了解名稱關係能幫助閱讀舊文件，相容性仍要透過設定檢查與實際連線確認。
Clash Meta 與 Mihomo 是同一專案的不同名稱
Mihomo 是 Clash Meta 後來採用的專案名稱。Original Clash 通常指 Dreamacro 發起的早期 Clash 核心；舊教學中的 Meta 與目前日誌中的 Mihomo，不代表兩套需要二選一的核心。
更容易混淆的是用戶端名稱。Clash Verge Rev、FlClash 和 Clash Party 是圖形用戶端，它們負責訂閱、系統代理和介面，裡面實際執行的核心才可能是 Mihomo。檔案名帶 Clash，不足以證明它使用的是原版 Clash。
名稱對應的層級
| 名稱 | 通常指什麼 | 現在看它有什麼用 |
|---|---|---|
| Original Clash | 最初的 Clash 核心與基礎設定模型 | 理解歷史設定和舊用戶端行為 |
| Clash Meta | 在原有模型上擴展的後續核心名稱 | 閱讀舊文件、舊日誌和舊訂閱說明 |
| Mihomo | Clash Meta 目前使用的專案名稱 | 新部署、目前欄位和維護中的核心 |
| Clash 圖形用戶端 | 管理核心的桌面或移動應用 | 看介面、平台支援和實際內建核心版本 |
查看實際執行的用戶端與核心版本
同一份訂閱在兩台電腦上表現不同，先核對實際載入的設定、核心和版本。可在用戶端的「設定 → 關於」「核心」或「執行日誌」中記錄完整名稱與版本；命令列部署則查看目前執行的二進位檔，不用路徑中另一份同名程式的結果代替。
mihomo -v
# 如果机器上运行的是旧名称的二进制，也应先看它自己的版本
clash -v記錄時不要只寫「最新版」
- 用戶端名稱與版本
- 核心顯示為 Mihomo、Clash Meta 還是 Clash
- 核心具體版本號
- 作業系統和 CPU 架構
- 發生錯誤時實際載入的設定檔
設定格式相似，也不能直接在不同核心間來回使用
Mihomo 延續了 proxies、proxy-groups 和 rules 等核心結構，所以基礎設定看起來很熟悉。但它後來增加或擴展了協議、DNS、TUN、規則集、嗅探和執行階段欄位。
舊核心遇到自己不認識的內容，可能報 unknown field、unsupported proxy type，也可能直接忽略某些欄位，留下更難發現的行為差異。
舊設定遷到新核心也可能需要調整。若舊設定使用的行為、指令碼能力或用戶端產生欄位已經變化，在 Mihomo 中就要重新驗證。相容不能只看「YAML 能開啟」，還要設定檢查通過、策略群組引用完整，規則命中與 DNS 結果都符合預期。
同一份訂閱最容易出現差異的地方
| 部分 | 原版 Clash 環境 | Mihomo 環境 | 遷移時怎麼做 |
|---|---|---|---|
| 節點協議與傳輸 | 取決於舊核心及其版本，只認識當時支援的欄位 | 持續增加和維護更多協議與傳輸選項 | 出現 unsupported proxy type 時核對核心，不刪除節點欄位硬湊 |
| DNS | 不同開源/Premium 版本的能力與欄位並不完全一樣 | 目前文件包含完整的 DNS、Fake-IP 和 nameserver 選項 | 先沿用最小 DNS，再逐項遷移 Fake-IP 過濾和上游 |
| TUN | 是否可用取決於舊版分支、版本和用戶端整合 | 目前 Mihomo 與主流用戶端普遍提供 TUN | 先用系統代理驗證，再單獨開啟 TUN 和服務權限 |
| 規則與 Provider | 舊核心只接受它認識的規則類型和結構 | 支援目前文件中的規則、規則集及擴展欄位 | 檢查 rule-provider behavior、策略群組名稱和最終合併結果 |
| 用戶端附加欄位 | 可能由舊 GUI 的 Mixin、Parsers 或指令碼產生 | 由新用戶端的 Merge、Script 或覆寫產生 | 按原用途重建，不整段複製用戶端私有設定 |
unknown field
常見原因：目前核心不認識該欄位，或欄位被放錯層級
處理方法：以實際核心版本的官方文件核對，不靠刪除冒號試錯。
unsupported proxy type
常見原因：協議或傳輸能力超出目前核心支援
處理方法：升級到服務方要求的維護中核心，或改用相容節點。
proxy/group not found
常見原因：策略群組、規則或覆寫引用的名稱不存在
處理方法：檢查最終合併設定，而不只看原始訂閱。
能載入但規則表現不同
常見原因：DNS、規則順序或用戶端覆寫改變了執行結果
處理方法：用連線記錄對照同一網域的命中規則和出口。
新裝環境優先選維護中的 Mihomo，舊核心只留給明確的遺留需求
如果現在重新安裝桌面用戶端、路由器外掛程式或伺服器服務，優先選擇明確使用 Mihomo、仍有官方發布和問題跟蹤的專案。這樣做主要是為了目前系統相容、安全修復和文件一致，而不是因為名稱更新就自動更快。
保留 Original Clash 的合理情境通常很窄：某套離線環境已經凍結，設定只使用它已知的能力，而且升級風險高於收益。即便如此，也應記錄二進位來源、版本和還原方法，不應繼續把舊核心暴露為公用網路控制服務。
- OpenWrt 使用者
- 同時確認外掛程式版本、Mihomo 核心架構和可用儲存，不只升級 LuCI 頁面。
- 伺服器端或容器部署
- 鎖定明確版本，先在測試目錄執行設定檢查，再替換執行實例。
- 遺留原版環境
- 保持隔離與可回滾，不將新協議訂閱直接推給舊核心。
把舊設定遷到 Mihomo：備份、設定檢查與實際連線測試
一份設定的安全遷移順序
保留舊設定
備份舊設定、核心版本和一組可重複存取的測試位址。
移除用戶端私有項
不要把舊 GUI 的視窗、快取或服務設定當成 Mihomo 設定複製。
先跑設定檢查
使用實際選定的 Mihomo 二進位檔，在獨立測試目錄檢查候選設定；命令範例見下方。處理實際出現的首條解析、類型或參照錯誤，避免一次刪除整段。
固定相同節點
先比較常用網站與內部網域；不讀取系統代理的應用程式，留到下一步開啟 TUN 後再測試。
再開 DNS 與 TUN 擴展
一次只改變一層，觀察連線記錄、規則命中和退出後的網路恢復。
以下命令依 Mihomo v1.19.32 的參數寫成範例。把二進位檔和兩個絕對路徑換成實際位置；測試目錄要有候選設定所需的可信 Provider 與資料檔副本，不能指向正在執行的目錄。
-t 檢查後退出，-d 指定工作目錄，-f 指定設定。初始化可能寫入測試目錄或取得所需資源，不等於完全唯讀；成功輸出只證明設定檢查通過，連線、規則和退出後的恢復仍須另外驗證。檢查通過也不代表支援未知或舊用戶端的私有欄位，仍須對照該版本文件。
mihomo -t -d '/absolute/path/to/test-data' -f '/absolute/path/to/candidate.yaml'遷移完成的判斷不是用戶端顯示「已連線」，而是舊環境中的關鍵流量在新核心裡命中預期規則，區域網路與內部網域仍能直連，系統代理或 TUN 關閉後網路能恢復。達成這些結果以後，再刪除舊二進位和舊服務。