mihomo 核心與原版 Clash 差異比較：新增協定、規則集與設定欄位

核心版本範圍：先分清原版、Premium 與 mihomo

mihomo 是原 Clash.Meta 專案的後續名稱，也常稱為 Clash Meta 核心。它沿用 Clash 的 YAML 設定格式，同時擴充協定、DNS、規則集與流量接管功能。改用搭載 mihomo 的用戶端，不只是換了介面：負責解析設定、建立連線與執行規則的程式也已不同。

「原版 Clash」要分成兩個比較對象：Dreamacro/clash 開源核心，以及原版生態中的 Clash Premium。兩者功能並不完全相同。尤其是 TUN 與規則提供者，不能一概說成「原版沒有，只有 mihomo 才有」。原版專案於 2023 年停止維護後，舊教學與訂閱範本仍持續流通；遷移時應以實際核心版本為準。

• 用戶端：負責匯入訂閱、系統匣操作、系統代理與產生設定，例如桌面版的設定管理介面。
• 核心：負責協定交握、DNS 查詢、規則比對與建立對外連線；介面版本號不能取代核心版本號。
• 訂閱：可能是完整設定，也可能只有一組節點；兩者不能任意填入同一種提供者欄位。

功能比較：支援更多協定，不代表設定完全通用

此表說明的是功能範圍，不代表所有版本都適用。伺服器端的新功能、特定傳輸組合及規則集格式，可能需要較新版 mihomo。若遇到「不支援的代理類型」，請先確認用戶端目前執行的核心，不要只看安裝檔名稱是否含有 Meta。

遷移 VLESS、Hysteria2 時的檢查重點

VLESS 節點的類型寫作 type: vless。若伺服器使用 REALITY，還必須正確設定 reality-opts、公鑰、短 ID、伺服器名稱，以及相符的用戶端指紋；flow 也必須符合伺服器設定。只把原 VMess 節點的類型改成 VLESS，並不能完成協定轉換。

Hysteria2 節點的類型寫作 type: hysteria2，與第一代 Hysteria 的設定並不相同。認證值、連接埠、SNI、混淆與頻寬參數都要依伺服器設定；所在網路也必須允許相應的 UDP 通訊。TCP 網頁能開啟，不代表 Hysteria2 的 UDP 交握一定可連通。

• 建議優先向訂閱服務提供者索取適用於 mihomo 的輸出格式，不要反覆手動修改整份訂閱。
• 不要用全域設定 skip-cert-verify: true 來掩蓋憑證名稱或信任鏈錯誤。
• 節點資訊可能包含密碼、UUID 或認證權杖。提交記錄前請先遮蔽敏感資訊，也要移除訂閱 URL 中的權杖。

遷移規則集：分清 provider、behavior 與檔案內容

proxy-providers 提供節點，rule-providers 提供比對條件。前者透過策略群組的 use 引用，後者則透過 RULE-SET 規則引用。將節點訂閱網址填入規則提供者，即使網址能下載，也無法取得可用的分流規則。

以下是本機檔案範例。設定檔與 rules 資料夾放在同一個設定工作目錄；若用戶端使用獨立的核心工作目錄，請以實際工作目錄為準。範例僅示範如何載入規則檔，不包含代理節點，也無法建立代理連線。

主設定中的規則提供者

rule-providers:
  local-domains:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/local-domains.yaml

rules:
  - RULE-SET,local-domains,DIRECT
  - MATCH,DIRECT

rules/local-domains.yaml 的內容

payload:
  - '+.example.com'
  - 'example.org'

behavior: domain 的項目是網域模式，不能直接放入 DOMAIN-SUFFIX,example.com 這類完整規則。若使用 behavior: classical，則可在 payload 中填入支援的傳統規則項目，例如 DOMAIN-SUFFIX,example.com；執行策略則由外層的 RULE-SET 指定。

• domain：用於網域比對內容，適合純網域清單。
• ipcidr：用於 IP 網段內容，例如 192.168.0.0/16，請勿混入網域。
• classical：用於支援的傳統規則類型，內容格式與前兩者不同。

YAML、純文字與 MRS 是不同的儲存格式。MRS 是 mihomo 使用的二進位規則集格式，支援 domain 與 ipcidr 行為，不適合作為原版核心通用的交換格式。遷移時請一併核對 behavior、format 與遠端實際回傳的內容；只把副檔名改成 .yaml 並不會改變檔案格式。

規則仍會依序比對。若將 MATCH 提前，後續規則便不會生效；若把範圍很大的直連規則放在代理規則之前，也可能改變原有分流結果。載入成功只代表內容可解析，不代表比對順序符合預期。

sniffer 嗅探：補充網域線索，不是解密流量

部分連線進入核心時，只有目標 IP。mihomo 的 sniffer 可嘗試從支援的 HTTP、TLS、QUIC 流量中取得網域線索，輔助規則比對；相關選項也可能變更連線目標。它不是 HTTPS 解密代理，不會因此取得 TLS 加密後的內容，也無法保證從每條連線擷取到網域。

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

這段設定將 HTTP 檢查範圍限制在 80、8080 連接埠，TLS 與 QUIC 則限於 443 連接埠，並明確停用目標位址覆寫。這樣便於先觀察嗅探與規則比對結果，避免同時引入目標改寫的變數。是否擴大連接埠範圍，應依實際需求決定，不宜為了「更完整」而直接檢查所有連接埠。

