mihomo 核心與原版 Clash 的差異：功能、設定相容性與選擇

比較範圍：核心、客戶端與設定檔

討論 Clash 與 mihomo 的差異時，首先要將「核心」和「客戶端」分開。核心負責讀取 YAML、建立代理連線、執行 DNS 解析、比對規則並開放本機監聽連接埠；桌面或行動客戶端則提供訂閱管理、系統代理切換、日誌檢視、設定編輯與服務安裝等介面。客戶端採用 mihomo 核心，不代表所有設定都會寫入主要設定檔；反過來，設定檔中存在某個欄位，也不代表客戶端介面一定提供對應的開關。

本文所稱的「原版 Clash」，主要是指 Dreamacro 專案形成的經典開源核心及其常見設定基準。歷史上也存在功能不同的 Premium 建置版本，因此不能將所有曾以 Clash 命名的版本視為同一套功能。mihomo 源自 Clash Meta 延續的核心分支，在經典設定結構上擴充了代理協定、規則類型、DNS 行為、TUN 接管方式與外部資源管理能力。

兩者的共同基礎仍十分明顯：設定通常使用 YAML；代理節點放在 proxies；策略群組放在 proxy-groups；分流規則放在 rules；執行模式由 mode 控制。常見的 mixed-port、allow-lan、log-level 與 external-controller 等欄位，也延續了相近的用途。正因基礎結構相似，許多經典設定可由 mihomo 讀取，但「可以啟動」不等於「行為完全一致」。

核心功能差異：從協定到流量接管

經典 Clash 設定主要圍繞 HTTP、SOCKS5、Shadowsocks、VMess、Trojan、Snell 等代理類型組織。mihomo 在保留常用類型的同時，加入或完善了 VLESS、TUIC、Hysteria2、WireGuard 等類型，並為部分協定提供更細緻的傳輸層、TLS 指紋、UDP 與多路複用參數。若訂閱中已包含這些新類型，經典核心通常無法只靠修改欄位名稱來建立連線，因為相應的協定實作本身並不存在。

流量識別也是差異集中的部分。mihomo 可依設定啟用協定嗅探，以實際存取的網域輔助處理只有目標 IP 的連線；也能結合程序名稱、程序路徑、入站類型、網路類型與目標連接埠進行分流。這類功能適合 TUN 接管、透明代理或需要細分應用程式流量的情境，但也會提高設定複雜度。嗅探範圍、略過網域與連接埠清單設定不當，可能使存取目標與預期規則不一致，因此不應一次啟用所有擴充選項。

外部控制介面的基本概念在兩類核心中相近，客戶端通常透過控制連接埠讀取連線、日誌與策略群組狀態。不過控制 API 的具體欄位與功能會隨核心版本變化。舊版客戶端介面即使能啟動新版 mihomo，也可能無法顯示新增的策略資訊；新版客戶端連線至舊核心時，也可能出現按鈕可見但呼叫沒有作用的情況。核心與客戶端外殼應依發佈方提供的組合使用。

設定相容性界線：能解析、能執行與結果一致

檢查設定相容性可分為三個層次。第一層是語法解析：YAML 縮排、清單與資料類型是否正確，以及核心是否認得該欄位。第二層是資源可用性：代理節點、規則集、Geo 資料與 DNS 上游能否載入。第三層是執行行為：相同請求是否進入相同策略群組、DNS 是否回傳預期結果，以及系統流量是否實際經過對應入站。遷移時只看到「設定載入成功」，還不足以確認後兩層。

以下是一段兩類設定中都很常見的基礎結構。實際節點參數應來自所使用的設定來源，範例重點在於欄位之間的關係。

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

proxies:
  - name: example-node
    type: socks5
    server: 127.0.0.1
    port: 1080

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - example-node
      - DIRECT

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

遷移至 mihomo 時，經典欄位通常可以保留，再依需求加入擴充選項。反向遷移則更嚴格：設定中的新協定節點、rule-providers、sniffer、擴充 DNS 欄位、邏輯規則或 mihomo 專用策略參數，都可能被舊核心拒絕，或無法依原本設計執行。刪除「不認得的欄位」並不是通用修復方法，因為被刪除的部分可能正是建立節點連線或正確比對規則所需的條件。

