先釐清用戶端、核心與設定檔格式

mihomo 是網路代理核心，前身為 Clash Meta，負責解析設定檔、建立對外連線、比對規則及處理 DNS。用戶端則提供匯入設定檔、切換系統代理、TUN 模式、選擇代理群組與檢視記錄等功能。用戶端名稱含有 Clash，不代表實際執行的是原版 Clash，也不表示它能讀取所有 mihomo 欄位。

比較「原版 Clash」時，也要區分開源核心與過去的 Clash Premium。兩者曾有功能差異，尤其是 TUN、規則提供者等功能。因此，不能把所有擴充功能都說成「mihomo 首次支援」，也不能只看舊用戶端的介面來判斷核心功能。

  • 用戶端版本：決定介面入口、權限管理及設定檔覆寫方式。
  • 核心版本：決定協定類型、欄位解析方式及網路功能是否可用。
  • 訂閱格式：決定匯入的是節點清單，還是包含 DNS、規則與代理群組的完整設定檔。

協定擴充：能解析節點，不代表連線參數正確

相較於原版開源 Clash，mihomo 擴充了多種出站協定與傳輸能力。常見的遷移需求包括 VLESS、REALITY、Hysteria2 和 TUIC。實際可用的欄位仍取決於安裝的核心版本；若訂閱轉換服務選用舊版 Clash 輸出格式，這些節點或參數可能在匯入前就已遺失。

功能mihomo 設定重點常見遷移問題
VLESStype: vless、UUID、傳輸層與 TLS 參數訂閱轉換時類型遭到篩除，或傳輸參數不完整
REALITYTLS、servername、reality-opts公鑰、短 ID 與伺服器端設定不相符
Hysteria2type: hysteria2、驗證、TLS 與 UDP 可達性網路限制 UDP，或誤用了第一代協定的欄位
TUICtype: tuic、驗證方式與伺服器端協定版本用戶端與伺服器端的版本需求不一致

REALITY 並非獨立的節點類型

不能用 type: reality 取代 VLESS 作為節點類型。常見設定是在 VLESS 節點中啟用 TLS，並設定 reality-opts；若伺服器端採用 Vision，也要確認對應的 flow。節點出現在代理頁面，只代表設定檔已讀取，不表示驗證與交握一定成功。

先驗證單一節點，再遷移整個群組

  1. 確認訂閱輸出格式支援 mihomo 或 Clash Meta，而非僅支援舊版 Clash。
  2. 檢查節點類型、伺服器連接埠、驗證欄位與 TLS 參數是否完整。
  3. 先用一個已知可用的節點連線至目標網站，再查看記錄中的交握或驗證錯誤。
  4. 使用 Hysteria2、TUIC 時，另外確認 UDP 網路條件；不要以 TCP 連接埠的連通結果代替協定測試。

更新核心不會自動將舊節點轉換成新協定，也不會更動伺服器端設定。新協定是否適用，取決於伺服器端支援情況與目前的網路環境，而非協定名稱是否新穎。

rule-providers：將規則來源與規則執行分開管理

rule-providers 用來管理獨立規則集，再透過 RULE-SET 在規則清單中引用。過去的 Clash Premium 已支援規則提供者，mihomo 則在此基礎上繼續擴充規則格式與相關功能。因此，從一般開源 Clash 遷移，與從 Premium 遷移所需的修改並不相同。

以下使用本機規則集，方便先排除遠端下載失敗的因素。兩個檔案皆為範例；主設定片段需合併至現有設定中，不能直接覆蓋，以免遺失原有節點、代理群組與 DNS 設定。

主設定片段

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

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

規則集檔案：rules/local-direct.yaml

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

此範例僅示範如何引用規則，預設全部直連，並非可直接使用的代理分流方案。path 會依核心的工作目錄解析；圖形化用戶端可能使用自己的設定目錄，請從執行中的設定檔或記錄確認實際位置。

  • behavior: domain 用於網域規則集，內容不是完整的 DOMAIN-SUFFIX,... 規則列。
  • behavior: ipcidr 用於 IP 網段規則集，不可混入網域規則。
  • behavior: classical 可使用上例中的傳統規則項目，但仍須符合核心支援的規則類型。
  • format 必須與實際檔案格式一致。mihomo 的 mrs 格式適用於 domain、ipcidr 類型的規則集，不能只把任意 YAML 檔改副檔名就當成 MRS。

規則仍依序比對。若將 MATCH 放在 RULE-SET 前面，後續規則集就不會有比對機會。改用遠端提供者後，還要分別確認下載成功、檔案解析成功，以及請求確實命中規則；這三者並非同一件事。

DNS 設定調整：區分連線網域與節點網域

mihomo 的 DNS 設定提供更細緻的解析路徑控制，例如 nameserver-policy、proxy-server-nameserver，以及讓 DNS 連線遵循路由規則的相關選項。遷移時最容易出錯的，並非少填一個位址，而是 DNS 查詢的出站連線依賴尚未解析的節點網域，造成循環依賴。

先建立最精簡、方便觀察的設定

以下片段說明 fake-ip 與節點網域解析各自負責的部分。127.0.0.1:1053 是本機 DNS 監聽位址，不是系統代理連接埠；只設定監聽位址，不會自動讓所有應用程式使用它。範例中的公共解析器是否適用於目前的網路環境，仍須實際確認。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost"
  nameserver:
    - 223.5.5.5
  proxy-server-nameserver:
    - 223.5.5.5