若特定網站在啟用嗅探後出現異常，請先關閉 sniffer.enable，逐一比較變更前後，再確認相關網域是否需要加入 skip-domain。使用 ECH 等 TLS 機制時，可觀察到的網域資訊可能減少。嗅探也不能取代 DNS 分流：若用戶端 DNS 繞過系統代理，仍須在 DNS 或流量接管路徑中處理。

DNS 與 TUN：基本欄位可沿用，執行條件要重新確認

舊設定中的 dns.enable、enhanced-mode: fake-ip、fake-ip-filter 等概念仍可用於 mihomo。Fake-IP 會以保留位址對應網域，再於後續連線中還原相關網域資訊；這不等於「所有 DNS 都經過代理」，也不會自動接管瀏覽器另外啟用的加密 DNS。

新增 DNS 欄位不可單獨複製套用

nameserver-policy 可指定特定網域使用的解析器；proxy-server-nameserver 用於解析代理節點的伺服器網域；respect-rules 則可讓 DNS 上游連線遵循路由規則。啟用後須留意代理節點網域的獨立解析路徑，避免陷入「先建立代理才能解析節點，先解析節點才能建立代理」的循環依賴。

遷移初期建議先保留已知可用的 DNS 上游，只確認網域能否解析、目標規則是否命中，再逐項加入這些欄位。不要直接拼接兩個用戶端的整段 DNS 設定：同名欄位可能遭後者覆蓋，用戶端也可能在啟動前注入自己的監聽位址或策略。

TUN 失敗，問題通常不只在 YAML 語法

• 權限：建立虛擬網卡、修改路由可能需要管理員權限、系統服務或相應的網路權限。
• 路由：自動路由必須與 VPN、虛擬機器網路及其他流量接管軟體協調，避免重複接管。
• DNS 劫持：dns-hijack 中針對 53 連接埠的規則，不代表能接管所有 DoH、DoT 要求。
• 系統代理：供遵循系統代理設定的應用程式使用；TUN 則在虛擬網卡層接管流量，兩者不是同一個開關。

排查時先關閉 TUN，透過明確指定的本機代理連接埠測試節點，再單獨啟用 TUN。如此可區分「節點無法使用」與「系統接管失敗」，避免因路由問題而反覆修改節點密碼。

遷移舊設定：依序驗證基本設定、規則與流量接管

遷移不應從一次複製所有進階欄位開始。先記下原用戶端的監聽連接埠、運作模式、策略群組選擇與核心版本，再建立可還原的副本。以下步驟適用於手動檢查核心，也適合用來找出用戶端產生設定時的問題。

1. 確認實際核心。獨立執行環境可執行 mihomo -v。用戶端環境則查看核心資訊或啟動記錄，區分用戶端版本與核心版本。
2. 檢查設定語法。在設定目錄執行 mihomo -t -f ./config.yaml。若檔案提供者使用相對路徑，也請確認核心的工作目錄設定；語法檢查通過不代表遠端節點連線成功。
3. 固定本機入口。例如設定 mixed-port: 7890，並維持 allow-lan: false。7890 是本例使用的連接埠，不是所有用戶端的固定預設值。
4. 驗證單一節點。先選用一個已知可用的節點，透過本機代理發送要求，再啟用自動策略群組，避免健康檢查與節點切換掩蓋問題。
5. 恢復規則與 DNS。逐一啟用規則提供者，查看連線記錄中的命中規則、策略群組與最終節點，不要只看網頁是否能開啟。
6. 最後啟用 TUN 與嗅探。每次只變更一項功能，並保留變更前後的記錄與生效設定。

mihomo -v
mihomo -t -f ./config.yaml
curl --proxy http://127.0.0.1:7890 --head https://example.com

以上 curl 指令假設本機已安裝 curl，並明確透過 7890 連接埠送出要求。在 Windows PowerShell 中，若 curl 被對應為其他指令，可改用 curl.exe。收到 HTTP 回應代表這次要求的連線路徑可運作，但不代表所有網域、UDP 或 TUN 流量都正常。

優先檢查的舊式寫法

• 舊式鍵名：早期範本中的 Proxy、Proxy Group、Rule，應依目前的設定結構整理為 proxies、proxy-groups、rules，不要依賴舊版相容處理。
• 策略群組引用：rules 引用的群組名稱必須存在，大小寫與空格都要一致；刪除舊群組後，也要一併修改最後的 MATCH。
• 協定專用欄位：不要將其他核心的 JSON 欄位直接貼進 mihomo YAML。相同協定在不同設定格式中，欄位層級與命名可能不同。
• 控制介面：external-controller 與代理監聽連接埠用途不同。若僅供本機管理，請綁定回環位址；如需遠端存取，應設定驗證並限制網路存取範圍。

故障排除：分開確認載入、連線與分流結果

mihomo 的主要優勢在於擴大協定支援與設定能力，而不是讓舊設定在任何環境中都能自動以相同方式運作。遷移是否穩定，不能只看「介面沒有報錯」：應分別確認節點連線、DNS 解析、規則命中與系統流量接管，再恢復日常訂閱更新。用戶端選型可參考用戶端比較；首次安裝與系統權限設定請參閱各平台使用指南。