核心解讀 預計閱讀 13 分鐘

mihomo 核心新增哪些功能？與原版 Clash 核心差異完整解析

從協定支援、規則類型、TUN 實作到 GEO 資料管理，完整整理 mihomo（Clash Meta）相較原版核心的擴充功能，並說明哪些設定欄位只有 mihomo 能辨識。

先分清原版 Clash、Clash Meta 與 mihomo

這裡所說的「原版 Clash」，通常是指由 Dreamacro 維護的 Clash 開源核心。它負責讀取 YAML 設定、建立代理連線、執行規則比對，並透過 HTTP、SOCKS5 或 mixed-port 為本機應用程式提供代理服務。原版專案停止更新後，社群分支 Clash Meta 持續擴充協定、規則、DNS 與透明代理功能，之後專案名稱改為 mihomo。

因此，Clash Meta 與 mihomo 不是兩套需要二選一的核心。前者是舊名稱，後者是目前名稱。部分用戶端介面、訂閱轉換器與舊設定仍會顯示「Meta」；判斷時應查看實際核心版本，而不只是用戶端名稱。

核心與圖形用戶端也要分開理解。用戶端負責系統匣選單、設定下載、系統代理開關與日誌顯示；真正辨識 proxies、rules、dns、tun 等欄位的是核心。同一份設定在不同用戶端中的表現不同，常見原因不是介面，而是它們內建的核心類型或版本不同。

功能比較的基本範圍

功能 原版 Clash mihomo
基礎規則代理 支援 相容並擴充
現代代理協定 涵蓋較早一代協定 新增 VLESS、Reality、TUIC、Hysteria2 等支援
TUN 透明代理 開源版功能有限，過去曾與 Premium 實作並存 整合多種協定堆疊與自動路由功能
邏輯組合規則 以線性規則為主 支援 AND、OR、NOT 與子規則
GEO 資料 基本 GEOIP、GEOSITE 使用方式 新增載入方式、下載位址與自動更新控制
流量嗅探 功能較少 提供獨立的 sniffer 設定區段

協定支援：新增的不只是節點類型

原版 Clash 已能處理 Shadowsocks、VMess、Trojan、Snell、SOCKS5、HTTP 等常見節點。mihomo 在此基礎上持續補充協定與傳輸層實作，較受關注的包括 VLESS、XHTTP、Reality、TUIC、Hysteria、Hysteria2、WireGuard，以及更多 Shadowsocks 外掛與傳輸組合。實際可用欄位仍取決於核心版本；訂閱中出現新欄位時，應先確認用戶端內建的 mihomo 是否足夠新。

VLESS 與 Reality

原版 Clash 無法辨識 mihomo 設定中的 VLESS 節點。mihomo 可讀取 type: vless，並處理 uuid、flow、network、tls 等欄位。使用 Reality 時，還可能包含 reality-opts、public-key 與 short-id。將這些欄位直接交給原版核心，通常會在設定驗證階段提示代理類型或欄位不受支援。

proxies:
  - name: vless-reality-example
    type: vless
    server: example.net
    port: 443
    uuid: 00000000-0000-0000-0000-000000000000
    network: tcp
    tls: true
    udp: true
    servername: www.example.com
    reality-opts:
      public-key: example-public-key
      short-id: "01234567"
    client-fingerprint: chrome

範例僅用於展示欄位層級；位址、UUID、公鑰與短 ID 必須來自實際服務設定。Reality 相關參數需要成組匹配，不能只將一般 VLESS 節點的 tls 改成 true。

TUIC 與 Hysteria2

TUIC 和 Hysteria2 都以 QUIC、UDP 為基礎，但設定欄位並不通用。TUIC 常見欄位包括 uuid、password、congestion-controller 與 udp-relay-mode；Hysteria2 常見欄位包括 password、obfs、obfs-password 和頻寬參數。節點提供者指定的協定類型，必須與核心設定中的 type 一致。

全域 TLS 指紋

mihomo 支援透過 global-client-fingerprint 設定全域用戶端指紋，也允許部分代理節點單獨填寫 client-fingerprint。常見值包括 chrome、firefox、safari、ios 與 random。節點層級欄位通常比全域欄位更具體；移轉設定時，應避免同時寫入彼此衝突的值。

global-client-fingerprint: chrome
unified-delay: true
tcp-concurrent: true

unified-delay 用於統一延遲計算方式，讓測試結果更接近完整連線過程；tcp-concurrent 會並行嘗試解析結果中的多個 IP，並以較快成功的連線繼續運作。這些都是 mihomo 常見的頂層擴充欄位，原版 Clash 設定不應依賴它們。

規則系統：從逐條比對擴充到邏輯組合

兩類核心都遵循「由上到下，首次命中即停止」的基本規則順序。原版常用規則包括 DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD、IP-CIDR、GEOIP、PROCESS-NAME、RULE-SET 與最後的 MATCH。mihomo 保留這些寫法，同時增加更多網路屬性與邏輯組合功能。

