Clash 核心相容性比較

先分清用戶端、核心與設定

Clash 用戶端的名稱不等於實際功能。視窗介面負責匯入訂閱、管理設定及設定系統代理；核心則負責解析節點、監聽連接埠、比對規則與建立連線。同一款用戶端的不同發行版本，可能搭載不同版本的核心。要判斷訂閱能否使用，首先應確認目前執行的核心，而不是桌面捷徑上的名稱。

本文所稱的「原版」是早期的 Clash 開源核心；Premium 則是當時另外提供的閉源增強核心，兩者不可混為一談。原版開源專案與 Premium 原有的公開發行管道於 2023 年停止維護後，舊程式或許仍能啟動，但不代表已取得後續協定更新或系統相容性支援。

依序檢查三個層面

1. 用戶端層：能否儲存自訂規則、更新訂閱，以及取得 TUN 所需權限。
2. 核心層：是否能辨識節點的 type、傳輸選項與 DNS 欄位。
3. 執行設定層：介面操作、訂閱轉換與設定合併後，最終傳給核心的 YAML 是否符合預期。

例如，編輯器中儲存了 mixed-port: 7890，用戶端的連接埠覆寫仍可能將它改成其他值。排查時應同時查看用戶端設定與執行中的設定，不能只檢查下載到本機的訂閱原始內容。

原版、Premium 與 mihomo 比較

下表比較的是各核心系列的功能範圍，並非對任何歷史版本的保證。尤其是 mihomo，新增協定、欄位與規則格式都有版本要求；使用 mihomo 不代表舊版執行檔支援所有目前的設定。

Premium 這個名稱不代表它現在的功能仍多於 mihomo，也不表示使用時必須購買訂閱。核心分支、用戶端發行方式與代理服務訂閱是三件不同的事。訂閱能否連上特定伺服器，還取決於伺服器參數、驗證資訊、網路路徑與憑證設定。

檢查協定支援時，細節要確認到個別參數

能辨識協定名稱，不代表連線一定成功

節點出現 type: vless、type: hysteria2 或 type: tuic 時，應選用明確支援這些類型的 mihomo 版本。把節點的類型文字改成 vmess 或 trojan 並不能轉換協定；伺服器端也必須提供相應協定的連線入口。

即使兩個核心都能辨識 type: ss，支援的加密方法也可能不同。不能只憑「支援 Shadowsocks」就判斷是否相容 Shadowsocks 2022 系列加密方法。同樣地，VLESS 的 REALITY 參數、傳輸方式與指紋設定，都必須與伺服器端一致，且受所用核心版本支援。

• 解析時出現未知類型：優先檢查核心分支、版本與訂閱格式。
• 提示缺少欄位或參數無效：對照該版本的設定文件，檢查欄位名稱、層級與資料類型。
• 設定載入成功但交握失敗：檢查伺服器位址、連接埠、驗證資訊、SNI 與憑證相關參數，而非繼續調整規則順序。
• 網頁可正常瀏覽，但 UDP 應用程式失敗：檢查節點、伺服器端與本機流量接管路徑是否都支援 UDP。

訂閱格式也有相容性限制

「Clash 訂閱」並非精確的版本聲明。服務商可能提供適用於原版的精簡設定，也可能提供含 mihomo 擴充功能的設定。若匯入前經過訂閱轉換，轉換器也可能刪除無法辨識的節點或欄位。發現節點數量減少時，應比對原始回應、轉換結果與用戶端執行中的設定，確認內容在哪個步驟發生變化。

設定相容性：從基礎欄位到擴充欄位

遷移時可先保留監聽連接埠、基本策略組與常用規則，再逐項加入擴充功能。以下是用來確認 mihomo 能否載入的最小設定，不含遠端代理節點；「出口選擇」只有直連選項，無法用來驗證代理伺服器是否可用。

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,出口選擇

7890 是本例選用的 HTTP 與 SOCKS 共用本機連接埠，並非所有用戶端的固定預設值。allow-lan: false 用來限制區域網路存取。匯入前若已有其他程式監聽這個連接埠，應更換連接埠或停止衝突的程序。不要同時啟動兩個使用相同監聽連接埠的核心。

規則順序與策略引用仍然重要

常見規則會由上而下依序比對；前面的規則命中後，後續規則便不會再決定該連線的出口。MATCH 應放在最後作為兜底規則。規則末尾引用的策略名稱必須確實存在，且字元完全一致。遷移核心不會自動修正拼錯的策略組名稱。

