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

「訂閱匯入成功，但節點連不上」和「用戶端沒有 TUN 開關」是不同層面的問題。圖形用戶端負責管理訂閱、系統匣選單、系統代理與設定合併；核心負責讀取最終設定、監聽連接埠、解析 DNS、比對規則並建立代理連線。設定檔則用來描述這些行為。要判斷 Clash 原版、Clash Meta 與 mihomo 的差異，應先確認目前執行的是哪個核心，而不是只看視窗上的應用程式名稱。

  • 用戶端版本：決定介面、服務安裝方式與設定覆寫機制。升級介面程式，不代表核心也會一併升級。
  • 核心版本：決定協定實作、欄位支援與路由能力。請以用戶端執行記錄或核心版本指令的輸出為準。
  • 訂閱格式：可能是完整的 Clash YAML，也可能只有節點清單，或是編碼後的分享連結集合。這三種格式不能直接互換。

原版、Meta 與 mihomo 的關係

Clash 原版：開源核心與 Premium 必須分開看

Clash 原版通常指 Dreamacro/Clash。過去除了開源核心，也有提供額外功能的 Premium 閉源版本。原專案已停止維護。討論原版是否支援 TUN、指令碼或某類規則時，必須先說明指的是哪種版本；不能把 Premium 的功能全算在開源版上，也不能假設兩個版本的設定完全相同。

例如，原版開源核心的 mixed-port 和 Premium 的 TUN 功能屬於不同層面的功能。前者提供本機 HTTP/SOCKS 代理入口，後者則涉及虛擬網卡接管。設定檔中出現 tun:，不代表任何名為 Clash 的執行檔都能處理它。

Clash Meta：從原版分支擴充功能

Clash Meta 是從 Clash 演進而來的分支，擴充了協定、DNS、規則與 TUN 等功能。「Meta 設定檔」通常表示設定使用了此分支支援的擴充欄位，而不是另一種完全不同的檔案格式。它仍廣泛採用 YAML，以及 proxies、proxy-groups、rules 這些熟悉的頂層結構。

mihomo：Meta 專案的後續名稱

Clash Meta 後來更名為 mihomo，兩者有直接的專案延續關係，並非毫無關聯的兩個核心。有些用戶端仍將核心選項標示為「Meta」，但實際執行的檔案已是 mihomo。反之，較早期的 Meta 執行檔也不會因為名稱相近，就自動支援後來新增的欄位。實際相容範圍取決於具體版本。

# 查看手動安裝的核心版本
mihomo -v

# 查看舊版 Clash 執行檔的版本
clash -v

上述指令須確保對應的執行檔已加入系統搜尋路徑。在 Windows PowerShell 中從目前目錄執行時，可使用 .\mihomo.exe -v。若用戶端內建核心，請優先查看啟動記錄中的版本資訊，避免查到其他全域安裝的程式。

協定支援：要看節點類型，也要看傳輸參數

協定名稱是第一個檢查項目，但不是全部。相同的 VMess 或 Trojan 節點，也可能使用 WebSocket、gRPC、TLS 等傳輸或加密設定。只有節點類型、傳輸方式與關鍵欄位都受到支援，才具備正常連線的條件。

功能 Clash 原版 mihomo 遷移檢查
Shadowsocks、VMess、Trojan 有相關實作，但受舊版限制 支援，具體參數隨版本演進 檢查加密方式、傳輸設定與 TLS 欄位
VLESS 與 REALITY 不支援 支援相應設定 檢查 UUID、flow、伺服器名稱及 REALITY 參數
Hysteria2、TUIC 不支援 支援相應協定 檢查版本、驗證欄位與 UDP 網路條件
TUN 接管 須區分開源版與 Premium 提供 TUN 功能 另行檢查管理員權限、服務與系統路由

「支援 Shadowsocks」不代表支援所有加密方式

較新的加密方式可能需要較新的核心。排查時應記錄 type、cipher、network 等欄位，不要只記下「SS 節點」。記錄中的「不支援的代理類型」較可能是核心功能問題；連線逾時則還要檢查伺服器、線路、UDP 是否可連通及驗證參數，兩者不應用同一種方式修復。

