Clash 原版、Meta 與 mihomo 有什麼關係？核心版本差異與選擇指南

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

討論 Clash 版本時，最容易混淆的是「客戶端」和「核心」。桌面上的視窗、系統匣選單、訂閱按鈕屬於圖形客戶端；負責建立代理連線、比對規則、處理 DNS 以及接管流量的可執行程式，才是核心。Clash Verge Rev、Mihomo Party 等名稱通常指客戶端，而 Clash、Clash.Meta、mihomo 指的是客戶端內部呼叫的核心。

設定檔則是第三個層次。常見的 YAML 檔案包含監聽連接埠、代理節點、策略群組、規則與 DNS 設定。客戶端負責下載、編輯設定，並交給核心處理；核心讀取欄位後開始運作。因此，同一份訂閱放進兩個介面相似的客戶端，結果仍可能不同：一個使用原版 Clash，另一個使用 mihomo，兩者可辨識的協定與欄位並不完全相同。

圖形客戶端: 提供訂閱管理、系統代理切換、節點選擇、日誌檢視與核心更新等介面。

代理核心: 解析 YAML 設定、建立連線，並執行規則比對、DNS 解析與 TUN 流量處理。

訂閱轉換: 將伺服器提供的節點資訊整理成特定核心可讀取的設定格式，無法憑空增加核心能力。

規則集: 依網域、IP、程序或網路條件，決定要求進入代理群組、直連或拒絕策略。

Clash 原版、Clash.Meta 與 mihomo 的關係

原版 Clash：規則代理體系的起點

通常所說的「原版 Clash」，是指由 Dreamacro 維護的 Clash 專案。它確立了至今仍沿用的設定結構，包括 proxies、proxy-groups、rules、proxy-providers 與 rule-providers。預設範例中常見的 HTTP 代理連接埠是 7890，外部控制介面則常用 9090，這些慣例也被許多後續客戶端保留。

原版專案在 2023 年 11 月停止公開維護，相關程式碼儲存庫隨後進入封存狀態。原版最後階段常見的版本標示是 v1.18.0。停止維護不代表既有安裝會立即失效：舊協定、基本網域規則與一般系統代理仍可能繼續運作，但不會再適配新協定、新規則欄位及後續作業系統的網路變化。

歷史上也曾有 Clash Premium。它曾在原版基礎上提供更多功能，例如強化規則與 TUN 相關功能，但它並不是今天 mihomo 的舊名稱。看到舊教學寫著「Premium 核心」時，應將其視為特定歷史分支理解，不要直接等同於目前的 mihomo。

Clash.Meta：相容 Clash 設定的社群擴充核心

Clash.Meta 是社群在 Clash 設定體系上持續擴充的核心。它保留大量原版欄位，讓既有規則與策略群組能以較低成本遷移，同時加入更多代理協定、規則類型、DNS 控制與 TUN 能力。對使用者而言，「Meta 設定」通常表示設定中使用了原版未定義的擴充欄位。

這裡所說的相容，更接近「mihomo 能讀取大部分原版設定」，而不是雙向完全相容。只使用 DOMAIN-SUFFIX、IP-CIDR、GEOIP、MATCH 等基本規則時，兩者差異較小；一旦設定使用 VLESS、Hysteria2、TUIC、GEOSITE 或 mihomo 專屬入站欄位，原版核心就可能報錯或忽略設定。

mihomo：Clash.Meta 改名後的延續名稱

mihomo 不是接在 Clash.Meta 之後的另一套陌生核心，而是 Clash.Meta 專案改名後採用的名稱。舊版客戶端、訂閱轉換工具與歷史文章仍可能顯示 Clash.Meta；較新的發行套件、日誌與設定文件通常使用 mihomo。看到「Meta 核心」和「mihomo 核心」時，首先應理解為同一個社群專案在不同階段的稱呼，而不是兩種需要二選一的產品。

協定、規則、DNS 與 TUN 的功能差異

選擇核心不能只看「能不能開啟網頁」。協定支援決定節點能否建立連線，規則能力決定流量能否準確分流，DNS 與 TUN 則會影響應用程式涵蓋範圍及網域解析路徑。以下整理實際設定時的主要差異。

比較項目	原版 Clash	mihomo
維護狀態	原專案已封存，末期常見版本為 v1.18.0	社群持續維護，客戶端通常可跟隨穩定版更新
基礎協定	支援 Shadowsocks、VMess、Trojan、HTTP、SOCKS5 等常用類型	相容多種基礎類型，並擴充 VLESS、TUIC、Hysteria2 等設定
規則類型	涵蓋網域、IP、連接埠、程序名稱、規則集與 MATCH 等基本比對	增加 GEOSITE、IP-ASN、網路類型、入站類型等更細緻的條件
DNS	具備 nameserver、fallback、fake-ip 等常用機制	擴充 nameserver-policy、規則聯動及更細緻的解析控制
TUN	不同舊分支的功能不一致，歷史教學常依賴 Premium	提供持續維護的 TUN 實作，並可搭配 DNS 劫持與路由自動設定
新設定相容性	遇到擴充欄位時可能無法啟動	更適合目前的訂閱與持續更新的規則範本

