Clash 原版核心、Clash Meta 與 mihomo 功能差異及設定相容性比較

核心沿革：原版 Clash、Premium 與 Meta 分支

選擇 Clash 用戶端時，介面名稱和核心名稱要分開確認。用戶端負責訂閱管理、系統代理切換、設定合併與記錄檢視；核心則負責建立代理連線、比對規則及處理 DNS。同一個用戶端可能會更新內建核心，也可能允許切換核心。光看軟體名稱，無法判斷某個 VLESS 節點或某段 TUN 設定是否可用。

原版 Clash 還要區分開源核心與 Clash Premium。Premium 是原專案的另一個發行系列，曾提供 TUN、規則集等擴充功能，不能把這些功能一概算在原版開源核心上。原專案於 2023 年停止維護後，舊用戶端與舊版執行檔仍可能運作，但不適合再作為新設定功能的參考。

Clash Meta 是從 Clash 發展而來的分支，後來更名為 mihomo。因此，Meta 和 mihomo 主要是同一條技術路線在不同階段使用的名稱，並非兩個互不相容的獨立產品。舊教學中的「Meta 核心」、訂閱中的「Clash Meta 格式」，通常都指這條擴充路線；實際功能仍取決於執行中的發行版本。

功能比較：協定、規則、TUN 與 DNS

下表比較的是功能範圍，並非每個歷史版本的完整清單。「支援」也必須同時符合伺服器參數、用戶端封裝方式與作業系統權限等條件。尤其不能把目前 mihomo 的功能套用到任何早期 Meta 版本。

功能	原版開源 Clash	Clash Premium	Meta／mihomo 路線
常見代理協定	支援 SS、VMess、Trojan、SOCKS、HTTP 等；可用參數視版本而定	以原專案的支援範圍為基礎	擴充支援 VLESS、Hysteria2、TUIC 等；請確認版本與參數
基本分流	支援網域、IP 網段、GEOIP 等常見規則	支援基本規則與擴充功能	保留常用規則，並擴充 GEOSITE、邏輯規則等功能
規則集	不能假設支援 Premium 的 RULE-SET 設定	支援 rule-providers 與 RULE-SET	支援規則集；格式與行為須符合設定
TUN 接管	不具備與 Premium 同等的內建 TUN 功能	提供 TUN，支援的平台與版本各有差異	提供 TUN；網路堆疊、路由與權限須分別確認
DNS	支援內建 DNS 與 Fake-IP 等基本機制	以原專案的 DNS 功能為基礎，搭配擴充功能	擴充解析策略與連線解析控制，欄位會隨版本演進
維護狀態	歷史專案，已停止維護	歷史發行系列，已停止維護	請以 mihomo 專案目前的發行記錄為準

協定支援與能否開啟訂閱檔是兩回事

YAML 能讀取，只代表基本格式正確。假如訂閱包含 type: vless，卻交由不支援 VLESS 的舊核心處理，可能會造成節點解析失敗，甚至整份設定載入失敗。Reality 是相關協定的傳輸安全設定，並非與 VLESS、Trojan 並列的節點類型。遷移時應一併確認 type、network、TLS 與相關傳輸選項。

訂閱服務標示「Clash」，也不能證明與原版 Clash 相容。有些服務以這個名稱泛指 YAML 輸出格式，實際內容早已包含 mihomo 擴充欄位。若服務明確提供 Meta 或 mihomo 輸出格式，請依目標核心選擇；轉換工具只能轉換支援的資料結構，無法讓舊核心取得尚未實作的協定功能。

設定相容性：可沿用的結構與需檢查的欄位

常見的 proxies、proxy-groups、rules 結構通常可以沿用。基本的 DOMAIN-SUFFIX、IP-CIDR、MATCH 規則也不必因為更名而全部重寫。遷移時的重點是確認擴充欄位是否受支援，以及用戶端最後產生了什麼設定。

逐項檢查清單

