Clash 核心版本差異：原版、Meta 與 mihomo 設定相容性

在用戶端設定、設定檔儲存庫與訂閱說明中，Clash、Clash.Meta、Meta、mihomo 經常同時出現。它們不是四套彼此獨立的設定體系，但也不能簡單視為同一程式的不同拼法。判斷 YAML 是否能載入，除了查看檔案副檔名，也要確認實際執行的核心、核心版本、用戶端提供的設定預處理方式，以及訂閱服務輸出了哪些擴充欄位。

多數基礎設定可以在這些核心之間共用，例如監聽連接埠、代理節點、策略群組與常見網域規則。不過，TUN、流量嗅探、新協定、規則集合、DNS 擴充與程序比對等能力存在明顯差異。選錯核心時，常見結果不是整份檔案都無法讀取，而是部分欄位被拒絕、某個節點無法建立、規則未依預期命中，或圖形化用戶端根本不顯示對應開關。

Clash、Clash.Meta 與 mihomo 的名稱關係

原版 Clash

一般所說的「原版 Clash」，是指最初的開源 Clash 核心及其既有設定語法。它建立了目前仍廣泛使用的基礎結構，包括 proxies、proxy-groups、rules、dns、mixed-port 與 external-controller 等欄位。許多訂閱轉換工具與用戶端設定範本，也以這套結構作為共同基礎。

原版專案已停止持續維護。這表示它仍可能在舊裝置或既有用戶端中正常執行，但不會再跟進新協定、平台網路介面變化與後續擴充欄位。對只使用 HTTP、SOCKS5、Shadowsocks、Trojan 等既有能力的舊設定而言，短期內可能感受不到差異；一旦訂閱加入較新的節點類型或設定依賴新規則能力，相容性界線就會浮現。

Clash.Meta

Clash.Meta 是在 Clash 設定體系基礎上持續發展的分支。它保留大量基礎欄位，同時擴充代理協定、TUN、DNS、嗅探、規則類型與平台支援能力。部分用戶端曾直接將核心標示為「Meta」，設定文件也經常使用「Meta 專屬欄位」這種說法，因此這個名稱至今仍出現在訂閱範本與錯誤日誌中。

mihomo

mihomo 是 Clash.Meta 後續採用的專案名稱。就演進關係而言，日常語境中的新版 Meta 與 mihomo 通常指向同一條持續維護的核心路線，而不是需要彼此轉換的兩種設定格式。實際判斷時仍應查看版本號，因為早期 Clash.Meta 與目前的 mihomo 之間歷經欄位補充、預設行為調整與協定實作更新。

因此，「支援 Meta」不能自動等同於「支援目前全部 mihomo 設定」。某個較舊的用戶端即使內建 Meta 核心，也可能無法辨識後來加入的節點參數；反過來，新的 mihomo 通常能讀取大部分基礎 Clash 設定，但舊欄位的行為、預設值或建議寫法可能已經改變。

維護狀態、協定與規則能力比較

協定支援是最容易觀察到的差異。訂閱中的每個節點都會宣告 type 及其參數。核心不認識節點類型時，通常會在設定檢查或啟動日誌中回報解析錯誤；認得協定但不支援某個參數時，也可能出現欄位錯誤。這類問題無法靠修改策略群組名稱解決，應先核對用戶端內建核心的版本與節點協定要求。

規則能力的差異更不易察覺。經典規則如 DOMAIN-SUFFIX、DOMAIN、IP-CIDR、GEOIP 與 MATCH 具有較高通用性。涉及規則集合行為、程序名稱、網路類型、入站標籤或邏輯組合的設定，則更依賴 mihomo 的具體版本。設定能夠啟動，也不代表擴充規則一定會按照作者預期執行；遷移後應透過連線記錄檢查實際命中項目。

哪些 YAML 欄位通常具備相容性

以下結構適合作為跨版本設定的基礎層。它只展示欄位關係，不包含真實伺服器憑證：

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

proxies:
  - name: Example-Node
    type: socks5
    server: 127.0.0.1
    port: 1080

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

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

