進階設定 預計閱讀 12 分鐘

mihomo 與原版 Clash 核心差異：新增協定、規則集語法與 TUN 實作比較

比較 mihomo（原 Clash Meta）與原版核心的差異：VLESS、Hysteria2 等協定、rule-providers 語法，以及 TUN 堆疊和 DNS 行為。

先釐清核心、客戶端與 Clash Premium

比較核心前，先釐清三個層次。核心負責解析設定、建立代理連線、處理 DNS 與比對規則；桌面或行動裝置客戶端負責管理設定、系統匣選單、更新訂閱及申請權限；訂閱則提供節點、策略組與規則資料。客戶端名稱中有 Clash，不代表它執行的是原版 Clash，也不代表支援所有 mihomo 設定。

原版 Clash 開源核心與 Clash Premium 的功能也不相同。Premium 是原專案提供的閉源增強核心，過去包含 TUN、規則集等進階功能。mihomo 是從 Clash Meta 延續而來的開源核心，保留許多 Clash 風格的 YAML 設定結構，並持續擴充協定、路由與 DNS 功能。原專案已停止維護，遷移時應依實際執行的二進位版本確認，不要把舊客戶端名稱當成功能清單。

對象主要職責確認位置
原版 Clash 開源核心傳統代理協定、策略組與規則分流核心版本與設定解析記錄
Clash Premium原版基本功能與過往增強功能Premium 建置日期與對應文件
mihomo新增協定、規則集擴充、TUN 與 DNS 設定實際執行的 mihomo 版本
圖形介面客戶端匯入訂閱、啟動核心、管理權限與覆寫設定客戶端設定、啟動記錄與執行設定

用指令確認實際版本

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

第一個指令可查看目前二進位檔的版本資訊；第二個指令指定工作目錄與設定檔，執行設定測試。這些檔案必須事先存在；測試通過只代表設定可被解析，不代表節點可用。圖形介面客戶端可能使用內建核心，終端機中的 mihomo 不一定與客戶端啟動的檔案相同，也應一併檢查客戶端記錄。

新增協定：VLESS、REALITY 與 Hysteria2

mihomo 與舊核心最直接的差異，在於能否辨識訂閱中的節點類型及其參數。原版 Clash 常見的協定包括 Shadowsocks、VMess、Trojan、SOCKS 和 HTTP。mihomo 擴充支援 VLESS、Hysteria2、TUIC 等協定，也支援特定協定組合中的 REALITY。不能只把 YAML 的 type 改掉，就將舊節點轉換成另一種協定；伺服器端必須提供相應的連線入口。

功能mihomo 設定重點常見誤解
VLESS確認 UUID、傳輸方式、TLS 與 flow直接將 VMess 節點的類型改成 VLESS
REALITY確認伺服器端要求的 SNI、公鑰與 short-id將 REALITY 當成獨立的節點類型
Hysteria2使用 type: hysteria2，確認密碼與 TLS 參數沿用 Hysteria 第一代的整份設定
TUIC確認伺服器版本、驗證欄位與 UDP 連線狀態只測試 TCP 連接埠就判定節點正常

分別檢查協定支援與網路條件

Hysteria2 與 TUIC 使用 QUIC，連線仰賴 UDP。區域網路、防火牆或電信業者線路若限制 UDP，即使設定測試通過，也可能發生交握逾時。VLESS 是否可用則須視實際傳輸方式判斷，不能把所有 VLESS 節點都視為相同的網路行為。協定名稱本身也無法保證延遲更低或吞吐量更高。

  • 顯示不支援節點類型：先確認客戶端是否確實啟動 mihomo，以及訂閱是否針對該核心輸出。
  • 顯示驗證失敗：確認 UUID、密碼與伺服器協定版本，不要先修改 DNS。
  • 顯示 TLS 交握錯誤：確認系統時間、SNI 與憑證要求，不要把略過憑證驗證當成一般修復方式。
  • QUIC 節點持續逾時：換個網路進行交叉測試，再檢查 UDP 對外連線與伺服器狀態。

rule-providers：沿用架構，確認 behavior 與 format

rule-providers 並非 mihomo 獨有，Clash Premium 也支援這項機制。遷移時通常可以沿用「宣告規則集，再以 RULE-SET 引用」的基本架構。規則集用來描述比對目標，而 rules 中的引用則指定命中後採用的策略；兩者不要混在一起。

本機 domain 規則集範例

