Clash 原版核心、Clash.Meta 與 mihomo 差異：功能與設定相容性整理

先釐清用戶端、核心與訂閱設定

看到用戶端支援「Clash 設定」，不能直接認定它支援所有 Clash.Meta 或 mihomo 欄位。用戶端負責視窗介面、訂閱管理、系統代理開關與服務安裝；核心負責監聽連接埠、解析網域名稱、比對規則並建立代理連線；訂閱則提供節點或完整設定。這三個部分各自更新，遇到「訂閱匯入成功，節點卻無法啟動」時，問題可能出在核心功能，而不是匯入按鈕。

例如，圖形介面可能沿用 Clash 的產品名稱，底層使用的卻是 mihomo。反過來說，能匯入 YAML 的舊用戶端，也可能仍搭載早期核心。判斷相容性時，應先查看核心名稱與版本，再檢查設定中的協定和功能欄位，不要只看應用程式名稱。

用戶端版本：通常可在「設定」→「關於」中查看，用來確認介面與服務元件的版本。
核心版本：可在用戶端的核心資訊或執行記錄開頭查看；若直接執行二進位檔，可使用 mihomo -v。
實際載入的設定：查看用戶端提供的執行設定預覽，或啟動記錄中的設定檔路徑。訂閱原始內容不一定等於最後載入的檔案。

Clash 原版、Clash.Meta 與 mihomo 的演進脈絡

原版 Clash 還要區分開源版本與 Premium

過去的原版 Clash 包含開源核心與 Premium 分支，兩者不能用同一份功能清單來理解：TUN、規則集提供者等功能，曾依 Premium 的功能範圍而有所不同。舊教學若只寫「Clash 支援 TUN」，卻沒註明是哪個分支，使用開源版本的讀者就可能找不到相應功能。

原版相關專案於 2023 年停止公開維護後，舊版二進位檔仍可能在既有系統上執行，但不代表它能辨識後來新增的協定與設定選項。新設定能否載入，必須以該二進位檔實際支援的功能為準。

Clash.Meta 是分支，mihomo 是後續名稱

Clash.Meta 以 Clash 為基礎擴充協定、DNS 與路由功能，之後專案更名為 mihomo。因此，Clash.Meta 與 mihomo 並非兩套完全獨立、需要逐行互譯的設定系統。許多舊教學、訂閱按鈕和檔名仍使用 Meta 字樣，實際指向的可能已是 mihomo 設定。

不過，「屬於同一條演進路線」不代表所有歷史版本的功能都相同。早期 Meta 二進位檔仍可能不支援較新的 mihomo 選項。遇到欄位錯誤時，應對照目前版本的文件與發行說明，而不是直接認定「所有 Meta 版本都支援」。

項目	主要用途	遷移時的注意事項
原版開源 Clash	基礎代理、策略群組與規則分流	不可預設支援 Premium 或 Meta 擴充功能
Clash Premium	原版系統的擴充分支	腳本模式等功能不能直接視為與 mihomo 等效
Clash.Meta	擴充協定與路由功能的分支	名稱仍廣泛沿用，實際功能取決於版本
mihomo	Meta 後續使用的專案名稱	確認新欄位、用戶端接管方式與實際執行設定

協定、規則與 TUN 的實際差異

節點協定支援度決定訂閱能否正常使用

原版常見設定使用 Shadowsocks、VMess、Trojan、SOCKS5 或 HTTP 等代理類型。mihomo 在此基礎上支援 VLESS、Hysteria2、TUIC 等擴充協定，但各協定的傳輸方式、驗證參數與具體選項仍有版本要求。不要把「支援某協定」解讀成「支援該協定所有實作的全部參數」。

舊版核心遇到 type: hysteria2 這類不認得的代理類型時，通常無法正常載入該節點；部分用戶端會在轉換或匯入階段就先篩除節點。若訂閱更新後節點數從 20 個變成 0 個，請先查看匯入記錄和協定類型，再檢查服務是否到期，不必立刻調整 DNS。

基本規則通常可沿用，擴充規則則需確認

