核心解析 預計閱讀 12 分鐘

mihomo 核心有哪些新功能？與原版 Clash 的功能差異一覽

整理 mihomo 新增的協定支援、規則集與 GEO 資料處理、TUN 強化等功能，並比較原版 Clash 的設定方式差異。

比較範圍：原版 Clash、Premium 與 mihomo

mihomo 是 Clash Meta 專案更名後採用的核心名稱。它沿用 Clash 的 YAML 設定架構，並持續擴充出站協定、規則表達方式、DNS 與流量接管功能。用戶端視窗仍顯示「Clash」或「Meta」，不代表目前執行的就是原版 Clash；介面名稱、設定格式名稱與核心名稱應分開判斷。

本文所稱的「原版 Clash」，限定為原專案停止維護前的開源核心，不包含 Clash Premium 的功能。Premium 曾提供 TUN、規則提供者等擴充功能，因此「原版開源核心沒有某項功能」，不代表歷來所有 Clash 分支都沒有。這項區分對舊設定檔的移轉尤其重要。

功能原版開源 Clashmihomo
HTTP、SOCKS、SS、VMess、Trojan 等常見出站協定支援，實際參數依版本而異沿用支援，並擴充部分參數
VLESS、REALITY、Hysteria2、TUIC無法直接使用 mihomo 的設定寫法支援，須符合協定與伺服器端參數
規則提供者 rule-providers不是原版開源核心的通用功能支援多種行為類型與檔案格式
GEOSITE 與邏輯規則不支援 mihomo 對應的擴充寫法支援，須準備相應資料或規則
TUN 流量接管與 DNS 劫持不提供 mihomo 這套設定方式支援，會受系統權限與路由環境影響
Fake-IP DNS已有相關功能沿用並擴充，並非首次導入

協定擴充：先看訂閱中的 type，再檢查傳輸參數

最容易察覺的差異是新增了出站協定。舊版核心遇到 type: hysteria2 或 type: vless 時，可能在載入階段就回報不支援的代理類型。調整策略群組或規則順序都無法解決，因為出站連線根本尚未建立。

VLESS 與 REALITY 並非可互換的節點類型

VLESS 是代理協定；REALITY 則是可用於相應出站設定的安全握手機制。在 mihomo 中，VLESS 節點通常以 type: vless 宣告，REALITY 相關設定則位於 reality-opts。直接把節點類型改成 reality，並不等於完成轉換。

  • uuid 是驗證參數，必須與伺服器端設定一致。
  • servername、reality-opts.public-key 和 short-id 必須依照伺服器端提供的資訊填寫，不能只憑網域名稱猜測。
  • flow、傳輸方式與指紋選項之間也有搭配限制；只新增一個欄位，無法將既有的 VMess 節點轉成 VLESS 節點。

Hysteria2 與 TUIC 需要可用的 UDP 連線

Hysteria2 與 TUIC 都以 QUIC 為基礎，能否建立連線不只取決於核心是否支援。如果目前的網路封鎖或嚴格限制 UDP，TCP 節點可用，但這兩類節點逾時並不矛盾。Hysteria 與 Hysteria2 也不是只改名稱的同一套設定，請依訂閱實際宣告的協定類型設定。

例如伺服器端監聽 UDP 443 時，請確認本機防火牆、上游網路及伺服器安全性群組都允許該連接埠。瀏覽器可透過 TCP 443 開啟網頁，不代表同一個位址上的 UDP 通道也能使用。也不要將切換協定說成一定能加速：鏈路封包遺失、伺服器容量與限速策略都會影響結果。

規則集擴充：從內嵌 rules 到獨立維護的資料檔案

原版 Clash 已具備依序比對的規則機制，mihomo 並未改變「第一條符合的規則決定出站」這項基本邏輯。擴充之處主要在規則來源與表達能力：可透過 rule-providers 管理外部規則集，再以 RULE-SET 引用；也能使用 AND、OR、NOT 等邏輯規則組合條件。

本機規則提供者的基本結構

