先看結論：Meta 與 mihomo 是同一個專案的前後名稱

挑選新設定檔時，請先確認用戶端實際執行的核心，而不是只看用戶端名稱。Clash 原版、Clash Premium 與 mihomo 的功能範圍各不相同；Clash Meta 後來更名為 mihomo，並非需要另外安裝的第四種獨立核心。舊教學所說的「Meta 設定檔」通常指該專案的設定體系，但仍須依實際版本確認支援的欄位。

將舊設定檔遷移至 mihomo 時，基本節點、策略群組與常見網域規則通常可以沿用；新增協定、Premium 指令碼、DNS、TUN 與規則集格式則須個別確認。反向遷移的限制更多：mihomo 能解析的設定檔，不代表 Clash 原版也能執行。

專案關係：Clash 原版、Premium、Meta 與 mihomo

Clash 原版與 Clash Premium

Clash 原版通常指 Dreamacro/clash 的開源核心；Clash Premium 則是原專案推出的閉源增強核心分支，兩者的功能不能簡單視為相同。過去，TUN、規則提供器與指令碼規則等功能，是區分 Premium 與原版開源核心的重要線索。原專案於 2023 年停止維護後，舊版執行檔仍可能運作，但不適合再作為持續取得新協定支援的基礎。

Clash Meta 與 mihomo

Clash Meta 從 Clash 生態系發展而來，擴充了協定與路由功能，之後專案更名為 mihomo。資料夾、訂閱說明或舊版介面仍保留 Meta 字樣，不代表核心一定已過時；應以實際執行檔的版本資訊及相應的發行說明為準。

  • Clash 原版：了解基礎 YAML、HTTP/SOCKS 入站與規則分流的歷史起點。
  • Clash Premium：舊設定檔中進階規則、TUN 與指令碼功能的來源之一。
  • Clash Meta / mihomo：同一專案的前後名稱，支援更多協定與設定擴充。

即使用戶端支援切換核心，也不代表可以任意替換執行檔。核心啟動參數、控制介面、服務權限與安裝路徑都可能由用戶端管理。建議優先使用用戶端提供的核心更新方式，並確認其明確支援的核心類型。

功能差異：分別比較協定、規則集與 TUN

歷史功能差異與遷移檢查方向
檢查項目 Clash 原版開源核心 Clash Premium mihomo
常見代理協定 支援 SS、VMess、Trojan 等協定，但受舊版實作限制 以歷史版本的功能為準，不應假設支援新協定 擴充支援 VLESS、Hysteria2、TUIC 等協定
基本規則 支援網域、IP 網段、GEOIP 與最終比對等規則 支援基本規則及增強功能 保留常見規則，並提供更多比對功能
rule-providers 不能直接套用 Premium 的功能 支援，但須確認規則行為與格式 支援，擴充格式須確認目標版本
TUN 接入 不具備 Premium 內建的 TUN 功能 支援，視平台與權限而定 支援，實際網路堆疊與欄位依版本而異
Premium script 不支援 歷史專屬功能 不能直接視為相容，遷移時須改寫

即使協定名稱相同，也要確認傳輸與加密欄位

節點標示為 VMess，不代表連線參數已完整。還需確認 UUID、TLS、伺服器名稱、WebSocket 路徑與要求標頭等設定。使用 VLESS 時，也要確認伺服器端採用的傳輸方式、安全層及相關參數。只修改 type，並不會將一種協定轉換成另一種。

Hysteria2 與 TUIC 需要 UDP 網路環境。核心能解析節點，但在目前網路環境下持續逾時時，應進一步檢查 UDP 連線、伺服器連接埠與憑證參數，而不是直接歸咎於設定格式。支援某個協定只是必要條件，不代表線路一定連得上。

設定檔相容性：先保留基本結構，再處理擴充欄位

典型設定檔包含 proxies、proxy-groups、rules，也可能包含 proxy-providers 與 rule-providers。這些名稱看起來相近，功能卻不同：前者可從外部載入節點，後者則載入分流規則，兩者不能使用相同的訂閱網址。

規則順序與策略名稱都要一併檢查

以下片段用來說明 mihomo 常見的設定結構。範例將手動選擇群組指向 DIRECT，不會產生代理出口；實際使用時，應保留直連選項，並加入有效節點或正確的節點提供器參照。

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

proxy-groups:
  - name: 手動選擇
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,手動選擇
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,手動選擇
  • mixed-port: 7890 是 HTTP 與 SOCKS 共用的監聽連接埠範例，不代表所有用戶端都預設使用此設定。
  • allow-lan: false 適合先在本機測試；需要讓區域網路裝置連線時，再檢查監聽位址與防火牆範圍。
  • 規則會依序比對。若將 MATCH 放在前面，後續規則就無法發揮預期作用。
  • 規則中的「手動選擇」必須與策略群組名稱完全一致，包括空格與大小寫。
  • no-resolve 表示該 IP 規則不會主動觸發網域解析，不等於關閉整個核心的 DNS。

Premium 指令碼與新規則集格式須個別遷移

舊設定檔中的 script 不能直接視為 mihomo 相容項目。應將指令碼實際執行的網域、IP 或程序判斷拆解，改寫成目標核心支援的規則；無法等效表達的邏輯則須重新設計。遷移後不只要通過語法檢查，也要確認具代表性的要求是否命中預期規則。