mixed-port 用於同時提供 HTTP 與 SOCKS 代理入口；mode: rule 表示依規則決定連線去向；策略群組名稱必須與規則末尾引用的目標一致。這類錯誤與核心分支無關，例如規則指向 Proxy，而策略群組實際名稱為 PROXY，任何核心都無法自動推斷兩者是同一群組。

節點欄位是相容性檢查的第一層。即使 proxies 清單本身屬於通用結構，清單內的協定類型、傳輸層參數、TLS 指紋、UDP 行為與驗證選項仍可能只受特定版本支援。訂閱服務更新節點範本後，舊用戶端突然無法啟動，往往就是核心版本落後於訂閱輸出格式。

DNS 是第二層。經典的 enhanced-mode: fake-ip、預設解析器與備用解析器具有廣泛認知度，但 nameserver-policy、代理伺服器網域解析、Fake-IP 排除清單以及不同上游的傳輸格式，會隨核心版本產生差異。將新版 mihomo 範例複製到舊版 Clash 前，應逐項查閱核心文件，而不是只刪除第一行報錯內容。

TUN、嗅探與規則集合為何容易出問題

TUN 不只是一個開關

TUN 模式讓核心透過虛擬網路介面接收流量，適合不遵循系統代理設定的應用程式。mihomo 設定中常見 tun 區塊以及 enable、stack、auto-route、auto-detect-interface 等參數。能否正常執行還取決於作業系統權限、路由表、既有 VPN、虛擬機網路，以及用戶端是否正確啟動服務元件。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true

將這段設定放入原版或較舊的 Meta 核心時，可能出現未知欄位，也可能因平台實作不同而無法建立介面。即使核心支援，圖形化用戶端也可能在啟動時重寫 TUN 設定。因此排查順序應為：確認核心版本、檢查設定測試結果、查看啟動日誌、核對系統權限，最後再檢查路由衝突。

嗅探用於還原網域資訊

流量嗅探會嘗試從 HTTP、TLS 或其他可辨識的流量中擷取目標網域，讓原本只呈現為 IP 連線的請求仍能參與網域規則比對。mihomo 對嗅探協定、連接埠範圍、強制網域與跳過網域提供較細緻的控制。舊核心無法直接承接這些欄位，錯誤設定還可能影響區域網路服務、遊戲連線或採用特殊握手方式的應用程式。

規則集合需要同時檢查格式與行為

遠端規則集合涉及下載網址、快取更新、規則行為類型與內容格式。不同核心及版本對 Rule Provider 或 Rule Set 的欄位命名、承載格式與更新方式可能不同。看到規則檔下載成功還不夠，也要確認它已被目標規則引用，且集合行為與內容一致。例如網域集合不能直接用 IP 網段集合的方式解讀。

規則清單遵循由上至下的比對順序。無論使用哪種核心，過早出現的寬泛規則都會截斷後續比對。MATCH 通常應放在末尾；區域網路與私人位址直連規則應置於適當位置；啟用 Fake-IP 後，DNS 對映與規則判斷也要結合連線日誌觀察。核心升級不會自動修正規則順序錯誤。

如何核對用戶端名稱與實際核心

圖形化用戶端通常會將核心檔案封裝在應用程式目錄中，並透過控制介面讀取代理群組、連線、日誌與設定狀態。有些用戶端允許在設定中切換核心，有些固定使用某個分支，還有些會在應用程式升級時一併更新核心。判斷實際環境時，可以依下列順序檢查：

1. 查看關於頁面或日誌第一行。啟動日誌通常會顯示核心名稱、版本與建置資訊，比用戶端宣傳頁更接近目前的執行狀態。
2. 使用用戶端內建的設定檢查。先驗證 YAML 語法，再觀察錯誤是否指向未知欄位、節點類型或無效值。
3. 確認覆寫與訂閱轉換。用戶端可能會在載入前合併本機設定，磁碟上的訂閱原文不一定等於核心最終收到的設定。
4. 核對控制介面相容性。mihomo 延續了大量 Clash API 結構，但擴充功能未必能被舊介面完整呈現。
5. 檢查核心切換是否真正生效。更換檔案後應徹底停止舊程序並重新啟動，避免介面仍連線到背景殘留的執行個體。