no-resolve 常用於 IP 類規則，表示比對這條規則時不主動觸發網域解析，並不代表整個請求永遠不會使用 DNS。加入 rule-providers 時，也要確認 behavior、format 與規則檔案內容彼此相符。不能把純網域清單直接當成包含完整規則語句的 classical 規則集。

不要直接沿用 Premium 腳本

Premium 的腳本功能不能視為 mihomo 通用的相容介面。舊設定若含有 script，應先確認所用核心是否支援相同機制，再考慮改寫為規則集、邏輯規則或策略組。YAML 可成功讀取，不代表所有未知欄位都會生效；部分欄位可能遭到忽略，因此仍須透過實際連線的命中紀錄驗證。

DNS 與 TUN 是兩項獨立檢查

Fake-IP、DNS 分流與 TUN 經常同時出現在教學中，但各自負責不同環節。DNS 模組處理網域解析與對應；TUN 則透過虛擬網卡與路由接管流量。啟用 TUN 不代表所有 DNS 查詢都會依預期處理，也不能只憑 DNS 測試頁面顯示的服務商名稱來判斷核心是否相容。

遷移 DNS 設定時檢查四個項目

1. 監聽位址：例如 127.0.0.1:1053 僅對本機開放；如果系統仍查詢其他位址，核心的 DNS 不一定會參與。
2. 增強模式：確認 enhanced-mode 使用的是 fake-ip 還是 redir-host，不要只沿用舊介面的開關狀態。
3. 解析分流：檢查 nameserver、fallback、nameserver-policy 的實際語意；不能簡單將 fallback 理解為主要解析器逾時後使用的備用位址。
4. 額外解析入口：瀏覽器的安全 DNS、應用程式內建的 DoH，以及路由器轉送，都可能繞過原先預想的解析路徑。

啟用 TUN 不代表所有流量都會經過代理

mihomo 的 tun.enable、auto-route 與 dns-hijack 各有用途：啟用虛擬網卡、設定路由，以及攔截指定的 DNS 流量。最終出口仍由規則決定，命中 DIRECT 的連線會直接連線。權限不足、路由衝突或同時執行 VPN，也可能導致部分流量未被接管。

不要為了配合舊教學而直接照搬 stack 的值。可用的堆疊與行為會受核心版本和作業系統影響。建議先使用用戶端為目前平台提供的預設設定，再針對特定問題調整。測試時先關閉 TUN，以系統代理確認節點正常後再啟用 TUN，可減少同時變動的因素。

如何驗證遷移前後的執行結果

遷移時應使用可還原的設定副本。先記錄舊核心名稱、版本、監聽連接埠與訂閱更新時間，再複製設定進行測試。命令列使用者可對實際執行檔進行以下檢查；桌面用戶端使用者則應查看核心記錄，確認測試的是用戶端實際啟動的核心。

mihomo -v
mihomo -t -f ./config.yaml

第一個指令用來查看版本，第二個則檢查設定能否解析與載入。檢查通過只代表靜態設定符合相應條件，不代表遠端節點交握成功、DNS 路徑正確或 TUN 路由已生效。若設定引用遠端規則或節點提供器，也應確認相關資源可以取得。

若發生問題，請依「載入失敗 → 本機監聽 → 節點連線 → 規則命中 → DNS/TUN」的順序排查。一次只修改一項變數。更多通用檢查方式請參閱故障排除；第一次匯入設定，可先依照設定教學完成基本連線。

用戶端選擇的最終判斷

• 新部署：優先選擇仍有維護、且明確標示所用 mihomo 核心版本的用戶端，再確認作業系統與處理器架構。
• 已有穩定的舊環境：先保留可用的設定副本，再檢查新訂閱是否加入舊核心不支援的協定，避免直接覆寫所有設定。
• 依賴 TUN：除了核心功能，也要確認用戶端能取得所需權限、管理服務，並在結束時清除路由。
• 依賴複雜規則：著重檢查規則提供器、邏輯比對與持續保存覆寫設定的方式，並確認更新訂閱不會移除本機修改。

選擇時應以可觀察的事實為依據：實際執行的核心版本、設定檢查結果、記錄中的協定錯誤，以及連線記錄內的規則與出口。Meta 與 mihomo 的名稱差異並非主要障礙；遷移時更常見的相容性問題，是舊版執行檔、擴充欄位與用戶端覆寫彼此不一致。