AND、OR 與 NOT

邏輯規則適合表達「同時符合多個條件」或「排除某個條件」。例如，只讓 UDP 且目的連接埠為 443 的流量進入指定策略群組，可以將網路類型與連接埠條件組合起來。邏輯規則的括號與逗號層級較嚴格，建議先用核心驗證指令檢查，不要直接覆蓋目前使用中的設定。

rules:
  - AND,((NETWORK,UDP),(DST-PORT,443)),QUIC策略
  - OR,((DOMAIN-SUFFIX,example.com),(DOMAIN-SUFFIX,example.net)),代理
  - NOT,((GEOIP,CN)),非中國大陸流量
  - MATCH,最終選擇

邏輯組合的價值不在於減少規則數量，而在於避免將一個條件拆成多組重複清單。規則越複雜，越需要把高頻且明確的網域規則放在前面，再將大範圍 GEOIP、規則集與 MATCH 放在後面。

連接埠、網路與程序規則

mihomo 可依來源連接埠、目的連接埠、入站類型、網路協定與程序路徑進一步分流。常見欄位包括 SRC-PORT、DST-PORT、IN-TYPE、NETWORK、PROCESS-NAME 與 PROCESS-PATH。例如 DNS 通常使用 53 號連接埠，HTTPS 通常使用 443 號連接埠，本機 mixed-port 則常設定為 7890。

規則集與子規則

rule-providers 仍是維護大量網域與 IP 規則的主要方式。mihomo 支援 domain、ipcidr 與 classical 等行為類型，也可使用 YAML 文字或 MRS 等載荷格式。規則提供器的 behavior 必須與檔案內容相符：純網域集合不應標記為 ipcidr，包含完整規則語法的清單則應使用 classical。

rule-providers:
  private-domains:
    type: http
    behavior: domain
    format: yaml
    path: ./ruleset/private-domains.yaml
    url: https://example.net/rules/private-domains.yaml
    interval: 86400

rules:
  - RULE-SET,private-domains,DIRECT
  - MATCH,代理

interval: 86400 代表每 86400 秒，也就是每 24 小時檢查一次更新。遠端規則首次下載失敗時，核心不可能憑空產生內容；應檢查 URL 是否可存取、檔案格式、寫入目錄權限，以及日誌中的 HTTP 狀態碼。

TUN 模式：接管範圍與協定堆疊更完整

系統代理只會影響主動讀取代理設定的應用程式。瀏覽器通常可以使用系統代理，但遊戲、命令列工具、部分商店應用程式，以及直接建立 UDP socket 的軟體可能繞過它。TUN 模式會建立虛擬網卡，將符合路由條件的 IP 流量交給核心，因此接管範圍更廣。

原版開源 Clash 與舊 Premium 核心過去存在不同的 TUN 功能邊界。mihomo 將 TUN、DNS 劫持、自動路由與流量嗅探納入持續維護的同一套設定體系，並提供 system、gvisor、mixed 等協定堆疊選項。不同平台的可用情況仍受作業系統與用戶端權限影響。

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

三種 stack 該怎麼選

auto-route 會自動寫入路由，讓流量進入 TUN；auto-detect-interface 用於識別目前的出口網卡；strict-route 會更嚴格限制繞過路徑。Windows、macOS 與 Linux 的路由實作不同，啟用後若區域網路印表機或 NAS 無法存取，應先檢查私人網段是否正確直連，而不是立即修改代理節點。

流量嗅探補足網域資訊

TUN 接管的連線有時只包含目的 IP，缺少原始網域。mihomo 的 sniffer 可從 TLS ClientHello、HTTP Host 或 QUIC 交握中擷取網域，再交由網域規則比對。這能減少「規則寫了網域，但連線只命中 IP」的情況。

sniffer:
  enable: true
  sniff:
    HTTP:
      ports:
        - 80
        - 8080-8880
    TLS:
      ports:
        - 443
        - 8443
    QUIC:
      ports:
        - 443
  skip-domain:
    - Mijia Cloud

嗅探不是 DNS 解析的替代方案，也無法從所有加密連線中還原完整網域。設定時應限制連接埠範圍，並使用 skip-domain 排除已知不適合改寫目標資訊的服務。排除問題時，可先關閉嗅探比較結果，確認問題究竟來自節點、DNS、規則還是網域覆寫。

DNS 與 GEO 資料：控制項明顯增加

原版 Clash 已提供 nameserver、fallback、fallback-filter、enhanced-mode 與 fake-ip-filter。mihomo 延續這些欄位，並增加 default-nameserver、proxy-server-nameserver、direct-nameserver、nameserver-policy、respect-rules 等細分控制。