REALITY 不是獨立的代理類型

常見設定會以 type: vless 宣告節點，再透過 reality-opts 等欄位指定相關參數。直接把節點類型改成 reality，或只刪除不認得的欄位，都無法完成協定轉換。同樣地，把 type: hysteria2 改成 ss，也不會變成可用的 Shadowsocks 節點；伺服器端也必須提供對應協定。

設定相容性：基本結構相近，擴充欄位各有界線

從原版設定遷移至 mihomo，常見的基本結構通常可以保留；從 mihomo 設定退回原版，則容易遇到未知協定、未知規則或欄位語意差異。相容性有方向性，不是「都使用 YAML，所以可以互換」。即使解析器沒有報錯，也要繼續確認欄位是否確實生效。

先用最小設定確認連接埠與規則入口

以下是用來檢查基本結構的 mihomo 設定，不包含遠端節點。PROXY 群組只有 DIRECT，因此所有請求最後仍會直接連線。這份設定可用來驗證本機監聽與規則結構，不能用來測試代理線路品質。

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

proxies: []

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.org,PROXY
  - MATCH,DIRECT
  • mixed-port: 7890：在同一個本機連接埠接受 HTTP 與 SOCKS 代理請求，不代表系統代理已自動啟用。
  • allow-lan: false：不向區域網路開放代理入口。遷移時應維持原有的存取範圍，不要為了解決連線問題就直接開放監聽。
  • mode: rule：使用規則模式。切換至全域模式後，就不能再透過檢查某條網域規則是否命中來驗證分流。
  • MATCH,DIRECT：作為最後的預設規則。實際使用代理時，應依照自己的策略調整預設出口。

優先檢查容易因版本不同而出錯的欄位

設定區域核對項目常見現象
proxies協定類型、TLS 參數、傳輸選項載入失敗，或指定節點交握失敗
proxy-groups節點名稱、群組名稱及 provider 參照找不到代理，或策略群組為空
dns增強模式、解析器位址與分流策略節點可連線，但網域解析異常
tun網路堆疊、路由與 DNS 劫持設定核心啟動成功，但應用程式流量沒有進入
script 等舊版擴充功能確認是否為 Clash 原版 Premium 專屬設定不能直接套用到其他核心

規則、規則集與訂閱應分開檢查

基本規則主要檢查順序與目標名稱

DOMAIN、DOMAIN-SUFFIX、IP-CIDR、MATCH 都是常見的規則類型。通常會依序比對，前面過於寬泛的規則可能會遮蔽後續的細部規則。遷移後若所有流量都走同一個群組，先確認是否過早放入 MATCH，再檢查規則參照的群組名稱是否與 proxy-groups 完全一致。

mihomo 的邏輯規則、程序相關規則及擴充比對功能，不能一概認定原版也支援。程序識別還會受到平台、權限與流量接管方式影響。設定檢查通過，只能表示語法及參照符合目前核心的要求，無法保證每個平台都能識別出每個應用程式的程序。

RULE-SET 也取決於規則檔案格式

使用 RULE-SET 時，應一併檢查 rule-providers 中的名稱、behavior、format 與檔案內容。domain、ipcidr、classical 對規則內容各有不同要求。不能把完整的 DOMAIN-SUFFIX,example.org 規則隨意放進只接受網域項目的資料來源。

mihomo 的 MRS 規則集採用特定格式，也受核心版本與支援的行為類型範圍限制。把檔案副檔名從 .mrs 改成 .yaml，不會改變檔案編碼。退回舊版核心時，應取得目標核心支援的規則來源，而不是只改副檔名。

訂閱匯入成功，不代表相容性驗證已完成

  1. 確認訂閱回傳的是完整設定，還是供 proxy-providers 使用的節點集合。
  2. 確認訂閱服務提供的是通用 Clash 設定，還是明確支援 Meta/mihomo 擴充功能的設定。
  3. 確認用戶端是否透過覆寫、合併或指令碼變更連接埠、DNS、規則及策略群組。
  4. 以實際交由核心執行的最終設定為準，避免只檢查下載的原始檔案。