協定支援：節點名稱相同不代表格式相同

Shadowsocks、VMess、Trojan 這類協定在原版與 mihomo 中都有廣泛的使用基礎，但具體加密方式、傳輸層參數與擴充選項仍須以設定欄位為準。VLESS、Reality、Hysteria2、TUIC 等較新的節點格式通常應交由 mihomo 處理。若匯入訂閱後節點數量明顯減少，或日誌出現 unsupported proxy type，應優先檢查核心是否過舊。

訂閱轉換只能改變文字結構。例如，它可以將節點整理成 YAML 的 proxies 清單，卻無法讓原版核心突然理解 Hysteria2。節點類型超出核心能力時，正確做法是更換支援該協定的核心或客戶端，而不是反覆修改訂閱網址。

規則能力：基本規則通用，擴充規則取決於核心

原版 Clash 已能完成大多數網域與 IP 分流。以下是常見的基本寫法：網域後綴進入代理群組，區域網路位址直連，其餘要求交由最終策略處理。

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

mihomo 在此基礎上支援更細緻的比對條件。例如 GEOSITE 可引用網域分類資料，IP-ASN 可依自治系統編號比對，NETWORK 可區分 TCP 與 UDP，IN-TYPE 可依入站類型處理流量。這些能力適合複雜分流，但設定放回原版核心時，不保證能正常使用。

rules:
  - GEOSITE,category-ads-all,REJECT
  - NETWORK,udp,UDP-Proxy
  - IP-ASN,13335,Proxy,no-resolve
  - MATCH,Final

規則會由上而下比對，命中後就停止繼續判斷。無論使用哪個核心，都應將具體規則放在寬泛規則之前，並將 MATCH 放在最後。否則，即使核心支援進階規則，也可能因前面的寬泛條件已命中而沒有執行機會。

DNS：關注解析路徑，不只看伺服器位址

原版 Clash 已提供 nameserver、fallback、fallback-filter 與 enhanced-mode 等核心設定。mihomo 延續這些欄位，並提供更細緻的網域策略與規則聯動。實際遷移時，請特別檢查 fake-ip 與 redir-host 模式、監聽位址、IPv6 開關，以及 TUN 下的 DNS 劫持設定。

常見的混合代理監聽連接埠是 7890，DNS 監聽範例則可能使用 0.0.0.0:1053。連接埠並非固定標準，最後仍應以設定檔與客戶端介面為準。若本機已有程式佔用 7890、9090 或 1053，核心日誌通常會出現 address already in use；此時應修改衝突的連接埠，而不是將問題歸咎於訂閱。

TUN：決定更多應用程式能否被接管

系統代理主要涵蓋會主動讀取代理設定的應用程式，部分遊戲、命令列程式與 UDP 流量可能繞過它。TUN 模式透過虛擬網路介面接管更廣泛的系統流量，因此更依賴核心的網路堆疊、路由設定與 DNS 協作。目前使用 TUN 時，mihomo 是較常見的選擇。

啟用路徑因客戶端而異，常見入口是「設定」→「網路設定」→「TUN 模式」，或主介面的「服務模式」與「TUN」開關。Windows 首次啟用通常需要系統管理員權限；macOS 可能要求核准網路延伸功能；Linux 則需要正確的 CAP_NET_ADMIN 權限，或以適當的服務方式執行。啟用後應一併檢查區域網路存取、DNS 解析與睡眠喚醒，而不是只驗證一個瀏覽器頁面。

將舊設定遷移至 mihomo 時要檢查什麼

從原版遷移至 mihomo 通常比反向遷移順利，但「能夠啟動」只是第一步。訂閱提供者、客戶端與本機覆寫都可能修改設定，最好按照固定順序排查。

先確認實際核心。 在客戶端中開啟「設定」→「核心」或「設定」→「關於」，記下名稱、版本號與架構。命令列環境可執行 mihomo -v；舊版原版可執行檔通常使用 clash -v。
保留原設定副本。 備份 YAML、規則集網址、本機覆寫與自建策略群組。只儲存訂閱連結，不一定包含本機新增的規則。
先進行語法測試。 mihomo 可使用 mihomo -t -f config.yaml 檢查設定。測試通過代表結構可讀取，不代表每個遠端規則集與代理節點都能連線。
核對代理群組引用。 每條規則末尾的策略名稱都必須存在於 proxy-groups。例如規則寫了 Proxy，但設定中只有「節點選擇」，核心就會回報找不到策略。
檢查外部資源。 proxy-providers、rule-providers、GEOIP 與 GEOSITE 資料需要能夠下載並寫入快取目錄。更新失敗時開啟「設定」→「日誌」，查看 HTTP 狀態碼、逾時資訊與檔案權限。
最後再啟用 TUN。 先使用系統代理驗證 7890 監聽、節點連線與規則分流，再啟用 TUN。這樣可以將節點問題與系統路由問題分開。