nameserver 負責一般網域解析；proxy-server-nameserver 則專門解析代理節點的網域。上例將兩者指向同一個解析器，是為了說明欄位用途，並非建議所有環境都使用這個位址。使用加密 DNS 時，也要確認解析器網域的前置解析方式與網路可達性。

fake-ip-filter 不等於直連規則

fake-ip 模式會將合成位址回傳給應用程式，再由核心維護位址與網域的對應關係。將網域加入 fake-ip-filter，代表不為該網域分配 fake-ip，不表示該連線一定會直連。最終的出站方式仍由規則、代理群組與出站模式決定。

遷移初期不建議同時更換上游 DNS、啟用 TUN、開啟嗅探並重寫所有規則。建議先確認 DNS 能取得預期回應，再檢查連線是否命中正確規則。若要啟用 respect-rules，應先設定好節點網域的解析路徑，並核對目前版本的文件，避免 DNS 查詢反過來依賴尚未建立的代理連線。

嗅探：補充網域資訊，不會解密 HTTPS

流量進入核心時若只剩目標 IP，網域規則可能缺少比對依據。mihomo 的 sniffer 可根據 HTTP Host、TLS 交握中的伺服器名稱等資訊嘗試識別網域。啟用嗅探不需要解密 HTTPS 內容，也無法保證從每一條加密連線中擷取到網域。

sniffer:
  enable: true
  sniff:
    HTTP:
      ports: [80, 8080]
    TLS:
      ports: [443]

此範例只在指定連接埠嘗試 HTTP 與 TLS 嗅探，沒有啟用目的位址覆寫等其他功能。若服務使用其他連接埠，請依實際情況調整。不要直接將舊設定中的歷史嗅探欄位拼進新結構；欄位層級不符時，應以目前核心的設定檢查結果為準。

  • 適合檢查的情況：TUN 收到 IP 連線，但預期應依網域分流。
  • 無法取代的設定：DNS 設定、代理群組定義、路由排除項目與應用程式本身的代理設定。
  • 需留意的限制：ECH 等機制可能隱藏可見的伺服器名稱，部分流量也沒有可識別的網域。

若啟用嗅探後特定網站的連線行為改變，請先針對該網域調整嗅探範圍或暫時關閉嗅探，再比對連線記錄。不要靠擴大嗅探連接埠範圍來掩蓋 DNS 或路由問題。

TUN 與系統代理：更新核心不會自動切換流量入口

系統代理仰賴應用程式遵循作業系統的代理設定。TUN 模式則透過虛擬網卡接收 IP 流量，需要用戶端正確處理權限、路由與 DNS。mihomo 支援 TUN，但不同平台、用戶端與版本的接入方式各異，不能只複製一段 tun: 設定，就認定所有流量都已接管。

例如，本機混合連接埠設為 7890 時，遵循系統代理設定的應用程式可透過該連接埠進入核心。DNS 監聽連接埠 1053 則是另一個入口。兩者用途不同，不應將系統 HTTP 代理位址設為 DNS 監聽連接埠。

初次遷移時，可先關閉 TUN，透過系統代理驗證訂閱與節點，再單獨啟用 TUN。若出現區域網路、印表機或其他 VPN 連線異常，應優先檢查路由重疊、DNS 接管與排除項目，而非先懷疑節點協定。

舊設定檔遷移：從語法、資源與連線三層排查

第一層：檢查最終執行中的設定檔

先備份訂閱檔、自訂覆寫設定與代理群組選擇。用戶端可能在啟動核心前合併多個來源，因此在編輯器中看到的檔案不一定是最終執行中的設定檔。請檢查用戶端匯出的執行設定，確認 dns、rules 與 proxy-groups 沒有被覆寫成另一套內容。

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

-t 用於檢查設定檔。檢查通過代表核心能接受該設定，不代表遠端規則一定下載成功，更不代表節點可以連線。若核心由用戶端管理，請優先使用用戶端提供的檢查功能，避免誤用另一個版本不同的執行檔。

第二層：確認外部資源與名稱引用

  1. 確認代理群組所引用的節點或提供者確實存在，且名稱完全一致。
  2. 確認 RULE-SET 的名稱與 rule-providers 中的鍵相符。
  3. 檢查規則檔案路徑、遠端資源請求與解析錯誤，分辨是網路連線失敗還是檔案格式不符。
  4. 確認訂閱更新後自訂設定仍然生效，不要只修改下次更新時會被覆蓋的快取檔案。

第三層：以固定請求驗證結果

確認混合連接埠確實設為 7890 且核心正在執行後，可使用下方命令明確透過 HTTP 代理發出請求，避免測試工具是否遵循系統代理設定所造成的混淆。

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com/

此處的 10 秒與 20 秒分別限制連線等待時間與整個請求的時長，並非速度評分。測試後請在連線頁確認目標網域、命中的規則與實際出站節點；若發生錯誤，再到記錄頁查看具體原因。交握失敗時先檢查節點參數，規則不符時先檢查順序與網域資訊；若沒有連線記錄，則先檢查流量入口。

遷移完成的判準是：設定檢查通過、所需資源載入成功、應用程式流量進入核心、規則命中符合預期，以及節點連線正常。逐項確認這五點，比一次啟用所有新功能更容易找出問題，也能保留可還原的舊設定。