Clash 核心版本比較：原版 Premium、Clash Meta 與 mihomo 有何不同

先釐清名稱：它們不是三個平行更新的版本

Clash 用戶端通常由圖形介面、核心與設定檔三部分組成。圖形介面負責匯入訂閱、切換節點與顯示日誌；核心負責建立代理連線、解析規則、執行 DNS 策略及接管流量。用戶端名稱相同，不代表使用相同核心。判斷功能範圍時，應先查看核心名稱與版本，而不是只看應用程式名稱。

原版 Clash 是 Dreamacro 發布的開放原始碼核心，提供 HTTP、SOCKS、混合代理連接埠、代理群組與基本規則比對等功能。Clash Premium 是原作者以此為基礎發布的增強版，曾加入 TUN、規則集、腳本及更完整的流量接管功能。原專案儲存庫於 2023 年停止維護後，原版與 Premium 都不再適合作為持續更新的功能基準。

Clash Meta 是社群從 Clash 分支出的增強核心。它延續 Clash 的設定結構，同時擴充協定、規則、DNS、TUN 與代理群組功能。專案之後將正式名稱改為 mihomo，因此 Clash Meta 與 mihomo 主要是前後名稱的關係，並非兩套完全獨立的新核心。舊版用戶端介面可能仍顯示 Meta，新版本、文件與程序名稱則多使用 mihomo。

名稱與維護關係

名稱	定位	目前選型意義
原版 Clash	早期開放原始碼的基礎核心	適合閱讀舊設定與理解基本語法，不建議作為新部署的首選
Clash Premium	原作者發布的增強版	常見於舊版桌面用戶端，重點是相容既有設定
Clash Meta	社群增強分支的舊稱	多數功能已延續至 mihomo
mihomo	Clash Meta 更名後持續維護的專案	適合需要新協定、擴充規則與完整 TUN 功能的裝置

協定支援差異：先看訂閱節點使用哪種傳輸方式

核心能否讀取訂閱，不等於能否連線訂閱中的所有節點。訂閱轉換後通常是一組 proxies，每個節點都包含 type、伺服器位址、連接埠與驗證欄位。遇到不支援的類型時，核心可能在載入階段直接報錯，也可能略過對應節點，最後呈現訂閱已更新但節點數量減少。

原版與 Premium 的基礎範圍

原版 Clash 主要涵蓋 Shadowsocks、VMess、Trojan、Snell、SOCKS5 與 HTTP 等當時常見類型。Premium 的核心優勢較偏向 TUN、規則集與執行能力，不應簡單理解為支援所有後來出現的代理協定。含有新欄位的訂閱放入舊版 Premium 用戶端，仍可能出現 unsupported proxy type 或欄位解析失敗。

mihomo 的擴充範圍

mihomo 在相容常見 Clash 節點結構的基礎上，持續加入 VLESS、Reality、Hysteria 2、TUIC、WireGuard、ShadowTLS 等類型或傳輸組合。具體欄位會隨核心版本變化，例如 VLESS Reality 通常涉及 servername、reality-opts、公鑰與短識別碼；Hysteria 2 通常需要伺服器連接埠、驗證資訊與 TLS 伺服器名稱。舊核心不認得這些欄位時，只修改節點名稱無法解決問題。

訂閱以 Shadowsocks、VMess、Trojan 為主時，三類核心的基本連線能力重疊較多。
訂閱包含 VLESS Reality、Hysteria 2 或 TUIC 時，應直接確認用戶端是否內建 mihomo。
使用 WireGuard 節點時，要區分「代理節點類型」與系統中獨立執行的 WireGuard 應用程式，兩者的設定入口不同。
節點支援也會受到用戶端封裝影響。核心具備功能，但圖形介面未提供欄位編輯入口時，需要透過 YAML 設定使用。

規則功能差異：基礎語法相容，擴充欄位無法反向通用

三者都沿用 Clash 由上而下比對、命中第一條規則即停止的模型。常用的 DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD、IP-CIDR、GEOIP 與最後的兜底規則具有較高相容性。真正拉開差距的是規則集合、程序比對、入站條件與地理資料載入方式。

