本文目錄
Mihomo、Clash Meta、原版 Clash，先分清它們是不是同一層東西
Original Clash 通常指 Dreamacro 發起的早期 Clash 核心；Clash Meta 是在其設定思路上繼續擴展的分支；Mihomo 則是 Clash Meta 後來採用的專案名稱。
Clash Meta 與 Mihomo 指向同一專案的不同階段，不是兩套需要二選一的新核心。很多舊教學寫「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 的合理情境通常很窄：某套離線環境已經凍結，設定只使用它已知的能力，而且升級風險高於收益。即便如此，也應記錄二進位來源、版本和還原方法，不應繼續把舊核心暴露為公用網路控制服務。
- 普通桌面使用者
- 選內建 Mihomo 的持續維護用戶端，從一份乾淨訂閱開始。
- OpenWrt 使用者
- 同時確認外掛程式版本、Mihomo 核心架構和可用儲存，不只升級 LuCI 頁面。
- 伺服器端或容器部署
- 鎖定明確版本，先在測試目錄執行設定檢查，再替換執行實例。
- 遺留原版環境
- 保持隔離與可回滾，不將新協議訂閱直接推給舊核心。
遷移時先復現舊行為，再逐項啟用新能力
一份設定的安全遷移順序
保留舊設定
備份舊設定、核心版本和一組可重複存取的測試位址。
移除用戶端私有項
不要把舊 GUI 的視窗、快取或服務設定當成 Mihomo 設定複製。
先跑設定檢查
處理第一條 unknown field、類型或引用錯誤，避免一次刪掉整段。
固定相同節點
對照常用網站、內部網域和一個不讀取系統代理的應用。
再開 DNS 與 TUN 擴展
一次只改變一層，觀察連線記錄、規則命中和退出後的網路恢復。
遷移完成的判斷不是用戶端顯示「已連線」，而是舊環境中的關鍵流量在新核心裡命中預期規則，區域網路與內部網域仍能直連，系統代理或 TUN 關閉後網路能恢復。達成這些結果以後，再刪除舊二進位和舊服務。