以下兩段請分別存成主設定檔與規則檔。範例只使用 DIRECT，用於確認規則載入結構，不會自動建立代理節點。請先在工作目錄建立 rules 資料夾，再將檔案放入其中；相對路徑會依核心執行環境解析，不一定是桌面上看到的訂閱檔位置。

# 主設定檔中的相關片段
rule-providers:
  work-domains:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/work-domains.yaml

rules:
  - RULE-SET,work-domains,DIRECT
  - MATCH,DIRECT
# ./rules/work-domains.yaml
payload:
  - '+.example.com'
  - 'example.org'

behavior: domain 表示檔案內容採用網域比對模式，不應直接在其中混入 IP-CIDR,192.168.0.0/16。若要在同一個規則集中放入多種規則語句，請選擇 classical，並依其格式整理內容。

  • domain：適合用來整理網域清單。
  • ipcidr：適合用來整理 IP 網段清單。
  • classical：適合包含多種規則類型的規則集。
  • mrs：是 mihomo 支援的二進位規則格式，主要適用於 domain、ipcidr 行為；並非將任意 YAML 檔案改個副檔名就能使用。

規則提供者與節點提供者也不能混為一談。rule-providers 提供比對條件，proxy-providers 提供代理節點。訂閱更新成功，只代表對應資源已完成更新，不代表另一類資源也已下載或生效。

GEO 資料：GEOIP 查 IP 位址，GEOSITE 查網域分類

GEOIP 規則並非 mihomo 獨有；原版 Clash 已能根據地理資料比對 IP。mihomo 的改進之一，是加入 GEOSITE 等資料驅動功能，並提供不同的 GEO 資料載入與更新選項。兩者比對的目標不同，不能只替換關鍵字，就期待結果相同。

規則範例比對依據使用前檢查
GEOIP,CN,DIRECT目標 IP 在資料庫中的項目資料檔可讀；網域連線可能需要解析
GEOSITE,cn,DIRECT網域是否屬於指定分類已載入 GEOSITE 資料，且包含 cn 分類
GEOIP,CN,DIRECT,no-resolve已有目標 IP 的地理資訊不會為了這條規則額外解析網域

geodata-mode: true 用來切換 GEOIP 的資料處理方式，通常會用到 GeoIP.dat；另一種預設方式則使用 MMDB 資料。GEOSITE 使用自己的網域分類資料，開啟 GEOIP 模式後，並不會因此取得所有網域分類。請一併確認資源檔、核心版本與分類名稱。

不要把 cn 當成即時網路測量結果。資料集由維護者整理，網域是否歸入某個分類、某段 IP 的歸屬，都可能隨版本變動。若發生分流錯誤，請先確認實際命中的規則與本機資料更新時間，再決定是否新增一條優先順序更前面的精確網域規則。

TUN 強化：接管範圍不代表所有流量都走代理

系統代理通常只會影響遵循系統代理設定的應用程式；TUN 則透過虛擬網路介面與路由接管更多 IP 流量。mihomo 的 TUN 功能適合處理不讀取系統代理設定的程式，但仍會受到路由、權限與規則影響。啟用 TUN 後，符合 DIRECT 規則的連線仍會直接連線。

# 合併至既有且可正常連線的 mihomo 設定檔
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53

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

這段設定只示範流量接管與 DNS 的關聯，不包含代理節點。1053 是內建 DNS 的監聽連接埠；dns-hijack 中的 53 是要攔截的傳統 DNS 目標連接埠，兩者不必使用相同數字。範例中的上游 DNS 僅供示範，實際使用時請改成可連線且符合網路政策的 DNS 解析服務。

分別檢查 stack 與權限

  • system、gvisor、mixed 分別採用不同的協定堆疊處理方式；mixed 通常以系統堆疊處理 TCP、以 gVisor 處理 UDP。是否可用仍須依目前平台與版本確認。
  • Windows 通常需要系統管理員權限，或由用戶端安裝特權服務；Linux 通常需要相應的網路管理權限，並確認 /dev/net/tun 可用；macOS 則須依用戶端要求授權。
  • auto-route 會調整路由設定。若同時使用其他 VPN、虛擬機網路或企業連線工具，請先關閉另一套流量接管工具，再進行對照測試。
  • 應用程式內建的 DoH 使用 HTTPS，不會因為攔截傳統 DNS 的 53 連接埠，就自動改走同一條解析路徑。