用戶端介面沒有某個選項，不一定表示核心缺少該能力；可能只是介面尚未提供表單。反過來，介面保留舊開關，也不保證目前核心仍採用相同的預設值。對於進階欄位，較穩妥的方式是編輯 YAML 或覆寫檔案，並在啟動後檢查最終設定與日誌。

行動裝置與桌面裝置還存在系統能力差異。桌面用戶端常透過系統代理或 TUN 接管流量，行動作業系統通常依賴系統提供的 VPN 介面。複製相同 mihomo 設定到不同平台時，節點與規則可以共用，但入站連接埠、TUN 路由、區域網路存取與 DNS 接管設定應依平台調整。

從原版 Clash 遷移至 mihomo 的檢查步驟

從舊核心遷移時，不建議一開始就加入所有新功能。先讓原有設定在新核心上穩定執行，再逐層啟用 DNS、TUN、嗅探與規則集合，更容易定位問題。

1. 保留原有設定與用戶端設定。分別備份訂閱原文、本機覆寫、策略群組選擇與 DNS 設定，避免將多個來源混成一份難以回復的檔案。
2. 建立最小可執行設定。保留一個可用節點、一個選擇策略群組與少量規則，確認核心能啟動並建立連線。
3. 恢復完整節點與策略群組。重點檢查群組內引用名稱、自動測速網址、篩選運算式與協定參數。
4. 恢復規則。先加入經典網域與 IP 規則，再接入遠端集合；每次調整後觀察規則命中情況與日誌。
5. 設定 DNS。確認基礎解析、代理節點網域解析與 Fake-IP 排除項目，再檢查區域網路網域及特殊應用程式。
6. 最後啟用 TUN 與嗅探。這兩項功能會改變系統流量入口與目標識別方式，應分別測試瀏覽器、終端機、遊戲與區域網路存取。

遷移後若出現「瀏覽器可用但終端機無法使用」，通常要檢查終端機是否讀取系統代理、環境變數是否已設定，以及是否需要 TUN；若出現「節點可連線但網域無法開啟」，應檢查 DNS 上游、Fake-IP 模式與節點伺服器網域解析；若出現「部分網站策略錯誤」，則應查看實際命中的規則，而不是直接更換所有節點。

如果新核心提示欄位已棄用，應依照目前版本文件進行替換，而非長期依賴相容處理。設定檔是持續運作的基礎設施，保留已失去意義的欄位會增加後續升級成本。對於訂閱產生的欄位，應優先調整訂閱範本或轉換規則，避免每次更新後手動修改。

不同使用情境的核心選型

繼續執行既有舊環境

如果裝置長期離線、設定固定、節點協定穩定，且用戶端與系統版本都不再變動，原版 Clash 仍可能維持既有用途。但這種選擇適合維持現況，不適合作為新的部署基準。訂閱一旦引入新協定或新參數，舊核心可能立即暴露相容性限制。

新安裝與持續更新的訂閱

對於新安裝、經常更新訂閱、需要 TUN 或希望使用現代規則能力的環境，優先選擇內建較新 mihomo 的用戶端。選擇用戶端時，應同時查看核心更新機制、設定目錄、日誌入口、系統代理控制與 TUN 服務安裝方式，而不是只比較介面配置。

多裝置共用設定

多裝置設定應以相容性較高的基礎層為中心，再為各平台附加覆寫。節點與策略群組可以來自同一訂閱，桌面端追加 TUN 與程序規則，行動端保留適合系統 VPN 介面的設定，伺服器則依命令列服務與環境變數需求處理。如此可避免某個平台專屬欄位阻止其他裝置載入。

伺服器端或命令列部署

在 Linux 伺服器、軟路由或容器中直接執行核心時，mihomo 的持續維護更適合作為部署基礎。除了設定語法，也要建立固定且可控的版本更新流程，明確設定目錄、工作目錄、Geo 資料位置、控制連接埠與服務權限。升級前應先執行設定測試，再重新啟動服務並檢查日誌，避免將語法問題誤判為網路故障。

常見相容性問題