還要區分主要設定與客戶端覆寫。許多圖形化客戶端會在啟動核心前合併本機設定，例如控制連接埠、執行目錄、TUN 開關、金鑰、DNS 覆寫或系統代理連接埠。使用者編輯的 YAML 可能只是最終設定的一部分。排查相容性問題時，應從客戶端匯出或檢視實際執行設定，並在日誌中確認核心最終讀取的路徑，避免一直修改未被載入的檔案。

遷移時容易遺漏的欄位

• proxy-providers 與 rule-providers 的路徑、URL、更新間隔與行為類型。
• 策略群組中引用的節點名稱、提供者名稱，以及規則末尾引用的策略群組名稱。
• external-controller、驗證金鑰與客戶端控制介面位址。
• geodata-mode、Geo 資料載入方式，以及對應資源檔案是否存在。
• DNS 的 enhanced-mode、fake-ip-range、過濾清單與上游分組。
• TUN 的協定堆疊、自動路由、DNS 劫持與介面排除設定。

規則支援：類型增加不代表優先順序改變

Clash 系列核心的規則通常由上而下比對，命中後便使用該行指定的策略。mihomo 增加了更多規則類型，但並未將「更具體的規則自動優先」作為普遍替代機制。若寬泛的 DOMAIN-SUFFIX 放在精確的 DOMAIN 前面，前者仍可能先攔截請求；若 MATCH 提前出現，後續規則便沒有執行機會。

常見規則包括 DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD、IP-CIDR、IP-CIDR6、GEOIP、DST-PORT、SRC-IP-CIDR、PROCESS-NAME 與 MATCH。mihomo 環境也經常使用 GEOSITE、RULE-SET、NETWORK、PROCESS-PATH 以及邏輯組合規則。實際可用類型仍應以核心版本文件與啟動日誌為準。

RULE-SET 本身不會憑空產生規則，它引用的是 rule-providers 中定義的外部規則集。規則集常見的行為類型有 domain、ipcidr 與 classical。domain 適合網域項目，ipcidr 適合 IP 網段，classical 則可容納帶有規則類型的經典項目。行為類型與實際內容不相符時，檔案可能下載成功，但項目無法依預期載入。

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

rules:
  - RULE-SET,private-domains,DIRECT
  - GEOIP,LAN,DIRECT,no-resolve
  - MATCH,PROXY

no-resolve 常用於不希望規則比對階段主動解析網域的 IP 類規則。它不代表整個連線不需要 DNS，也不會關閉 DNS 模組；它只會影響該規則比對時是否觸發解析。機械式地將它加到所有規則後面，既不能提升所有情境的速度，也可能改變原本依賴解析結果的比對路徑。

程序規則在不同系統上的可用性也不完全相同。桌面系統通常較容易取得程序名稱或路徑，行動系統則受權限與網路堆疊限制，客戶端未必能向核心提供相同資訊。將一套依賴 PROCESS-NAME 的桌面設定遷移至手機時，應準備網域或 IP 規則作為補充，而不是假設規則文字相同就會得到相同結果。

DNS 與 TUN：最容易誤判差異的區域

一般系統代理主要接收明確使用 HTTP 或 SOCKS 代理的應用程式流量，TUN 模式則透過虛擬網路介面接管更廣泛的連線。mihomo 的 TUN 設定常見欄位包括 enable、stack、auto-route、auto-detect-interface 與 dns-hijack。這些欄位能否生效，還取決於作業系統權限、路由表、防火牆、客戶端服務，以及其他 VPN 軟體是否同時佔用網路接管能力。

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

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"

這段設定展示的是欄位關係，不是所有裝置都應直接採用的固定答案。不同 mihomo 版本支援的 TUN 協定堆疊選項可能有所調整，客戶端也可能自動產生相關欄位。若客戶端已經管理 TUN，卻又在訂閱設定中寫入另一套參數，可能在每次更新時被覆寫，或與本機路由設定衝突。

DNS 的 fake-ip 模式會先向應用程式回傳保留位址範圍中的映射位址，再由核心對應真實網域並執行規則。這有助於在透明接管情境中保留網域資訊，但區域網路裝置探索、部分遊戲、特定驗證流程，以及依賴真實 DNS 回應的程式，可能需要加入 fake-ip-filter。redir-host 的處理路徑不同，相容性表現也會隨系統與應用程式而變化。選擇模式時應根據故障現象進行測試，而不是只比較欄位數量。

mihomo 也提供 nameserver-policy、proxy-server-nameserver、direct-nameserver 等更細緻的 DNS 分工。前者可讓特定網域使用指定上游；後兩者用於區分代理伺服器位址與直連目標的解析路徑。它們能減少 DNS 路徑混用，但設定錯誤也可能形成循環：例如解析代理伺服器網域時，所選 DNS 本身又必須先透過尚未建立的代理存取。