rules:
  - DOMAIN-SUFFIX,example.com,Proxy
  - DOMAIN-KEYWORD,video,Media
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,Final

這段設定體現了通用原則：網域規則放在需要解析 IP 的規則之前；區域網路位址直接連線；no-resolve 用於避免 IP-CIDR 規則主動觸發 DNS 解析；最後使用 MATCH 接手未命中的連線。部分舊設定使用 FINAL，遷移時應依目標核心文件統一為其支援的寫法。

RULE-SET 與規則提供者

Premium 曾透過規則集功能解決超長規則清單的維護問題。Meta 與 mihomo 進一步普及 rule-providers，可從本機檔案或遠端位址載入 domain、ipcidr、classical 等行為類型。設定時不只要看規則檔內容，也要讓 behavior 與內容格式一致。將網域清單宣告為 ipcidr 時，核心不會自動猜測並修正。

rule-providers:
  private-domain:
    type: file
    behavior: domain
    path: ./rules/private-domain.yaml

rules:
  - RULE-SET,private-domain,DIRECT
  - MATCH,Final

遠端規則提供者還可能包含 url、interval 與快取路徑。更新間隔通常以秒計算，例如 86400 代表 24 小時。規則檔並非更新越頻繁越好；公開地理清單每天抓取一次通常已足夠，頻繁更新只會增加啟動與網路請求負擔。

程序與入站比對

mihomo 支援更豐富的規則條件，例如 PROCESS-NAME、PROCESS-PATH、NETWORK、IN-PORT、SRC-IP-CIDR 與邏輯組合規則。程序比對依賴作業系統權限與實作方式，在 Android、Windows、macOS 上的可用範圍並不完全一致。行動系統限制較多時，使用網域與 IP 規則通常更穩定。

GEOSITE 與 GEOIP：名稱相近，但比對對象不同

GEOIP 依目標 IP 所屬地區進行比對。只有網域的連線可能需要先解析出 IP，核心才能判斷地區。GEOSITE 則根據預先整理的網域分類資料比對，例如搜尋服務、串流媒體或特定地區的網域集合。它不等同於即時查詢網站歸屬，也不會分析網頁內容。

原版 Clash 很早便支援 GEOIP 等基礎地理比對。Premium 與後續分支擴充了可用資料與規則格式。mihomo 可搭配 GeoIP、GeoSite 及不同格式的資料檔案運作，但檔案格式、下載路徑與設定項目必須對應具體版本。只有規則列而缺少資料檔案時，啟動日誌通常會提示資源讀取失敗。

rules:
  - GEOSITE,category-ads-all,REJECT
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,Final

上例先依網域分類處理廣告集合，再讓中國大陸常見網域直接連線，之後使用 GEOIP 補充處理已取得 IP 的連線。順序不能任意顛倒。如果把寬泛的 GEOSITE,cn,DIRECT 放在需要代理的特定網域規則之前，具體規則可能永遠無法命中。

地理資料常見排查項目

在用戶端「設定」→「核心」或「關於」中確認實際執行的是 Premium、Meta 還是 mihomo。
開啟設定目錄，檢查 GeoIP 與 GeoSite 資料檔是否存在，並確認修改時間是否合理。
在「設定」→「日誌」中搜尋 geo、rule 或 provider，確認檔案已載入。
將目標網域放入更具體的 DOMAIN 或 DOMAIN-SUFFIX 規則中測試，排除地理分類本身的偏差。
確認用戶端更新核心後是否也同步更新了地理資料。兩者通常由不同入口管理。

TUN 模式差異：接管範圍取決於核心、權限與系統路由

系統代理只會影響遵循 HTTP 或 SOCKS 代理設定的應用程式。遊戲、命令列程式、部分商店應用程式及自帶網路堆疊的軟體可能繞過系統代理。TUN 模式透過虛擬網路介面接管更多 TCP 與 UDP 流量，因此常用於需要統一分流的桌面與行動裝置。

