mihomo 與 Clash 核心比較

先釐清核心、客戶端與歷史分支

先說結論：需要較新的協定、細緻的規則或持續維護的核心時，建議優先考慮 mihomo；若現有舊設定運作穩定，切換前應先確認相容性，再讓實際流量改走新核心。兩者的差異主要在功能涵蓋範圍與維護方向，並非換個名稱就能讓所有節點加速。連線品質、伺服器參數與本地網路仍是影響連線表現的關鍵。

Clash 是代理核心專案，負責連線轉送、規則比對與 DNS 等工作；桌面或手機客戶端則提供訂閱管理、系統匣、系統代理與權限管理功能。Clash Meta 是以 Clash 為基礎發展的分支，後來更名為 mihomo。舊文件、設定範本與客戶端設定中仍可能出現 Meta 字樣，這通常只是沿用舊稱，不代表還得另外安裝第二個核心。

「原版 Clash」也得進一步區分：過去曾有開源核心與閉源的 Clash Premium，兩者功能並不完全相同。原專案已於 2023 年停止維護，因此不能把過去 Premium 的所有功能都算在開源版名下，也不能把第三方客戶端持續更新視為原核心恢復維護。

協定支援：新增類型不代表自動相容

mihomo 在原有代理功能上，增加了多種協定與傳輸方式。對使用者最直接的影響是：訂閱中若有 VLESS、Hysteria2 或 TUIC 節點，舊核心可能無法解析；支援相應實作的 mihomo 則能處理。能否使用仍取決於具體版本、欄位與伺服器設定，不能只看節點顯示名稱。

遷移節點時，核對這三組參數

• 協定憑證：伺服器位址、連接埠、密碼或 UUID 必須與伺服器端一致。TLS 常用的 443 只是連接埠號碼，不能據此認定「該節點必定使用 HTTPS」。
• 傳輸參數：WebSocket 路徑、Host、gRPC 服務名稱等都要逐項對應。YAML 能載入，不代表握手參數正確。
• TLS 與 REALITY：核對 servername、指紋，以及適用時的 reality-opts。不要用 skip-cert-verify: true 掩蓋網域或憑證設定錯誤。

如果訂閱轉換時已經移除了新協定節點，升級核心也無法讓節點重新出現。請一併檢查服務商提供的訂閱格式、轉換器輸出，以及客戶端最終套用的設定。先確認節點類型確實保留下來，再排查握手失敗，能大幅縮短排查時間。

規則與規則集：保留順序，區分檔案格式

基本比對邏輯沒有改變：在規則模式下，rules 會依序比對，由第一條符合的規則決定連線交由哪個策略處理。DOMAIN、DOMAIN-SUFFIX、IP-CIDR 等基本規則仍然重要，最後通常以 MATCH 接住未符合的流量。新增功能不會自動修正錯誤的規則順序。

mihomo 提供更多比對條件，例如依程序名稱、目標連接埠或邏輯組合篩選連線。不過，程序識別會受到作業系統、權限與流量接管方式影響。設定中有 PROCESS-NAME，不代表每個平台都能取得預期的程序資訊。

RULE-SET 不是節點訂閱

• proxy-providers 用來提供節點，內容最終必須能解析為代理設定。
• rule-providers 用來提供比對項目，再由 RULE-SET 引用並指定策略。
• behavior: domain、ipcidr 與 classical 對項目內容的要求不同，不能只改副檔名就互換。
• mihomo 的 mrs 是規則集格式，不能直接交由原版 Clash 使用，也不能當成一般 YAML 文字編輯。

遷移 Premium 設定時，可能已經包含 rule-providers 與 RULE-SET；若是從原版開源核心遷移，則不應預設這些欄位原本就能使用。以下提供一份用來驗證基本結構的完整範例設定，刻意不包含遠端訂閱，策略組也只有直連選項。

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

proxy-groups:
  - name: 出口選擇
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,出口選擇

這份設定只用來驗證載入、連接埠與規則結構，不提供代理線路。加入實際節點後，再將有效節點或節點提供者加入策略組。不要把 MATCH 放在專用規則之前，也不要讓規則引用已重新命名或不存在的策略組。

DNS 差異：留意解析路徑與啟動依賴

原版 Clash 已具備 DNS 與 Fake-IP 功能，因此「換成 mihomo 才能使用 Fake-IP」並不準確。mihomo 的差異在於提供更多解析控制選項，以及能與分流功能搭配使用，例如透過 nameserver-policy 為特定網域指定解析器，或透過 proxy-server-nameserver 獨立處理代理伺服器網域的解析。

