名稱關係：原版、Premium 與 Meta 分支

判斷 Clash 設定能否轉移，得先分清圖形用戶端與代理核心。用戶端負責管理訂閱、系統匣選單、權限要求及產生設定；核心則負責監聽連接埠、解析 DNS、比對規則並建立對外連線。同一個用戶端名稱，底下可能搭載不同版本的核心。介面能匯入 YAML，不代表核心能執行其中所有欄位。

「原版 Clash、Clash.Meta、mihomo 三代核心」方便搜尋，但不是嚴謹的專案系譜。Clash.Meta 是從 Clash 發展而來的分支；mihomo 是該分支後續採用的專案名稱，並非與 Clash.Meta 毫無關聯的第三套實作。Premium 則是原 Clash 體系中的增強版本，不能直接等同於 Meta。

  1. 原版 Clash：以 Dreamacro/clash 為代表的開源核心，奠定常見的 YAML 設定結構、規則模式、策略群組與控制介面。
  2. Clash Premium：原作者推出的閉源增強核心，過去提供 TUN、規則集、腳本等進階功能；不能只根據開源版的功能列表推斷 Premium 的能力。
  3. Clash.Meta：由 MetaCubeX 維護的衍生分支，擴充協定、DNS、規則與流量接管能力。
  4. mihomo：Meta 分支後續沿用的名稱。舊訂閱範本、用戶端選項和教學中仍可能看到 Meta；判斷相容性時，應以實際核心版本為準。

從時間脈絡來看，原版 Clash 與 Premium 原有的發布管道在 2023 年底出現重大變化；Meta 分支持續發展，並於 2024 年改用 mihomo 這個名稱。舊安裝檔即使仍能啟動，也不會因此自動支援後續新增的協定與設定欄位。

功能比較：協定、規則與設定限制

以下比較的是功能發展方向，不代表涵蓋所有歷史版本的具體支援情況。尤其 mihomo 的新協定和新欄位會隨版本逐步加入。訂閱中即使出現某個 type，仍須確認本機核心是否支援該類型及其相關參數。

項目 原版開源 Clash Clash Premium Clash.Meta / mihomo
常見基礎協定 支援 Shadowsocks、VMess、Trojan 等；可用參數視版本而定 延續原版的基礎協定支援 保留基礎協定，並持續擴充實作
VLESS、REALITY、Hysteria2、TUIC 不以支援這些新協定或功能為目標 不能視為 Meta 擴充協定的替代實作 視相應版本而定；還須確認傳輸層與驗證參數
基礎分流 支援網域、IP、GEOIP、MATCH 等常見規則 支援基本規則，並提供增強功能 保留基本規則，並擴充邏輯比對等功能
規則集與腳本 不能比照 Premium 的規則集與腳本功能 支援規則集及特定腳本機制 支援規則集；不應假設相容於 Premium 腳本執行環境
TUN 不具備 Premium 內建的 TUN 功能 提供 TUN，但受作業系統與發布版本限制 提供 TUN；實際支援的協定堆疊與路由選項須參考對應版本

協定名稱相同，參數也不一定完全一致

例如，VMess 節點可能用到 WebSocket、TLS、服務名稱或請求標頭；VLESS 也可能使用 REALITY 和特定流量控制參數。REALITY 是相關連線的安全握手功能，不應當成可任意填入 type 的獨立節點協定。轉移時若只改節點類型，卻保留不相容的傳輸參數，往往能通過部分解析，最後仍會在握手階段失敗。

  • 解析失敗：優先檢查協定類型、欄位拼字、YAML 縮排及欄位資料型態。
  • 握手失敗：確認伺服器位址、連接埠、憑證、TLS 服務名稱、傳輸方式及伺服器端設定。
  • 連線逾時：接著檢查網路是否可連通、是否支援 UDP、上游是否封鎖，以及本機防火牆；別只歸因於核心名稱。

設定相容性：哪些可以保留，哪些需要重寫

將原版設定轉移至 mihomo 時，proxies、proxy-groups、rules 等基礎結構通常能延續使用。但「欄位仍存在」不代表「所有預設值與執行結果都相同」。協定參數、規則資料、DNS、TUN 和用戶端覆寫設定都應分別檢查。

基本規則：先確認策略名稱與比對順序

proxy-groups:
  - name: 出站選擇
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,出站選擇
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,出站選擇

這段設定用來檢查結構，不包含遠端代理節點。「出站選擇」目前只有 DIRECT，因此流量命中它時仍會直接連線。轉移實際設定時，必須將已驗證的節點名稱加入策略群組；規則引用的名稱必須與策略群組或節點名稱完全一致。

規則通常由上而下比對，MATCH 應放在最後。範例中的 no-resolve 表示不為這條 IP 規則主動觸發網域解析，並非關閉所有 DNS，也不會讓網域規則失效。如果連線尚無可用的目標 IP，這條規則可能不會命中。

規則集：資料格式比副檔名更重要

轉移 rule-providers 時，也要確認 type、behavior、format、path 和更新網址。behavior: domain、ipcidr、classical 對資料內容各有不同要求。將包含完整規則的 classical 資料當成純網域清單使用，不會因為檔名都是 YAML 就自動相容。

同樣地，別把 mihomo 支援的規則集格式直接交給舊核心。例如，二進位規則集需要有相應的實作支援，改副檔名並不能完成轉換。遠端規則集即使下載成功，也仍須確認解析記錄與實際規則命中情況。

DNS 與 TUN：欄位相似，流量接管範圍不同

系統代理通常只會影響遵循系統代理設定的應用程式。TUN 透過虛擬網路介面與路由規則接管符合條件的 IP 流量，適合處理不會讀取系統代理設定的程式，但不代表所有流量都一定會經過遠端代理。流量遭接管後，仍須經過規則比對，可能會以 DIRECT 直連、拒絕連線或使用代理等方式處理。

