mihomo 核心與原版 Clash 比較：新增協定、rule-providers 與 TUN 功能差異

先釐清原版開源核心、Premium 與 mihomo 的差異

結論是：mihomo 沿用 Clash 的設定架構，但不能把兩者當成只是更名的同一個執行檔。mihomo 延續 Clash.Meta 的開發方向，增加了協定、規則與流量接管功能。遷移時通常可保留基本欄位，但新設定不保證能由舊核心讀取。

「原版 Clash」也要區分兩種對象：原版開源核心，以及當年的 Clash Premium。Premium 曾提供規則集與 TUN 等擴充功能。若把兩者混為一談，再下結論說「Clash 不支援 rule-providers，只有 mihomo 支援 TUN」，就會失之偏頗。

• 用戶端：負責介面、訂閱管理、系統代理切換及啟動核心。用戶端版本不等於核心版本。
• 核心：負責讀取設定、建立代理連線、解析 DNS 與執行規則。實際支援哪些欄位，取決於目前執行的核心。
• 訂閱轉換：可能會依目標核心產生不同的節點欄位。轉換器可以改變輸出結構，但無法讓舊核心支援新的協定實作。

先在用戶端的核心資訊或啟動記錄中確認名稱，再檢查實際執行檔。以下指令適用於獨立執行的二進位檔；圖形用戶端內建的檔案可能使用不同名稱，請勿因此再啟動第二個核心。

mihomo -v
clash -v

協定支援比較：匯入節點不代表能成功連線

Shadowsocks、VMess、Trojan 等是兩種路線都支援的常見協定。mihomo 進一步支援 VLESS、Hysteria2、TUIC 等；實際可用的傳輸組合與參數，仍應以目前核心文件為準。原版不同歷史版本之間也有差異，不能將某個舊版的結果套用到所有版本。

遷移時請檢查節點的傳輸層參數

1. 協定類型：先檢查 type，例如 vless 或 hysteria2。若核心不認得該類型，應更換核心或訂閱輸出目標。
2. 身分資訊：確認密碼、UUID 與驗證欄位。直接把 VMess 節點改成 VLESS 類型，並不能完成轉換。
3. 傳輸方式：確認 WebSocket、gRPC 等傳輸設定與伺服器端一致，尤其是路徑、Host 與服務名稱。
4. TLS 參數：確認伺服器名稱、憑證驗證設定與 REALITY 參數。請勿以關閉憑證驗證來取代問題排查。

Hysteria2 與 TUIC 使用以 QUIC 為基礎的傳輸方式，網路必須允許相應的 UDP 通訊。設定測試通過只代表欄位可成功解析；若出口網路限制 UDP，連線仍可能失敗。更換核心不會自動解除網路端的限制。

rule-providers：先確認 behavior，再檢查檔案格式

rule-providers 用來載入規則集，不是節點訂閱。節點供應器使用 proxy-providers。完成規則集宣告後，還必須在 rules 中以 RULE-SET 引用，否則不會參與比對。

從 Premium 遷移至 mihomo 時，既有的一般 YAML 規則集通常可以保留。重點是確認 behavior 與檔案內容相符：classical 放完整規則運算式，domain 放網域比對項目，ipcidr 放 IP 網段。這三種內容不能只改宣告後混用。

本機 classical 規則集範例

將以下片段合併至現有的主設定檔。Proxy 是示範用的策略群組名稱，必須改成實際存在的群組名稱，或在原設定中定義該群組。路徑是相對於核心工作目錄，不一定相對於圖形用戶端的安裝目錄。

rule-providers:
  local-sites:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/local-sites.yaml

rules:
  - RULE-SET,local-sites,Proxy
  - MATCH,DIRECT

建立 rules/local-sites.yaml，內容如下。example.com 是示範網域，實際使用時請替換成需要分流的網域。

payload:
  - DOMAIN-SUFFIX,example.com
  - IP-CIDR,192.168.0.0/16,no-resolve

• format: yaml 的規則檔包含 payload。純文字格式則須依照相應格式逐行撰寫項目，不能繼續套用 YAML 外層結構。
• mihomo 的 mrs 是二進位規則集格式，適用於 domain 與 ipcidr；不能只把任意 classical 檔案改副檔名就拿來使用。
• HTTP 類型的供應器還需要可實際存取的 url。其中 interval: 86400 表示更新間隔為 86400 秒，不是連線逾時時間。
• 規則仍會由上而下比對。範圍太廣的規則若放在前面，後面的精確規則就可能沒有命中機會；MATCH 通常放在最後。

網域嗅探：補足網域資訊，不是解密 HTTPS

IP 連線本身可能不包含可供網域規則比對的目標名稱。mihomo 的 sniffer 可從 HTTP Host、TLS 握手中的伺服器名稱，以及可辨識的 QUIC 握手資訊擷取網域，協助進行流量分流。這不等於解密 HTTPS，也無法保證還原所有連線的網域。

以下是 mihomo 嗅探設定片段。建議先保留 override-destination: false，觀察規則命中情況，再判斷是否需要覆寫連線目標；這不是所有設定都必須啟用的選項。

sniffer:
  enable: true
  override-destination: false
  sniff:
    HTTP:
      ports: [80, 8080-8880]
    TLS:
      ports: [443, 8443]
    QUIC:
      ports: [443, 8443]

嗅探與 Fake-IP 的適用範圍