DOMAIN、DOMAIN-SUFFIX、IP-CIDR、MATCH 這類基本規則通常有良好的相容性。較複雜的邏輯規則、程序比對與規則集格式，則要同時確認核心支援度、作業系統功能及資料檔案是否可用。規則仍是由上而下比對；若把最後的 MATCH 放在前面，後續規則就不會生效。

例如，以下是一段獨立的規則片段，並非完整設定。它假設現有設定中已有名為「代理選擇」的策略群組；名稱必須完全相同，否則即使 YAML 格式正確，也會出現參照錯誤。

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

這裡的 no-resolve 表示該 IP 規則不會主動觸發網域解析，不代表整個核心都關閉 DNS。192.168.0.0/16 也只涵蓋一個私有網路網段，這段範例並非完整的區域網路略過清單。

TUN 是流量接管方式，不是節點協定

系統代理通常只影響遵循系統代理設定的應用程式；TUN 則透過虛擬網路介面接管流量，涵蓋範圍更廣，但需要權限、路由與 DNS 相互配合。原版 Premium 與 mihomo 都可能使用 TUN，不能只憑介面上有「TUN」開關，就判斷兩者使用相同核心。

遷移時，不要把舊用戶端的虛擬網卡、背景服務或路由設定視為新用戶端的必要項目。請先結束舊用戶端並關閉其流量接管，再由新用戶端安裝或啟用自己的服務。兩套 TUN 同時執行，可能造成預設路由競爭、DNS 迴圈或區域網路連線異常。

舊設定遷移至 mihomo：哪些可保留，哪些要重新確認

不建議直接貼上整份舊設定，然後一次開啟所有功能。請先備份，再建立最小可用基準：節點可連線、策略群組可選擇、規則比對正確，最後才加入 DNS 強化與 TUN。如此一來，每個步驟都能對應到明確的故障範圍。

欄位或內容	處理建議	具體檢查項目
`proxies`、`proxy-groups`	先保留基本架構	協定選項有效，策略群組參照名稱存在
`rules`	保留原有順序，再逐項驗證	目標策略存在，最後一條規則為兜底規則
`rule-providers`	確認來源與格式	`behavior` 與實際規則內容一致
`dns`、`tun`	依新環境重新檢查	連接埠、網段、權限與路由沒有衝突
`script`	不要直接照搬	Premium 腳本分流需改寫為支援的規則邏輯
`external-controller`、`secret`	檢查用戶端的流量接管設定	控制連接埠沒有衝突，存取金鑰不會隨設定公開

連接埠與本機路徑最容易被忽略

例如，舊設定使用 mixed-port: 7890，新用戶端也監聽 7890，若舊程序尚未結束，就可能發生連接埠占用。若新用戶端改用 7897，終端機的代理環境變數仍指向 127.0.0.1:7890，終端機請求就會繼續連到舊連接埠。這些數字只是常見設定範例，並非所有用戶端的固定預設值。

規則提供者與代理提供者中的相對 path，通常要搭配核心的工作目錄來理解。將 YAML 移至其他目錄，不代表對應的快取檔案也會一併移動。請讓新用戶端重新更新提供者，並從記錄確認檔案已成功寫入，不要只看介面上仍顯示舊節點名稱。

訂閱更新可能讓手動修改「消失」

有些用戶端更新訂閱時會重建設定，手動修改的 dns 或 rules 可能隨即被覆寫。建議優先使用用戶端支援的覆寫、合併或擴充設定功能，並查看最終執行設定確認結果。合併規則是追加、取代或置於前方，取決於用戶端的實作；不能只根據覆寫檔案的內容推斷最終順序。

DNS 與 fake-ip：遷移時重新檢查解析路徑

fake-ip 的基本原理是為網域名稱回傳虛擬位址，並讓核心在後續連線中將位址對應回網域名稱。它不是某種節點協定，也不會自動確保所有 DNS 請求都經過指定的解析器。系統 DNS、瀏覽器的安全 DNS、應用程式內建解析功能，以及 TUN 的 DNS 劫持範圍，都會影響實際解析路徑。

以下僅示範 mihomo 的 DNS 設定片段，需合併至現有設定中。範例監聽本機 1053 連接埠，避免直接占用常見的 53 連接埠；但「開啟監聽」本身不會自動讓作業系統將查詢送到這裡。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query
  nameserver-policy:
    "+.example.com":
      - https://1.1.1.1/dns-query