設定與記錄可能包含訂閱網址、節點密碼、UUID 或控制介面金鑰。回報問題時，只保留相關欄位結構與錯誤資訊，並先移除驗證資料。請勿在截圖或公開討論區貼出完整訂閱連結。

遷移步驟：先驗證設定，再檢查流量

建議保留舊環境作為回復點，每次只變更一個變數。不要同時更換用戶端與訂閱、啟用 TUN、重寫 DNS；否則即使問題消失，也無法確認真正原因。

  1. 記錄目前狀態：保存核心版本、用戶端版本、目前設定副本、監聽連接埠與策略群組選擇，並確認舊設定在目前網路下的實際表現。
  2. 檢查候選設定：使用準備執行的 mihomo 執行檔測試設定。遇到第一個解析錯誤時，先修正該錯誤，再繼續檢查。
  3. 單獨啟動新核心：停止舊核心，或為新核心使用不同連接埠。避免兩個程序同時占用 7890 或控制介面連接埠。
  4. 先測試明確指定的代理：關閉 TUN，只透過指定的 HTTP/SOCKS 連接埠測試一個確認可用的節點。
  5. 再測試規則與 DNS：分別連線至預期直連與預期走代理的目標，並從連線記錄核對命中規則、策略群組與最終節點。
  6. 最後啟用 TUN：安裝用戶端所需服務或授予權限，再檢查虛擬網卡、路由與 DNS 接管。
# 檢查候選設定；不會啟動常駐代理服務
mihomo -t -f ./candidate.yaml

# 透過 HTTP 代理入口發出請求
curl -I --proxy http://127.0.0.1:7890 https://example.org/

# 透過 SOCKS 入口發出請求，並由代理端解析目標網域
curl -I --proxy socks5h://127.0.0.1:7890 https://example.org/

在 Windows 上可使用 curl.exe 明確呼叫 curl，避免舊版 PowerShell 的同名別名造成干擾。測試時請將目標網址換成要驗證的網站，並檢查連線記錄中的出口；以上最小設定只會直接連線，無法證明遠端節點可用。

-t 檢查不等於完整的網路連線測試。外部規則、節點 provider、本機資料庫檔案與相對路徑仍須另外核對。命令列與用戶端執行時的工作目錄也可能不同；手動測試時找不到檔案，不一定代表 YAML 內容有誤。

常見問題與核心選擇

舊版 Clash YAML 可以直接交給 mihomo 使用嗎？

基本節點、策略群組與規則結構通常可以沿用，但應先執行設定檢查，再驗證 DNS、TUN 與外部資源。Clash 原版 Premium 的指令碼等專屬功能，不能預設 mihomo 也有相同實作。也請確認用戶端是否變更了最終執行設定。

用戶端顯示 Meta，一定要手動換成 mihomo 嗎？

不必只因名稱不同就更換。先確認實際核心版本與專案來源，介面標籤可能沿用舊名稱。建議優先使用用戶端提供的核心更新管道；手動替換還會涉及執行檔路徑、權限與用戶端介面相容性。

更換核心後網速會變快嗎？

核心可能影響協定支援、連線行為與資源使用量，但無法直接提升節點頻寬或改善電信業者線路。比較時應固定節點、目標網址、網路連線方式與測試時段，並同時觀察延遲、傳輸速度與失敗率；不要把單次測速差異當成普遍結論。

支援 TUN 的核心為什麼仍無法接管應用程式？

核心支援只是必要條件。還要檢查服務權限、自動路由、其他 VPN 的路由衝突，以及 DNS 請求是否走預期路徑。若明確指定代理時連線成功，但 TUN 失敗，應優先排查流量接管路徑，不要立刻更換節點或修改節點驗證參數。

選擇核心時應從設定需求倒推：先列出節點協定，再列出規則、DNS 與流量接管需求，最後選擇能提供相應 mihomo 版本及權限管理功能的用戶端。欄位說明可參閱技術參考；首次部署時，請先依照教學完成訂閱匯入與明確代理測試，再逐步加入規則與 TUN。