原版基礎核心主要圍繞代理連接埠運作。Premium 將 TUN 作為重要的增強功能。mihomo 延續並擴充 TUN 設定，常見欄位包括 enable、stack、auto-route、auto-detect-interface、strict-route 與 dns-hijack。不同版本支援的值可能有所變化，遷移舊設定時應以目前核心輸出的錯誤訊息為準。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  strict-route: true
  dns-hijack:
    - any:53

auto-route 用於自動寫入必要路由；auto-detect-interface 嘗試識別目前的出口網卡；strict-route 用於減少流量繞過；dns-hijack 將指定的 DNS 請求交由核心處理。範例中的 any:53 代表接管目標連接埠為 53 的 DNS 流量，但是否適合目前系統，仍要配合本機 DNS、區域網路裝置與其他 VPN 軟體判斷。

常見 TUN 堆疊如何選擇

system：更依賴作業系統網路堆疊，通常效能較直接，適合先作為桌面系統的測試選項。
gVisor：使用使用者態網路堆疊處理部分連線，相容性表現可能不同，遇到特定 UDP 或應用程式問題時可用於對照測試。
mixed：依流量類型組合處理。是否存在及具體行為取決於 mihomo 版本，遷移舊設定後應檢查啟動日誌。

開啟 TUN 後無法連上網路，不代表核心本身無法使用。先關閉 TUN，確認一般系統代理能正常連線；再檢查管理員權限、虛擬網卡、預設路由與 DNS。Windows 可重點觀察是否與其他 VPN 虛擬網卡衝突，macOS 要確認系統延伸功能或 VPN 權限，Android 則要確認系統只保留一個作用中的 VPN 服務。

DNS 行為差異：Fake-IP 設定要與規則和 TUN 一起檢視

Clash 系列核心常見的 DNS 增強模式包括 fake-ip 與 redir-host。Fake-IP 會先向應用程式回傳保留位址，再在連線階段還原原始網域，讓網域規則能更早參與比對。它能減少部分情境下的重複解析，但也可能影響依賴真實區域網路位址的裝置探索、印表機、遊戲平台或公司內網網域。

mihomo 對 Fake-IP 過濾、DNS 分流、回退解析與 nameserver-policy 等功能提供更多組合方式。設定越複雜，就越需要明確每組 DNS 的用途。把所有網域同時交給多個上游不一定更快，還可能造成結果不一致。家庭網路可以先從一組主要解析器、一組直連規則與必要的 Fake-IP 過濾項開始。

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 223.5.5.5
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"

範例將核心 DNS 監聽在 1053 連接埠，並使用 198.18.0.1/16 作為 Fake-IP 位址段。該位址段不應視為節點伺服器的真實位址。在日誌中看到連線至 198.18.x.x 時，要配合網域映射判斷，不要直接認定為錯誤目標。

設定相容性：能啟動只是第一步

Clash Meta 與 mihomo 盡量延續 Clash YAML 結構，但相容性並非雙向。基礎 Clash 設定通常較容易被 mihomo 讀取；使用 mihomo 新協定、新規則類型或擴充 DNS 欄位的設定，則無法直接交給原版或 Premium。用戶端也可能在儲存時重寫設定，因此手動修改前應區分「訂閱產生的設定」與「本機覆寫設定」。

從 Premium 遷移至 mihomo 的檢查清單

記錄原用戶端的混合連接埠、區域網路存取設定、工作模式與目前選用的代理群組。
保留原始 YAML 副本，再將訂閱匯入新用戶端，不要直接覆寫唯一的設定檔。
先關閉 TUN，只測試 7890 等本機代理連接埠是否能正常連線。
檢查日誌中是否有棄用欄位、重複鍵、規則集載入失敗與代理類型錯誤。
逐一測試 DIRECT、REJECT、節點選擇群組與自動測速群組，確認規則動作符合預期。
最後開啟 TUN 與 DNS 劫持，分別測試瀏覽器、命令列、遊戲及區域網路裝置。

自動測速群組也可能造成使用體驗差異。常見的 url-test 會定期存取指定 URL，根據連線耗時選擇節點。測試間隔設為 300 代表每 5 分鐘檢測一次。延遲最低不代表下載速度最高，因為測試通常只涵蓋 DNS、TCP、TLS 或一次小型 HTTP 請求，無法代表長連線頻寬與尖峰時段的壅塞情況。