規則提供器也要確認 behavior 與檔案內容是否一致。domain、ipcidr、classical 分別對應不同的規則內容；YAML、純文字與 mihomo 的 MRS 格式，不能只改副檔名就互相轉換。MRS 等擴充格式也受規則行為與核心版本限制，舊版核心未必能讀取。

DNS 與 TUN：最容易發生「能啟動卻不能用」的部分

DNS 設定須區分解析入口與上游伺服器

DNS 監聽位址、上游伺服器、Fake-IP 模式與網域例外清單各自處理不同問題。看到 enhanced-mode: fake-ip，只能確認使用了 Fake-IP 機制，不能據此判斷系統要求一定會進入核心。系統仍可能使用其他 DNS 路徑，應用程式也可能啟用自己的加密 DNS。

  • 遷移前先備份原有的 nameserver、fallback、fake-ip-filter 及相關策略。
  • 若只有本機裝置名稱或內網網域異常，請先檢查區域網路的解析路徑與 Fake-IP 例外，不要一次更換所有上游伺服器。
  • 若記錄顯示上游網域解析失敗，請檢查用來解析 DNS 伺服器網域名稱的引導解析設定。
  • 變更設定後可重新啟動相關應用程式；系統 DNS 快取與應用程式快取不一定會在核心重新載入時同步清除。

TUN 負責接管流量，不會修正節點參數

TUN 透過虛擬網路介面接收流量，通常需要管理員權限或相應的網路權限。Windows 的服務模式、Linux 的路由與權限，以及 macOS 的網路延伸功能或虛擬介面處理方式，應依各用戶端的實作分別確認。系統代理正常運作後再測試 TUN，較容易縮小問題範圍。

tun.auto-route、tun.auto-detect-interface 與 tun.dns-hijack 分別涉及路由、出口介面偵測與 DNS 接入，並非可以互相取代的「增強開關」。範例中的 any:53 用於比對 DNS 連接埠，不代表能攔截所有應用程式內的加密 DNS。與其他 VPN 同時執行時，也須檢查路由優先順序與虛擬網卡衝突。

將舊設定檔遷移至 mihomo：六個驗證步驟

  1. 備份原始設定檔。備份訂閱來源、本機覆寫、規則集與目前使用的設定檔。圖形化用戶端匯出的檔案可能已合併覆寫設定，請同時保留可編輯的來源檔案。
  2. 記錄核心資訊。在用戶端的核心資訊或記錄中確認實際版本；獨立部署時可執行 mihomo -v，並記下輸出內容與系統架構。
  3. 先檢查語法。獨立執行時可使用 mihomo -t -f config.yaml。相對路徑資源應在與正式執行相同的工作環境中檢查，以免將路徑錯誤誤判為格式不相容。
  4. 先測試本機代理連接埠。確認設定實際監聽 7890 後，再執行下方指令。若使用的連接埠不同，請同步修改指令。
  5. 確認規則命中情況。在用戶端的連線記錄中檢查目標網域、命中規則、策略群組與最終出口。要求成功只代表這次連線可用，不能證明所有分流都正確。
  6. 逐項恢復擴充功能。依序加入規則提供器、DNS 覆寫、TUN 與開機啟動。每個步驟都查看記錄，並確認重新載入設定後仍然有效。
mihomo -v
mihomo -t -f config.yaml
curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com

上方的 10 秒連線逾時與 20 秒總逾時是診斷參數，不是速度指標。在 Windows PowerShell 中，可明確使用 curl.exe 呼叫系統中的 curl 程式。測試前請確認目前沒有用戶端正在使用 7890，以免同時啟動第二個核心而造成連接埠衝突。

常見遷移問題：依錯誤位置縮小範圍

訂閱可以匯入，節點卻全部無法使用

先確認訂閱內容是完整的 Clash 設定檔、節點提供器資料，還是其他用戶端的分享連結集合。圖形化用戶端顯示「匯入成功」，可能只代表已儲存網址。接著檢查下載結果、節點解析記錄與協定支援情況。請勿將含有憑證的訂閱網址貼到公開的轉換服務或問題討論串。

設定檢查通過，實際規則卻未生效

確認執行模式是否為 rule，以及目前生效的檔案是否就是剛才修改的檔案。用戶端可能在更新訂閱後重新產生設定檔，也可能透過覆寫插入優先順序更高的規則。若要保留變更，請使用用戶端支援的覆寫或合併機制，而非只修改產生後的檔案。

啟動時顯示連接埠已被占用

確認是否同時執行兩個用戶端，或背景服務仍留有舊核心程序。代理入站連接埠與控制介面連接埠用途不同：例如 7890 可作為本機代理連接埠，9090 可作為控制介面連接埠，但實際設定仍須以目前的設定檔為準。變更代理連接埠後，也要同步調整系統代理、終端機環境變數與應用程式中的手動代理位址。

該繼續使用舊核心，還是改用 mihomo？

需要 Hysteria2、TUIC、VLESS 或較新的規則與 DNS 功能時，請選擇明確支援這些功能的 mihomo 用戶端，並確認內含的核心版本。若現有環境依賴 Premium 指令碼或特定舊版行為，請先在獨立設定檔中完成遷移測試，再替換正式使用環境。用戶端安裝檔可參考選型指南，基本設定步驟請見使用說明。

最終判斷標準是設定檔能否解析、節點能否連線、規則是否依預期命中，以及系統代理或 TUN 的接管範圍是否正確。名稱中有「Meta」或「mihomo」，都不能取代這四項檢查。