fake-ip 模式會為網域回傳對應位址，之後由核心依據映射處理連線；redir-host 則較接近回傳實際解析結果。哪種方式較合適，取決於應用程式相容性與網路接管方式。遇到區域網路裝置探索、特定遊戲或企業內網異常時，應找出相關網域與存取路徑，而不是直接把所有網域都加進過濾清單。

三個容易混淆的 DNS 欄位

TUN 與客戶端：除了功能開關，還要有權限

系統代理通常只會影響遵循系統代理設定的應用程式；TUN 則透過虛擬網路介面接管符合路由條件的 IP 流量。mihomo 支援 TUN，但能否正常運作仍取決於系統權限、虛擬網卡、路由規則及其他 VPN 軟體。啟用 TUN 不會改變伺服器端協定，也不會讓不支援 UDP 轉送的線路自動具備這項能力。

1. 先測試一般代理：使用系統代理或明確指定 HTTP 代理進行測試，確認節點本身可連線後，再啟用 TUN，避免同時排查兩類問題。
2. 接著檢查權限：桌面客戶端可能透過服務元件取得所需權限；直接執行核心時，則需依作業系統要求授予網路管理權限。
3. 最後檢查路由與 DNS：auto-route、auto-detect-interface 與 DNS 接管應依實際網路環境設定，尤其要留意多張網卡、企業 VPN 與虛擬機器網路。

不要把混合代理監聽連接埠 7890 當成 TUN 網卡連接埠，也不要把控制介面連接埠 9090 填進瀏覽器代理欄位。控制介面是供客戶端管理核心使用，不是一般網頁代理入口。若要設定控制介面，建議限制在迴路位址，並設定存取憑證。

遷移舊設定：依六個步驟驗證，別直接覆寫

大部分基本 YAML 結構都能延續，但「舊設定能啟動」與「新設定完整生效」是兩項不同的檢查。未知欄位可能遭到忽略，特定規則或節點也可能在後續載入階段發生錯誤。建議保留原設定與原客戶端環境，先用獨立副本逐步驗證。

1. 備份設定來源：分別保存訂閱原文、客戶端覆寫規則與目前生效的設定。客戶端顯示的訂閱檔案不一定就是最終交給核心的檔案。
2. 記錄執行環境：記下作業系統、客戶端版本、mihomo -v 的輸出，以及是否啟用系統代理與 TUN。切換前先關閉另一個執行個體，以免連接埠遭占用。
3. 執行設定測試：在設定檔所在目錄執行以下命令。如果規則提供者使用相對路徑，請確認工作目錄與實際執行環境一致。

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

4. 判讀錯誤類型：YAML 縮排或型別錯誤就先修正語法；策略組不存在就檢查名稱；無法辨識節點類型則核對核心版本與訂閱輸出。不要一看到錯誤就反覆更新訂閱，覆蓋問題現場。
5. 測試實際連線：啟動核心後，透過明確指定的代理請求測試入口、節點與 TLS，再檢查記錄檔確認符合哪條規則。設定測試通過，不能取代實際連網驗證。
6. 逐項恢復進階功能：最後再加入遠端規則集、DNS 策略、程序規則與 TUN。每新增一項就重新測試，才能快速找出是哪項變更造成異常。

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

此命令假設混合連接埠為 7890，且未設定代理驗證；若連接埠不同，請相應修改。收到 HTTP 回應只能證明這次請求成功，不能代表所有規則、UDP 應用程式或 TUN 都正常。還應分別測試一個預期直連的目標與一個預期走代理的目標，並對照記錄檔中的策略名稱。

更新訂閱後設定被還原，該怎麼辦？

如果手動編輯的是由訂閱管理的檔案，下次更新很可能會被伺服器內容取代。請使用目前客戶端支援的覆寫、合併或指令碼機制保存本機變更，並檢查合併順序。不同客戶端的合併語法不盡相同，不能直接把某款客戶端的覆寫片段當成 mihomo 原生欄位。

選型結論：依實際需求決定遷移範圍

• 需要新協定：優先選擇整合適當版本 mihomo 的客戶端，同時確認訂閱輸出保留完整的節點欄位。
• 需要複雜分流：確認規則提供者、程序識別、DNS 策略與目標平台支援情況，不要只比較介面上有沒有「規則模式」按鈕。
• 現有舊環境運作穩定：先用副本完成驗證，再取代日常使用的入口；遷移目標應是取得所需功能並維持可維護性，而不是追求名稱變更。

選擇客戶端時，可參考客戶端比較，確認平台與核心方向；若要進一步核對協定欄位，請查看協定手冊。最終仍應以實際執行版本、載入記錄與連線結果為準：節點可解析、規則可追蹤、DNS 路徑明確，才算完成一次可重現的遷移。