不同 nameserver 的職責

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - https://dns.alidns.com/dns-query
  proxy-server-nameserver:
    - https://1.1.1.1/dns-query
  nameserver-policy:
    "geosite:cn":
      - https://dns.alidns.com/dns-query

範例將核心 DNS 監聽在 1053 連接埠，而不是直接占用系統常見的 53 號連接埠。TUN 中的 dns-hijack 會再將符合條件的 53 號連接埠查詢送入核心。若系統上已有本機 DNS 服務，應先確認連接埠占用情況，避免兩個程序監聽同一個位址。

GEOIP、GEOSITE 與 GeoSite.dat

GEOIP 依目的 IP 所屬地區進行比對，GEOSITE 則依維護好的網域分類比對，兩者不是同一種資料。網域規則可能在 DNS 解析前就命中，而 GEOIP 通常需要先取得目的 IP。將所有流量都交給 GEOIP 判斷，既不能取代網域分類，也可能增加解析後的比對成本。

mihomo 提供 geodata-mode、geodata-loader、geox-url、geo-auto-update 與 geo-update-interval 等頂層設定，用於控制資料格式、載入方式、下載位置與更新週期。部分版本也支援 GeoIP、GeoSite、MMDB 與 ASN 資料的獨立位址。

geodata-mode: true
geo-auto-update: true
geo-update-interval: 24
geox-url:
  geoip: https://example.net/data/geoip.dat
  geosite: https://example.net/data/geosite.dat
  mmdb: https://example.net/data/country.mmdb
  asn: https://example.net/data/ASN.mmdb

geo-update-interval: 24 通常以小時理解，表示每 24 小時檢查一次更新。實際支援的欄位與資料格式會隨 mihomo 版本變化，部署前應以目前的核心文件及啟動日誌為準。下載位址若回傳 HTML 錯誤頁，即使 HTTP 狀態看似正常，資料載入仍會失敗。

哪些欄位移回原版 Clash 會出問題

基礎的 port、socks-port、mixed-port、allow-lan、mode、log-level、proxies、proxy-groups 與一般 rules 通常容易相容。真正造成移轉失敗的，往往是 mihomo 擴充的節點類型、邏輯規則與頂層增強設定。

欄位或寫法 mihomo 用途 移轉注意事項
global-client-fingerprint 設定全域 TLS 用戶端指紋 原版核心不應依賴此欄位
sniffer 從 HTTP、TLS、QUIC 流量識別網域 需要移除相關網域覆寫邏輯
geox-url 指定 GEO 資料下載位址 原版的資料管理方式不同
tcp-concurrent 並行嘗試多個解析位址 舊核心可能忽略或拒絕
VLESS、TUIC、Hysteria2 現代代理協定 必須更換節點或繼續使用 mihomo
AND、OR、NOT 邏輯組合規則 需要拆成原版可辨識的線性規則
listeners 定義多個自有入站監聽器 原版通常使用固定連接埠欄位

先驗證，再替換執行中的設定

修改 YAML 後，可先在獨立目錄執行驗證。mihomo 常用的指令形式如下，其中 -d 指向包含設定與資料檔案的工作目錄，-f 指定設定檔：

mihomo -t -d ./mihomo-work -f ./config.yaml

驗證通過只代表語法、欄位與本機檔案基本可讀取。接著還應檢查執行日誌中的節點交握、規則提供器下載、DNS 監聽與 TUN 路由。建議至少完成四項測試：存取一個應直連的網站、存取一個應代理的網站、執行一次 UDP 請求，以及關閉系統代理後確認 TUN 是否仍能接管目標應用程式。

如何判斷是否需要 mihomo

如果設定只有 Shadowsocks、VMess、Trojan 與簡單網域規則，而系統代理也能涵蓋所有應用程式，那麼更換核心帶來的可見變化可能不大。設定是否穩定，仍主要取決於節點參數、規則順序與 DNS 路徑，而不是核心名稱本身。

以下情境更適合使用 mihomo：訂閱包含 VLESS Reality、TUIC 或 Hysteria2；需要透過 TUN 接管遊戲與命令列程式；希望依程序、入站或邏輯條件分流；需要獨立管理節點網域 DNS；使用 GEOSITE、ASN、MRS 規則集或自動 GEO 資料更新；需要在透明代理情境中透過嗅探還原網域。

  1. 先在用戶端的「設定」→「核心」查看實際核心名稱與版本。
  2. 匯出目前設定，搜尋 type: vless、type: tuic、type: hysteria2、sniffer: 與 geox-url:。
  3. 執行設定驗證，處理未知欄位、縮排錯誤與缺少資料檔案等問題。
  4. 開啟日誌，將層級暫時設為 info；只有排查複雜連線時，才在短時間內使用 debug。
  5. 逐項啟用 TUN、DNS 劫持與嗅探，不要一次修改所有網路路徑。
Clash 用戶端下載 查看各平台可用版本