虛擬位址範圍：198.18.0.1/16 位於測試用途的位址空間；若本機實驗網路已使用此範圍，請先排除衝突。
分域解析：nameserver-policy 可為符合條件的網域指定解析器，但不代表該網域的連線會固定使用某個代理節點。
加密解析：DoH 可保護相關解析請求的傳輸，但端點是否可連線、請求如何路由，仍須依實際網路環境確認。
位址對應：變更 fake-ip 設定後，系統或瀏覽器可能仍快取舊位址；請清除快取或重新啟動測試中的應用程式，再觀察新的連線。

若要透過 TUN 接管 DNS，可在現有的 TUN 設定中檢查 dns-hijack。常見寫法包含 any:53 與 tcp://any:53，分別涵蓋一般 DNS 的 UDP 與 TCP 流量；實際接管效果也會受到平台與路由實作影響。應用程式直接透過 HTTPS 傳送的 DoH 並非送往 53 連接埠的一般 DNS，不要預期這類劫持會自動改寫 DoH。

設定遷移驗證：從語法檢查到 TUN 接管

第一步：檢查設定能否載入

直接使用核心時，可先執行以下命令。Windows 使用者可將命令中的程式名稱替換為本機的 mihomo.exe，並在設定檔所在目錄執行。若使用圖形介面用戶端，建議優先使用內建的設定檢查功能，避免另開程序搶占正在使用的連接埠。

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

檢查通過只代表設定符合這次測試的載入條件，不代表節點伺服器可以連線，也不代表每條規則都符合預期。若錯誤指向特定行，請同時檢查上一行的縮排、冒號與清單符號；YAML 使用 Tab 縮排或頂層鍵重複，都可能造成不易察覺的問題。

第二步：只用一個節點驗證代理出口

結束舊用戶端，暫時關閉新用戶端的 TUN，使用規則模式並選擇一個已知可用的節點。
確認實際使用的混合連接埠。若設定為 7890，可使用下方命令，明確透過該連接埠向測試網域送出請求。
在連線記錄中確認目標網域、符合的規則與最後使用的節點。明確指定代理連線成功後，再開啟系統代理測試一般應用程式。
最後啟用 TUN，分別測試瀏覽器、終端機和一個不遵循系統代理設定的應用程式，並確認區域網路仍可正常存取。

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com

這裡的 10 秒連線逾時與 20 秒總逾時是用來控制測試等待時間，並非網速指標。若提示無法連線至本機連接埠，請先檢查是否正在監聽；若記錄已顯示代理交握錯誤，則應檢查節點驗證資訊、傳輸參數或線路，而不是繼續更改本機連接埠。

第三步：驗證訂閱更新與復原方式

手動更新一次訂閱和規則提供者，再確認自訂規則、DNS 覆寫與策略群組選擇是否保留。完成後，備份新用戶端的有效設定，並保留舊設定的離線副本。需要復原時，先停止新用戶端接管流量，再還原舊環境，避免兩邊同時修改系統代理與路由。

核心選型結論：依設定需求與維護狀態判斷

若要繼續使用現有的 Clash 風格訂閱，並需要較新的協定、規則與 DNS 功能，請選擇明確整合 mihomo，且可查看核心版本與執行記錄的用戶端。若舊設定來自 Premium，遷移重點在於腳本邏輯、提供者、TUN 與 DNS，而不是單純更換程式檔名。

只需要基本分流：先讓節點、策略群組與基本規則穩定運作，不必為了功能名稱一次開啟所有選項。
需要新協定：確認核心版本與協定欄位，優先取得服務提供者明確標示適用於 Meta 或 mihomo 的設定。
需要全域接管：確認平台權限、TUN 服務與 DNS 路徑，依序驗證「明確指定代理 → 系統代理 → TUN」。
需要長期維護：同時留意用戶端與核心更新。介面更新與核心更新是兩回事，升級後仍須重新檢查重要設定。

Clash.Meta 與 mihomo 的名稱關係只是起點。真正決定設定能否遷移的，是目前執行的核心版本、有效設定內容，以及本機連接埠、權限與解析路徑。逐項記錄這些資訊，遇到問題時就能針對相應層級排查。