本機連接埠：檢查 port、socks-port 與 mixed-port。例如統一使用 mixed-port: 7890 時，系統代理和需要手動設定的應用程式都應指向實際監聽的連接埠，不能繼續沿用舊環境的 7897。
控制介面：external-controller 是管理 API，不是應用程式的代理入口。若使用 127.0.0.1:9090，請勿把瀏覽器代理設定為 9090。僅供本機管理時，請保留迴送位址並設定存取密鑰。
規則引用：RULE-SET 引用的名稱必須與 rule-providers 中的鍵一致；GEOSITE 也需要相應的資料檔。資料下載失敗與規則語法錯誤應分開處理。
規則目標：每條規則引用的策略組都必須存在。將「自動選擇」改名為「延遲優選」後，也要同步更新規則與其他群組中的引用。
腳本設定：不要直接沿用 Premium 的 script 分流實作。用戶端提供的 JavaScript 覆寫是在產生設定時執行，與核心處理連線時執行的腳本並非同一機制。
介面專用設定：舊用戶端的設定合併、設定檔擴充與啟動選項，不等同於 mihomo 原生 YAML。遷移時應搬移這些設定所產生的有效結果，而非把所有舊檔案整批複製。

先用獨立設定確認連接埠與規則

以下是本機診斷範本，不含可用的代理節點。僅用於確認核心能否啟動、7890 連接埠是否能監聽，以及基本規則能否載入。MATCH,DIRECT 會讓未比對到規則的流量直接連線，不能把它當成已設定完成的代理方案。

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

proxies: []
proxy-groups: []

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,DIRECT

先測試這個範本，再分批加入實際節點、策略組和規則集。如此一來，啟動錯誤就能定位到新增內容，不必在包含數千條規則的訂閱檔中同時排查多個變因。

TUN 遷移：分別檢查權限、路由與 DNS 接管

系統代理主要供遵循系統代理設定的應用程式使用；TUN 則透過虛擬網卡接管流量。切換核心後，即使 TUN 開關顯示已啟用，也不代表虛擬網卡、路由和 DNS 劫持都已成功。Windows 通常需要服務模式或管理員權限，Linux 需要網路管理權限，macOS 也須取得相應授權；實際設定位置取決於用戶端的實作方式。

不要照搬舊教學中的 TUN 預設值。stack、自動路由與介面偵測是否適用，會受到平台、核心版本和其他網路軟體影響。以下 mihomo 設定僅列出常用欄位；首次測試時仍應維持 enable: false，待系統代理路徑確認正常後再啟用。

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

先確認權限：若記錄顯示建立網卡或新增路由失敗，請先檢查服務與權限，而不是更換節點。
再確認出口：同時執行其他 VPN、虛擬機網路或容器網路時，自動介面偵測可能選錯出口。請暫時停用其他接管工具，再比較結果。
最後檢查 DNS：any:53 是針對一般 53 埠 DNS 流量，不會自動解密瀏覽器內建的 HTTPS DNS。後者可能成為一般 HTTPS 連線，再由規則決定流量出口。

TUN 也無法補足節點本身缺少的 UDP 能力。遊戲或語音應用程式仍有異常時，應分別檢查節點協定、伺服器的 UDP 支援、策略組路由和本機防火牆，不要只是不斷切換 TUN 網路堆疊。

DNS 與 Fake-IP：欄位相容不代表解析路徑相同

原版 Clash 已具備 Fake-IP 機制，不能把 Fake-IP 視為 mihomo 獨有功能。其運作方式是先回傳虛擬位址，再由核心根據對應關係還原網域並處理連線。遷移後若 DNS 查詢未送到核心，或應用程式仍快取舊結果，即使 YAML 中的 enhanced-mode 沒有變更，實際行為仍可能不同。

依用途保留 DNS 欄位

nameserver 用來設定一般的上游解析器。若使用網域名稱格式的加密 DNS 上游，也要考慮上游位址本身如何進行初始解析。
nameserver-policy 依網域條件選擇解析器；它不是代理分流規則，不能直接取代 rules。
fake-ip-filter 用來指定哪些網域不回傳 Fake-IP。請只針對有相容性問題的網域精確加入例外，避免使用大範圍萬用字元，讓整套方案退回真實位址解析。
fallback 與 fallback-filter 是另一組解析器選擇機制，並非所有設定都必須啟用。舊設定中有這些欄位，不代表遷移時要照抄所有地區篩選條件。