proxy-groups:
  - name: Auto
    type: url-test
    proxies:
      - Node-A
      - Node-B
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

tolerance: 50 表示候選節點延遲差距較小時，減少頻繁切換。對會議、下載與持續播放而言，穩定連線通常比每次測試後追逐幾毫秒更重要。遷移核心後若節點切換明顯增加，應檢查測試 URL、間隔與容差，而不是只調整規則。

不同平台如何選擇核心

Windows 與 macOS

新安裝優先選擇明確標示使用 mihomo、能顯示核心版本並提供日誌入口的用戶端。桌面系統常需要 TUN、程序規則與規則提供者，mihomo 的涵蓋更完整。安裝後可依序檢查「設定」→「核心版本」、「設定」→「訂閱」與「日誌」，確認介面版本與實際核心並非兩套獨立的更新狀態。

如果舊用戶端仍使用 Premium，且現有訂閱只有基礎協定，短期內可能仍能運作。但遇到系統升級、地理資料失效或訂閱加入新節點類型時，排查成本會逐漸提高。遷移前保留規則與連接埠設定，再用 mihomo 用戶端逐項恢復，通常比在舊核心中補上新協定更直接。

Android

Android 用戶端透過系統 VPN 介面接管流量，應用程式本身是否整合 mihomo，比桌面上的系統代理設定更關鍵。選擇時應查看核心說明、分應用程式代理、IPv6、UDP 與背景執行策略。系統只允許一個主要 VPN 服務同時執行，因此 Clash 類用戶端與其他 VPN、DNS 過濾應用程式通常無法同時接管流量。

iPhone 與 iPad

iOS 上通常不是直接安裝名為 mihomo 的獨立核心程式，而是使用支援 Clash 設定或相近規則體系的網路工具。不同應用程式可能採用不同實作，不能根據設定檔副檔名推斷完整相容性。匯入前應核對應用程式說明所支援的協定、規則類型與 TUN 行為，尤其是 VLESS Reality、Hysteria 2 與複雜的 rule-providers。

路由器、NAS 與命令列環境

路由器與 NAS 更重視 CPU 架構、記憶體用量、啟動方式與防火牆整合。下載核心時要符合 amd64、arm64 或其他實際架構。以命令列執行後，可透過版本指令或控制介面確認核心身分，並檢查 7890、9090、1053 等連接埠是否與現有服務衝突。低記憶體裝置應控制規則提供者數量與更新頻率。

使用情境	建議選擇	優先檢查
新安裝桌面用戶端	mihomo	TUN 權限、核心版本、訂閱協定
繼續維護舊設定	先確認 Premium 相容性，再安排遷移	規則集、腳本、舊欄位
Android 分應用程式代理	整合 mihomo 的用戶端	VPN 權限、背景限制、UDP
iOS 設定匯入	依應用程式實際相容範圍選擇	協定、規則提供者、系統 VPN 限制
路由器與 NAS	符合架構的 mihomo	架構、記憶體、路由與連接埠衝突

最終判斷：依功能需求選擇，不要只猜名稱的新舊

原版 Clash 奠定了設定、代理群組與規則體系；Premium 補充了當時重要的 TUN 與進階規則功能；Clash Meta 延續社群開發，並以 mihomo 之名持續維護。對一般使用者而言，Meta 與 mihomo 不必視為兩套互斥技術，重點是用戶端內建的實際版本與設定相容範圍。

只使用基礎 Shadowsocks、VMess 或 Trojan 節點，並依賴系統代理時，舊核心與 mihomo 的表面體驗可能相近。需要 VLESS Reality、Hysteria 2、TUIC、完整規則提供者、GEOSITE、程序規則或更細緻的 TUN 與 DNS 控制時，mihomo 更適合作為目前的基準。

選定核心後，依照「一般代理連線 → 基礎規則 → DNS → TUN → 擴充規則」的順序驗證。每增加一層功能就查看一次日誌，並記錄連接埠、模式與測試結果。如此即使更新用戶端或訂閱結構變更，也能快速判斷問題出在節點、規則、DNS 還是系統路由。