DNS 與流量嗅探：補充網域資訊，不取代代理規則

Fake-IP 的基本原理是先替網域指派映射位址，再於連線進入核心時還原網域資訊。範例中的 198.18.0.1/16 位於常用於此用途的基準測試保留位址範圍。看到這類解析結果時，不應直接判定為公用 DNS 故障；請確認發起連線的應用程式是否也由同一個核心接管。

mihomo 的嗅探功能可嘗試從 HTTP Host、TLS SNI 等協定內容取得網域，協助只有目標 IP 的連線套用網域規則。這並不是解密 HTTPS，也不保證每條連線都能擷取網域。遇到加密握手資訊、非標準協定或應用程式專用的連線方式時，仍可能無法取得可用的網域名稱。

sniffer:
  enable: true
  sniff:
    HTTP:
      ports: [80, 8080]
    TLS:
      ports: [443, 8443]

上例限定了嗅探協定與目標連接埠。若服務依賴指定 IP、使用內部憑證網域，或啟用後連線行為有所改變，請先比較停用嗅探後的結果，再依目前版本支援的略過條件縮小範圍。不要把嗅探當成解決所有規則未命中的通用開關。

移轉順序：語法檢查、節點測試、規則驗證，最後才啟用 TUN

舊設定檔不必為了移轉而全部重寫。先保留混合連接埠、既有節點與簡單規則，再逐項加入新功能，較容易判斷問題來自節點參數、規則資料或系統流量接管。以下順序適用於獨立核心，也可作為圖形化用戶端的檢查清單。

  1. 備份一份可還原的設定。記錄原用戶端、核心版本、設定來源與工作目錄。若用戶端支援訂閱覆寫或合併設定，也請一併備份。
  2. 確認設定檔能否載入。使用下方的測試指令。這能找出 YAML、部分欄位與資源載入問題，但無法證明遠端節點一定連得上。
  3. 先測試代理入口。確認 mixed-port 實際監聽的連接埠，再透過本機代理傳送請求。下方範例使用 7890；若設定不同，請一併修改指令。
  4. 確認規則比對結果。查看連線紀錄中的目標網域、命中規則與最終出站。加入 GEOSITE 或 RULE-SET 後，請再次測試同一個目標。
  5. 最後測試 TUN。先確認系統代理路徑正常，再啟用 TUN。分別測試瀏覽器、未讀取系統代理設定的應用程式、區域網路存取與 DNS 解析。
mihomo -v
mihomo -t -d ./mihomo-data -f ./config.yaml
curl -I --proxy http://127.0.0.1:7890 https://example.com/

若主設定檔引用相對路徑，測試時的 -d 應與預期工作目錄一致，並事先準備好規則檔。測試指令通過後，還要檢查用戶端實際交給核心的設定；有些用戶端會合併訂閱、覆寫與介面設定後才執行，因此磁碟上的訂閱原文不一定等於生效設定。

三類錯誤，對應三種排查方向

  • 不支援的代理類型：先確認核心名稱與版本，再確認訂閱是否輸出 mihomo 相容格式；不要先改 DNS。
  • 規則集或 GEO 資料載入失敗：檢查路徑、檔案格式、存取權限與下載連線；不要直接刪除所有分流規則來掩蓋問題。
  • 代理可用，但 TUN 無法使用：檢查權限、預設網卡、衝突路由與 DNS 接管；不要因此判定遠端節點失效。

用戶端入口與安裝說明請參閱下載中心；第一次匯入訂閱可參考使用指南。若要進一步確認 DNS、策略群組與 TUN 欄位，請至設定大全依欄位查閱。

下載用戶端