以下展示 Fake-IP 與網域解析策略的最小組合。example.com 是文件範例網域；替換時應填入確實需要獨立解析的服務網域。1053 是本機 DNS 監聽連接埠，不是系統預設的 53 埠；單獨啟動監聽器不會自動變更系統 DNS。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 1.1.1.1
  nameserver-policy:
    '+.example.com':
      - 1.1.1.1
  fake-ip-filter:
    - '*.lan'

測試時可使用支援的等效指令，執行 nslookup example.com 127.0.0.1 -port=1053；各系統的參數順序與實作可能不同，若環境支援 dig，也可直接執行下方查詢。命中 Fake-IP 時，結果應位於所設定的虛擬位址範圍；但回傳真實位址也可能是篩選項所致，不能只憑單一位址判定是否有 DNS 洩漏。

dig @127.0.0.1 -p 1053 example.com A

也應查看核心記錄是否收到查詢，並比對系統 DNS、瀏覽器安全 DNS 與連線出口。線上檢測頁面列出的解析器歸屬只是觀察結果之一：解析器所在地與代理出口所在地不同，單憑這點無法證明請求繞過了預期路徑。

遷移順序：離線測試、逐步還原與回復

遷移時不必同時更換用戶端、訂閱格式、DNS 方案和規則來源。維持相同節點與測試目標，先完成最小幅度的切換，再逐步還原擴充功能，才能有效比較結果。

備份目前的運作設定。保存訂閱原始檔、用戶端覆寫內容、目前生效的設定及核心版本輸出。記錄本機代理連接埠（例如 7890），以及是否啟用系統代理、TUN 和區域網路存取。含有節點密碼與訂閱憑證的檔案，只能存放在可信任的位置。
確認目標執行檔。執行版本指令並記錄實際輸出，不要只根據安裝套件名稱推測。桌面用戶端內附的核心，可能與獨立下載的版本不同。
執行設定測試。先檢查語法與引用。測試通過後再啟動；若錯誤指出策略組不存在，應先修正名稱引用，不要同時變更 DNS。
確認系統代理路徑。關閉 TUN，載入一個確定可用的實際節點。使用明確指定代理的請求檢查監聽連接埠、交握與出口，再測試系統代理開關。
還原規則與 DNS。逐一加入規則集，確認記錄中的比對規則與目標群組。接著檢查 DNS 查詢路徑，最後再啟用 TUN。
保留可回復的狀態。新設定出現問題時，先關閉新用戶端的 TUN 與系統代理，再還原舊環境。不要讓兩套用戶端同時搶用相同的連接埠或虛擬網卡路由。

命令列驗證範例

以下以執行檔名稱為 mihomo、設定檔位於目前目錄且名稱為 config.yaml 為例。在 Windows PowerShell 中，本機執行檔通常需寫成 .\mihomo.exe；使用桌面用戶端時，應測試它實際載入的設定，而不只是測試下載的訂閱檔。

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

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

-t 檢查通過，不代表遠端節點可以連線。上述請求設定 10 秒連線逾時與 20 秒總逾時，是為了避免故障時無限等待，不是速度基準。若目前使用前面的直連診斷範本，這個請求也只能驗證本機代理入口，無法證明流量經過遠端節點。

核心選型結論與故障排查範圍

需要 VLESS、Hysteria2、TUIC 或新版規則功能時，應優先確認 mihomo 對應版本是否支援，不要在原版核心中反覆嘗試新增欄位。維護舊環境時，則應將設定限制在原核心已實作的功能範圍內，避免訂閱更新後突然出現無法解析的節點。

從 Clash Meta 遷移至 mihomo，主要應檢查版本差異與用戶端產生設定的方式；從原版或 Premium 遷移至 mihomo，還要確認腳本、規則集、DNS 與 TUN 的實作差異。沒有一套通用的「全部替換欄位」規則；最可靠的做法仍是確認版本、檢查有效設定，並逐層測試連線。

選擇用戶端時，可接著查看用戶端平台與核心比較；若要了解規則語法與設定結構，可參閱協定手冊。保留一份能說明每個欄位用途的設定，比疊加多份來源不明的覆寫更容易維護。