• Fake-IP 透過 DNS 映射保存網域與合成 IP 的對應關係；嗅探則嘗試從連線內容擷取網域。兩者取得資訊的來源不同。
• 若程式將 IP 硬寫在程式碼中、使用無法辨識的協定，或握手資訊受到加密保護，嗅探可能無法取得有效網域。
• 需要套用網域規則卻只看到目標 IP 時，應先檢查 DNS 是否由核心處理、映射是否有效，再檢查嗅探；不要直接擴大嗅探範圍。

遷移後若只有少數網站異常，可以暫時關閉嗅探進行比較。每次只調整一個選項，並查看連線詳細資訊中的目標網域、命中規則與出口策略，避免把嗅探、DNS 與節點故障混為一談。

TUN 功能：分別確認協定堆疊、路由與 DNS 接管

TUN 會將流量送入虛擬網路介面，與系統 HTTP 代理不同：未遵循系統代理設定的程式，也可能透過路由進入 TUN。原版 Premium 已支援 TUN，mihomo 則持續擴充此功能；不能將「支援 TUN」本身視為 mihomo 獨有功能。

mihomo 的 TUN 設定可選擇 system、gvisor、mixed 等堆疊，實際可用性取決於平台與版本。mixed 會搭配使用 system TCP 堆疊與 gVisor UDP 堆疊。堆疊名稱不代表速度排名；發生問題時，應在相同網路與節點下進行比較。

最精簡的 TUN 驗證片段

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

這只是要合併至現有設定的 TUN 片段，還需要有效的 dns 設定。auto-route 用來自動設定路由，auto-detect-interface 用來自動辨識出口介面；若同時使用多個 VPN 或虛擬網卡，仍須確認自動辨識結果是否正確。

1. 先確認權限：Windows 通常透過用戶端服務或管理員權限設定虛擬介面；Linux 則需要相應的網路管理權限。請勿將權限錯誤誤判為節點失效。
2. 接著檢查路由：確認虛擬介面已建立，且目標流量確實進入核心。若記錄中完全沒有連線資訊，應優先檢查流量接管路徑。
3. 另外檢查 DNS：any:53 適用於進入接管路徑的一般 53 埠 DNS。瀏覽器內建的 DoH 透過 HTTPS 傳輸，不會因為這項設定就自動改由核心處理 DNS 查詢。
4. 最後測試 UDP：節點協定、伺服器、出口網路與用戶端程式都可能影響 UDP。網頁能開啟，不代表遊戲或語音連線也正常。

舊設定檔遷移：分階段載入，保留回復方式

最穩妥的順序是先確認設定可解析，再測試一般代理，最後才啟用 DNS、規則集與 TUN。若直接替換核心並同時開啟所有新功能，一旦失敗就很難找出是哪一層改變了行為。

第一步：測試實際生效的設定

以下指令會檢查 config.yaml。若用戶端有覆寫、腳本或合併設定，應檢查它最後產生的執行檔，而不只是訂閱下載的原始檔案。

mihomo -t -f config.yaml

遇到未知的代理類型，請檢查訂閱目標是否設定為 mihomo；遇到策略不存在，請檢查規則引用與策略群組名稱；遇到規則集讀取失敗，請檢查工作目錄、檔案路徑與格式。測試通過不代表節點驗證、網路連線與遠端規則集更新都已成功。

第二步：以一般代理建立基準

先保持 TUN 關閉，並使用現有設定中的 mixed-port。若設定為 7890，可執行下列請求。這裡明確指定 HTTP 代理，以排除系統代理開關造成的影響。

curl -I --proxy http://127.0.0.1:7890 https://example.com

請一併確認是否收到回應、連線記錄是否出現，以及命中了哪條規則。這項測試只驗證目前的 HTTP 代理路徑，不測試 UDP，也不代表所有應用程式都已接管。若連接埠遭舊程序占用，請先結束舊核心，不要任意改用多個連接埠同時執行。

第三步：逐項恢復進階設定

1. 恢復規則集，檢查每個 RULE-SET 引用與下載狀態。
2. 恢復 DNS 設定，確認 enhanced-mode、nameserver 與 nameserver-policy 的實際解析路徑。
3. 視需要啟用嗅探，並比對目標網域與命中規則。
4. 最後啟用 TUN，檢查介面、路由、DNS 與 UDP。

保留舊核心可讀取的設定副本。回復舊版時，不只要換回執行檔，也要還原相容的規則集格式與欄位；新核心產生的設定不應直接覆蓋唯一的舊設定備份。

選擇依據與參考資料

若現有設定只使用基本協定與一般規則，遷移時應著重維護狀態、平台支援與用戶端整合；若需要 VLESS、Hysteria2、TUIC、mrs 或精細的嗅探設定，應選擇明確採用 mihomo 且具備所需功能的用戶端。介面上有某個按鈕，不代表目前選用的核心一定能執行該功能。

本文依功能範圍進行比較，不會把單一版本的表現視為永久結論。平台限制、欄位預設值與新增協定參數，請以實際安裝版本及對應文件為準。以下資料可用來確認專案資訊、欄位定義與變更記錄。

• mihomo 專案儲存庫：專案說明、原始碼與問題追蹤。
• mihomo 規則集設定文件：供應器類型、behavior 與檔案格式。
• mihomo TUN 設定文件：堆疊、路由與平台相關選項。
• mihomo 網域嗅探文件：協定範圍與目標覆寫設定。
• mihomo 版本發布記錄：搭配本機版本確認修正內容與行為變更。

若要進一步確認完整設定結構，請參閱本站的進階設定；首次安裝與匯入訂閱可依照教學指南操作。遷移驗收請以四項結果為準：「設定可解析、節點可連線、規則命中正確、接管範圍符合預期」。