請將以下片段合併至現有設定中使用。此設定會將範例網域規則導向 DIRECT，不依賴節點名稱。工作目錄中必須有 rules/local-domains.yaml 檔案；若已有 rule-providers 或 rules，應合併內容，不要重複建立同名的頂層鍵。

rule-providers:
  local-domains:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/local-domains.yaml

rules:
  - RULE-SET,local-domains,DIRECT
  - MATCH,DIRECT

rules/local-domains.yaml 的檔案內容：

payload:
  - '+.example.com'
  - 'intranet.example.net'

+.example.com 用來比對該網域及其子網域。此範例採用直連作為預設策略，只示範引用方式，不能直接取代現有訂閱中的代理設定。實際遷移時，應保留自己的代理策略組與末尾的預設規則。

三種 behavior 不能互換

  • domain：項目是網域或支援的網域比對表示式，不含 DOMAIN-SUFFIX 前綴。
  • ipcidr：項目是 IP 網段，例如 192.168.0.0/16，不是完整的規則語句。
  • classical：項目是規則表示式，例如 DOMAIN-SUFFIX,example.com，通常不會在項目結尾寫上策略名稱。

如果把 DOMAIN-SUFFIX,example.com 放進 behavior: domain 的檔案，即使 YAML 縮排正確，內容格式仍不相符。檢查規則集時，應同時查看提供者宣告與下載後的檔案，不要只看副檔名。

mihomo 支援的規則集格式

mihomo 支援 YAML、純文字及 MRS 等規則集格式。MRS 是規則集專用的二進位格式，適用於 domain 與 ipcidr，不適用於 classical。不能因此推定舊版 Premium 設定可以直接讀取 MRS。採用這些格式前，應確認所用 mihomo 版本及規則來源的說明，避免將較新的設定欄位複製到舊核心中。

規則仍然依序由上而下比對。若將 MATCH 放在規則集引用前，後續規則就無法正常參與比對。排查分流錯誤時，優先查看連線詳細資訊中的命中規則與實際策略，不要只看策略組目前選取的節點。

TUN 實作：堆疊選擇、路由接管與系統權限

系統代理與 TUN 的流量入口不同。系統代理會讓遵循系統設定的應用程式連至代理連接埠；TUN 則會建立虛擬網路介面，配合路由規則接收 IP 流量。TUN 較適合處理不遵循系統代理設定的應用程式，但特定連線是否會被接管，仍受路由、介面選擇、排除項目及作業系統權限影響。

原版開源 Clash 與 Premium 支援的 TUN 功能範圍不同，不能一概而論地說「所有 Clash 都有 TUN」。Premium 過去的 TUN 方案與 gVisor 堆疊有關；mihomo 則提供 system、gvisor、mixed 等堆疊選項。實際支援範圍須依平台與版本而定，不能直接套用其他核心的 TUN 設定區段。

stack 值處理方式選擇建議
system採用與系統網路堆疊相關的實作先使用客戶端預設值建立可運作的基準
gvisor透過使用者空間網路堆疊處理流量用於比對相容性，不預設一定較快
mixed結合 system 的 TCP 與 gVisor 的 UDP 處理方式確認目前平台支援後再進行測試

桌面環境的設定片段

mixed-port: 7890
allow-lan: false
mode: rule

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

此處的 7890 是範例混合代理連接埠，並非所有客戶端的固定值。auto-route 用於自動設定路由，auto-detect-interface 則協助選擇對外介面；這些設定不能取代權限授予。Windows 通常需要透過客戶端服務或提權機制；Linux 需要適當的網路管理權限；macOS 則須依客戶端實作完成授權。

  1. 關閉其他 VPN 或另一個代理客戶端的 TUN，先減少路由衝突。
  2. 先確認系統代理模式可正常運作，再單獨啟用 TUN，避免同時引入兩組問題。
  3. 檢查記錄是否出現建立虛擬介面失敗、加入路由失敗或權限不足等訊息。
  4. 切換 Wi-Fi、有線網路或從休眠狀態恢復後，重新檢查對外介面與路由。

DNS 與 Fake-IP：保留機制，重新確認解析路徑

Fake-IP 並不是 mihomo 新增的功能。它會透過位址映射建立網域與連線之間的關聯，協助核心依網域比對規則。遷移時真正需要留意的是：DNS 查詢是否進入核心、哪些網域需要回傳真實位址，以及代理伺服器網域使用哪條解析路徑。