先確認 DNS，再啟用虛擬網卡

轉移時建議先關閉 TUN，使用本機代理連接埠驗證節點與分流，再加入 DNS 劫持和路由接管。這樣可以區分「代理連線失敗」與「系統 DNS 未進入核心」這兩類問題。以下是 mihomo 的設定片段，請合併至現有設定，不要重複定義頂層 dns 或 tun。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

tun:
  enable: false
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
  • 127.0.0.1:1053 是本機 DNS 監聽位址；只啟用監聽，不會自動讓所有應用程式改用這個位址。
  • 198.18.0.1/16 是範例用的 fake-ip 位址池，用來提供映射用的合成位址，不是遠端代理伺服器位址。
  • enable: false 用來先驗證非 TUN 路徑。權限和路由準備就緒後，再改成 true。
  • dns-hijack 處理的是符合接管條件的 DNS 流量；應用程式自行建立的 DoH 或 DoT 連線，不能一概視為一般的 53 埠查詢。

系統差異：權限與路由都要檢查

Windows 通常需要用戶端服務模式或相應的提升權限；macOS 可能透過特權輔助程式或特定應用程式的網路接管機制實作；Linux 則須檢查 TUN 裝置與網路管理權限。Android 用戶端通常透過系統 VPN 介面接管流量，其介面設定不一定能與桌面版原始 YAML 一一對應。

若同時執行其他 VPN、虛擬機網路或企業安全軟體，預設路由與 DNS 設定可能互相覆蓋。關閉 TUN 後連線恢復，只能說明問題集中在流量接管路徑，不能直接證明某個協定不相容。應記錄預設出口、DNS 位址、路由變化和記錄時間，再逐項排查。

轉移驗證：設定檢查、連接埠測試與還原

可靠的轉移流程需要可重現的步驟。別同時升級核心、替換訂閱、修改 DNS 又啟用 TUN，否則出問題時很難找出原因。保留舊設定副本，並在新用戶端使用獨立設定進行驗證。

  1. 記錄基準狀態：保存目前可用的節點、策略選擇、DNS 模式和監聽連接埠，並記下是否啟用系統代理與 TUN。
  2. 確認目標核心：確認使用的是 mihomo 還是舊版 Meta 執行檔，並查看實際版本；不能只看訂閱範本標題。
  3. 檢查設定：先執行設定測試，再啟動監聽。測試通過只代表設定可以載入，不代表節點握手和規則更新都已成功。
  4. 驗證單一連線：固定使用一個節點，以相同目標位址比較直連與明確指定代理的結果，先不要使用自動測速群組。
  5. 逐步恢復其他功能：依序恢復規則集、DNS、TUN 和開機啟動，每一步都留意記錄與連線紀錄。
mihomo -v
mihomo -t -f config.yaml

如果用戶端使用的混合連接埠是 7890，可以用以下指令區分明確指定代理與直連路徑。實際連接埠應以執行中的設定為準；7890 只是常見範例，不是所有用戶端的固定預設值。

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://clashgrand.com/
curl --noproxy "*" --connect-timeout 10 --max-time 20 -I https://clashgrand.com/

這兩個指令不能用來實測速度，也不能只靠狀態碼判斷出口。請搭配用戶端的連線紀錄，確認目標連線命中哪條規則、使用哪個策略及最後採用的節點。如果策略群組仍選擇 DIRECT，即使明確連到本機代理連接埠，也可能直接連線至目標。

常見問題與優先檢查項目

現象 優先檢查項目 處理方式
未知的代理類型或欄位錯誤 實際核心、訂閱目標格式、參數資料型態 選用對應 mihomo 的設定，或升級至支援該欄位的版本
連接埠繫結失敗 舊用戶端是否仍占用 7890 或本機 DNS 連接埠 結束舊程序，或修改連接埠並同步更新應用程式設定
看得到訂閱節點，但無法連線 用戶端最後產生的節點參數與握手記錄 確認傳輸參數、憑證和伺服器協定，別反覆切換模式
手動修改設定後，重啟就還原 訂閱更新、設定合併、用戶端覆寫 修改會保留的覆寫或合併設定，不要只改暫存的執行檔
啟用 TUN 後，區域網路異常 內網路由、DNS、其他 VPN 與流量接管範圍 先關閉 TUN 進行驗證，再設定適當的路由排除規則

還原時，先關閉新用戶端的系統代理與 TUN，再結束新程序，接著恢復舊用戶端及原有設定。不要讓兩套核心同時搶用監聽連接埠和系統路由。控制介面也應優先繫結至回環位址；若確實需要遠端管理，請另外設定驗證方式與存取範圍。

選型結論：依設定依賴選擇核心

  • 只有基本節點與常見分流規則：通常可以直接轉移，重點檢查策略名稱、DNS 行為及用戶端覆寫。
  • 使用 VLESS、REALITY、Hysteria2 或 TUIC：選擇明確支援相應參數的 mihomo 版本，並逐項確認設定與伺服器端一致。
  • 依賴 Premium 腳本：先改寫並驗證腳本行為，不要以替換執行檔當成完整轉移。
  • 需要 TUN：同時評估用戶端權限管理、作業系統支援和路由衝突，不能只比較核心功能名稱。

新部署時，建議優先選擇仍持續維護、且能清楚顯示核心資訊的用戶端，再依實際訂閱協定決定設定格式。舊環境則應先建立可重現的測試流程與還原方案。核心選型的重點不在名稱是否更新，而在節點能否完成握手、規則能否命中、DNS 能否正常解析，以及流量接管範圍是否符合預期。