從原版 Clash 遷移至 mihomo 的驗證步驟

穩妥的遷移應從一份能正常運作的設定副本開始，不要在唯一檔案上連續疊加修改。先驗證基礎代理，再加入規則集、DNS 與 TUN，可以快速判斷故障屬於節點連線、規則比對還是系統接管。

1. 記錄目前的執行資訊。 儲存原核心版本、客戶端版本、監聽連接埠、系統代理狀態、DNS 模式與可用策略群組。若遷移後行為改變，這些資訊可作為對照。
2. 檢查 YAML 結構。 確認縮排只使用空格，節點名稱與策略群組引用完全一致，連接埠為數字，布林值沒有意外寫成字串。先解決解析錯誤，再處理網路錯誤。
3. 建立最小連線測試。 暫時使用一個已知可用的節點、一個 select 策略群組與少量規則。確認本機混合連接埠可存取後，再匯入完整訂閱或代理提供者。
4. 逐項恢復規則資源。 查看每個 provider 的下載狀態、檔案路徑、behavior 與 format。規則集更新失敗時，不要只觀察策略群組是否存在，還應在日誌中確認項目數量。
5. 單獨驗證 DNS。 分別檢查代理伺服器網域、直連網域與需要代理的網域。若網域連線失敗而直接存取 IP 正常，問題通常更接近 DNS 路徑，而不是節點協定。
6. 最後啟用 TUN。 先關閉其他 VPN 或流量接管工具，確認管理員權限與服務元件正常，再觀察路由表、DNS 劫持與區域網路存取。一般系統代理可用但 TUN 無法使用時，應集中檢查系統層設定。
7. 確認最終生效設定。 若客戶端支援覆寫、腳本或合併功能，應查看合併結果。訂閱更新後再次確認本機規則與 DNS 修改是否仍然存在。

日誌中的錯誤類型有助於縮小範圍。出現 unknown field 或設定解析失敗，通常指向欄位與版本不相容；出現規則提供者下載失敗，應檢查 URL、網路路徑與儲存目錄；出現連線逾時，則要進一步區分代理伺服器解析、傳輸交握、路由與規則選擇。不要因為多個錯誤同時出現，就一次修改連接埠、DNS、節點與 TUN；大量改動會失去可比較的基準。

如何選擇：依據設定來源與實際功能

如果現有設定只使用經典協定、簡單策略群組與少量網域規則，而且客戶端與核心組合長期穩定，繼續使用相容的經典環境可以降低變更成本。但仍應留意專案維護狀態、作業系統升級與客戶端支援情況，尤其要確認控制介面、系統代理服務與憑證元件是否仍能正常配合。

如果訂閱包含 VLESS、TUIC、Hysteria2 等較新的節點類型，或設定依賴 GeoSite、規則提供者、邏輯規則、協定嗅探、精細 DNS 分流與持續維護的 TUN 功能，mihomo 通常是更合適的選擇。此時應選擇明確標示所用核心版本的客戶端，讓客戶端、核心與設定語法處於彼此支援的版本範圍內。

選擇時不必追求欄位最多。對一般桌面使用者而言，穩定的系統代理、可更新的訂閱與清楚的策略群組已涵蓋主要需求；對需要遊戲 UDP、區域網路共享、容器網路、依程序分流或全域 TUN 接管的使用者，則應重點測試該作業系統上的實作。相同 YAML 在 Windows、macOS、Linux、Android 與 iOS 上，可能因權限與網路框架不同而有不同表現。

選擇前的四項確認

• 訂閱中的節點協定是否受目標核心支援。
• 規則是否依賴 mihomo 專用類型、Geo 資料或外部規則集。
• 客戶端是否能管理所需的 TUN、服務模式與系統代理設定。
• 設定更新機制是否會保留本機覆寫與自訂規則。

從設定管理角度來看，mihomo 更適合承載持續擴充的規則與協定需求；經典 Clash 設定則仍是理解連接埠、策略群組與由上而下規則機制的重要基礎。遷移的關鍵不是將舊檔案改成更多欄位，而是逐項確認協定實作、資源檔案、DNS 路徑與系統接管方式。保留一份最小可用設定，並讓每次修改都能驗證，通常比直接複製複雜設定更容易取得穩定結果。

常見問題