分開測試 DNS 與 TUN

dns:
  enable: true
  listen: 127.0.0.1:7874
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - '*.lan'
    - 'localhost'
  nameserver:
    - 223.5.5.5
    - 119.29.29.29

以下片段用來示範解析行為：DNS 監聽本機的 7874，Fake-IP 使用 198.18.0.1/16 範圍，上游則是兩個明確的 IPv4 DNS 位址。上游 DNS 應依實際網路與隱私需求選擇，這裡列出的位址不保證適用於所有線路。fake-ip-filter 只會排除 Fake-IP 位址分配，不代表強制直連規則，也不能取代本機 DNS 伺服器設定。

在已安裝 dig 的環境中，可直接查詢核心 DNS：

dig @127.0.0.1 -p 7874 example.com A

未命中篩選項目時，回應通常會出現設定範圍內的映射位址。這是預期的運作方式，不代表網域伺服器回傳了錯誤的公網 IP。接著連線至該網域，再檢查核心連線記錄，確認連線能對應到網域並命中預期規則。

加密 DNS 與節點網域解析

  • 瀏覽器獨立 DoH：瀏覽器可能會繞過系統 DNS 路徑。排查時先統一 DNS 解析入口，再比較結果。
  • TUN 的 DNS 劫持：any:53 用於傳統 DNS 流量，不能解讀成可自動接管所有 DoH、DoT 要求。
  • 節點網域解析：mihomo 可透過 proxy-server-nameserver 指定代理伺服器網域的解析器，減少啟動時解析路徑彼此依賴的問題。
  • 規則影響 DNS 對外連線：respect-rules 等設定會改變 DNS 連線的路由行為。必須依目前版本說明搭配設定，不能只啟用單一選項。

區域網路服務存取異常時，應確認本地域名後綴、路由器 DNS 與網段規則。只新增 *.lan 無法涵蓋企業內部使用的所有網域。切換增強模式後，也要考量瀏覽器、系統與應用程式快取；快取中舊的映射位址可能會短暫保留。

從 Clash Premium 遷移至 mihomo 的自我檢查步驟

遷移的重點不是重寫所有規則，而是找出依賴舊核心的部分。大多數基本欄位、傳統節點與規則語句都可作為起點，但不應原封不動保留 Premium 的腳本設定、舊實驗性欄位及特定 TUN 參數。mihomo 不能視為 Premium 腳本介面的直接替代品。

  1. 備份設定與執行環境：保留目前可用的 YAML，記錄監聽連接埠、選用的策略組、系統代理與 TUN 狀態。訂閱網址應存放於安全的位置，切勿公開分享。
  2. 確認訂閱輸出格式：優先使用服務提供者提供的 mihomo 或 Clash Meta 格式。若節點使用 VLESS、Hysteria2，請確認協定參數完整。
  3. 執行設定測試：執行 mihomo -t，先處理未知協定、欄位型別、規則檔案路徑與策略名稱錯誤。
  4. 只測試系統代理：先關閉 TUN，使用指定連接埠驗證節點與規則。例如實際連接埠為 7890 時，可將支援代理的應用程式設為使用 127.0.0.1:7890。
  5. 確認規則集：檢查 behavior、format、本機檔案內容與規則順序，並確認引用的策略組確實存在。
  6. 分別啟用 DNS 與 TUN：依序檢查權限、介面、路由與解析。每次只變更一個變數，並保留記錄以便前後比對。
  7. 確認客戶端覆寫設定：檢查最終執行的設定。客戶端可能會合併連接埠、DNS、TUN 或規則設定，因此編輯訂閱來源檔案不一定會改變實際執行值。

在可重現的條件下比較速度

擴充協定不代表速度會自動提升。比較兩個核心時，應固定節點、測試目標、網路與測試時段，並記錄單一連線下載速度、並行處理效能及 CPU 使用率。延遲測試只反映對指定目標的一次請求耗時，不能取代大型檔案的傳輸量測，也無法證明所有網站都使用同一條線路。

若需要新增協定、持續更新的規則集功能或更細緻的 DNS 設定，mihomo 是值得優先確認的核心。若只需要傳統協定與簡易系統代理，選擇時仍應著重客戶端的維護狀態、目前的系統相容性，以及設定是否容易管理。可先在術語表確認 Fake-IP、策略組與規則集的概念，再依照設定教學逐步測試。

下載 Clash