如何讓基礎設定維持較高相容性

需要在多台裝置之間共用設定時，可將通用部分限制在基本欄位，並把 mihomo 擴充內容放入獨立覆寫。以下骨架使用混合連接埠 7890、本機控制介面 127.0.0.1:9090 與規則模式，適合作為排查結構的起點。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090

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

rules:
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

這段範例沒有真實代理節點，因此 Proxy 群組暫時只包含 DIRECT。實際使用時，應由訂閱或本機設定加入節點。不要直接將網路上的設定控制介面改成 0.0.0.0:9090；若確實需要區域網路控制，應同時設定存取金鑰並限制防火牆範圍。

2026 年安裝客戶端應該選擇哪個核心

若是新安裝，優先選擇仍在維護且明確使用 mihomo 的客戶端。原因不只是名稱較新，而是它能持續適配目前的節點協定、規則資料、DNS 行為與作業系統網路變化。尤其當訂閱包含 VLESS、Reality、Hysteria2、TUIC，或計畫使用 TUN、GEOSITE、IP-ASN 時，mihomo 更符合設定預期。

適合直接選擇 mihomo 的情況

首次安裝 Clash 類客戶端，希望正常接收後續核心修正與功能更新。
訂閱中包含 VLESS、Reality、Hysteria2 或 TUIC 節點。
需要使用 TUN 接管遊戲、命令列工具、UDP，或不讀取系統代理的應用程式。
規則使用 GEOSITE、IP-ASN、NETWORK、IN-TYPE 等擴充條件。
需要依網域設定不同的 DNS 上游，或使用更細緻的 fake-ip 排除策略。

仍可能保留原版的情況

隔離環境中的既有設定已穩定運作，且只使用基本協定與基本規則。
某個舊客戶端與自動化腳本固定依賴原版命令參數，遷移前需要先進行相容性測試。
短期重現歷史問題，需要維持與當時相同的核心及設定行為。

這些情況較適合「暫時保留並安排遷移」，而不是將原版作為新裝置的預設選擇。舊環境至少應記錄客戶端版本、核心版本、設定來源與連接埠使用情況，避免裝置重灌後無法還原。

選擇客戶端時檢查這六項

核心名稱與版本：明確標示 mihomo，並能在「設定」→「核心」查看目前版本。
設定管理：能區分訂閱原文、本機覆寫與執行時設定，避免更新訂閱時覆蓋手動修改。
日誌入口：至少提供 info、warning、error 等級，能查看節點、DNS、規則集與連接埠錯誤。
TUN 管理：能顯示服務狀態、權限要求與失敗原因，而不只是一個開關。
平台架構：Windows 區分 x64 與 ARM64，macOS 區分 Apple Silicon 與 Intel，Linux 則確認 amd64、arm64 及安裝方式。
更新範圍：客戶端更新、核心更新、GEO 資料更新與訂閱更新應分別顯示，方便定位是哪一層發生變化。

常見誤區與排查結論

「設定能匯入」不等於「所有欄位都會生效」

YAML 語法正確，只代表縮排與結構可以解析。有些客戶端還會在匯入階段刪除未知欄位，或使用本機覆寫取代訂閱內容。要判斷功能是否生效，應查看執行時設定與核心日誌。例如加入 GEOSITE 後沒有任何規則命中記錄，就需要確認規則資料是否載入、規則順序是否正確，以及實際核心是否支援這種類型。

「Meta」和「mihomo」不是兩條並行的升級路線

在目前的語境中，mihomo 是 Clash.Meta 改名後的專案名稱。下載時不必尋找所謂「Meta 版與 mihomo 版的效能比較」。真正需要核對的是發行日期、版本號、處理器架構，以及客戶端是否仍在呼叫多年未更新的核心檔案。

版本越新，也要先測試設定

持續維護的核心會修正問題，也可能調整預設行為、淘汰欄位或加強設定驗證。升級前應匯出設定，升級後依序測試訂閱更新、策略群組、DNS、系統代理與 TUN。企業網路、校園網路及使用本機 DNS 的環境，尤其要檢查內網網域與區域網路網段是否仍能直連。

最終選擇可以濃縮成一句話

新裝置與新設定優先使用 mihomo；舊版原版環境若仍有業務依賴，可以先保留、記錄版本並逐項遷移。Clash.Meta 與 mihomo 主要是改名前後的名稱關係，而客戶端名稱只是外殼，真正決定協定、規則、DNS 與 TUN 能力的是正在執行的核心。