先說結論：舊設定通常可遷移，新功能無法反向通用
如果訂閱仍是常見的 Shadowsocks、VMess 或 Trojan 節點，規則主要使用 DOMAIN-SUFFIX、IP-CIDR 和 MATCH，遷移到 mihomo 通常不必重寫整份 YAML。真正需要逐項確認的是節點擴充參數、規則集格式、DNS 設定，以及用戶端是否會覆寫手動修改的欄位。
mihomo 是 Clash Meta 專案後續使用的名稱，沿用 Clash 的設定體系，並持續擴充協定與流量處理能力。它是核心，不等同於某個帶有圖形介面的 Clash 用戶端。用戶端負責管理訂閱、切換系統代理及合併設定；核心負責建立連線、執行規則與處理 DNS。只更換介面程式，不一定代表實際執行的核心也換了。
原版專案已停止維護。若需要新協定、持續更新的規則功能或較新的系統支援，應優先評估仍在維護的核心；但「核心更新」不代表所有節點都會更快。線路品質、伺服器設定、網路封包遺失，以及實際命中的出站策略，都會直接影響連線表現。
協定支援：先看節點類型，再確認握手參數
| 節點或功能 | 原版 Clash 開源核心 | mihomo 遷移檢查 |
|---|---|---|
| Shadowsocks、VMess、Trojan | 支援常見設定 | 確認加密方式、傳輸層與 TLS 參數 |
| VLESS、Reality | 不支援相應的新式組合 | 確認伺服器要求的 flow、指紋、公鑰與 short-id |
| Hysteria2、TUIC | 不支援 | 檢查 UDP 連線狀況及協定專用的驗證欄位 |
| 較新的加密與傳輸擴充功能 | 受舊版限制 | 依實際演算法、傳輸類型及核心版本確認 |
「支援 VLESS」不代表任何 VLESS 連結都能直接使用
節點的 type 只是第一層。VLESS 搭配 Reality 時，還可能需要設定 servername、client-fingerprint，以及 reality-opts 下的公鑰與短識別碼；使用 Vision 時也要確認 flow。這些參數必須符合伺服器設定，不能直接複製其他節點的值沿用。
- 出現「不支援的代理類型」：先確認實際使用的核心是否為 mihomo，不要只看用戶端名稱或訂閱檔名。
- 設定檢查通過，但 TLS 交握失敗：檢查系統時間、SNI、憑證網域名稱及 Reality 參數；不要一開始就關閉憑證驗證。
- Hysteria2 或 TUIC 連線逾時：確認目前網路與伺服器允許 UDP。瀏覽器能透過其他 TCP 節點開啟網頁，並不能證明 UDP 連線正常。
訂閱轉換也有其限制：轉換工具可以調整欄位結構，卻不能把 Hysteria2 伺服器自動轉成原版 Clash 支援的 VMess 伺服器。若用戶端無法辨識新協定，請改用相容的核心，或選擇服務提供者明確支援的其他節點。
規則擴充：保留基礎語法，確認規則集格式
Clash 常用規則仍會依清單順序由上而下比對，命中第一條規則後便選定出站策略。遷移時可以先保留既有規則順序，不要一次調整數十條規則。尤其要確認規則所引用的策略組確實存在，並在最後用 MATCH 處理前面未命中的連線。
rules:
- DOMAIN-SUFFIX,example.com,Proxy
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- MATCH,Proxy這裡的 Proxy 必須是設定中已有的策略組或出站名稱；example.com 是用來示範語法的保留範例網域。no-resolve 表示這條 IP 規則不會主動觸發網域解析，並非關閉整個核心的 DNS。如果連線本身已有目標 IP，仍可依該 IP 進行比對。
rule-providers 與 RULE-SET 屬於不同層級
rule-providers 用來定義規則的來源及解析方式；RULE-SET 則是在主規則清單中引用規則集。mihomo 支援規則提供器，也提供更多規則組合與比對功能；Premium 使用者可能已經用過其中部分機制。
rule-providers:
private-net:
type: file
behavior: classical
format: yaml
path: ./rules/private.yaml
rules:
- RULE-SET,private-net,DIRECT
- MATCH,Proxy對應的 ./rules/private.yaml 檔案可以包含以下內容。相對路徑通常是以核心的工作目錄為基準，不一定是介面程式所在的目錄；找不到檔案時，請先查看啟動記錄中的工作路徑。
payload:
- IP-CIDR,10.0.0.0/8,no-resolve
- IP-CIDR,172.16.0.0/12,no-resolve
- IP-CIDR,192.168.0.0/16,no-resolvebehavior: classical可使用包含規則類型的項目，例如上方的IP-CIDR。behavior: domain和behavior: ipcidr各自使用對應的內容格式，不要直接混入完整的 classical 規則行。- mihomo 的 MRS 二進位規則集適用於 domain 或 ipcidr 類型，不能只把任意 classical YAML 改個副檔名，就當成 MRS 使用。
- 邏輯規則、程序比對等擴充功能都應逐項驗證。程序辨識也會受作業系統、權限及流量接管方式影響。
遷移後若大量網站都套用預設策略，請先確認規則集是否成功載入，再檢查規則順序。能下載規則集網址，不代表其內容格式符合 behavior 設定。
DNS 差異：保留基本欄位，分開驗證解析與出站
原版 Clash 已具備 DNS 模組及 Fake-IP 等基本功能，mihomo 則進一步支援依網域選擇解析器、控制節點網域解析等方式。DNS 回傳正確位址與連線使用正確策略是兩回事：前者決定要連到哪個目標，後者決定透過哪個出口連線。
舊設定中哪些欄位可以先沿用
常見的 dns.enable、listen、enhanced-mode、fake-ip-range 與 nameserver 可作為遷移起點。以下只是方便理解的 DNS 設定片段，不包含完整節點與策略組，也不會自動變更系統 DNS。
dns:
enable: true
listen: 127.0.0.1:1053
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
nameserver:
- 223.5.5.5
- 119.29.29.291053 是此範例的本機 DNS 監聽連接埠；一般系統 DNS 設定通常只填伺服器位址，不能同時填入這個連接埠。若要接管系統解析，需另外設定轉送，或在適用情境下啟用 TUN 的 DNS 劫持。198.18.0.1/16 用於 Fake-IP 對應，並非遠端網站的真實公網位址。
不要一次啟用所有新功能
- nameserver-policy：為指定網域或網域集合選擇解析器，適合分別處理內網與公網網域。
- proxy-server-nameserver：指定代理節點伺服器網域的解析路徑，避免解析節點位址時又依賴尚未建立的代理連線。
- fake-ip-filter：將確實有相容性問題的網域排除於 Fake-IP 之外；不要只因一個區域網路服務就取消整套分流設定。
驗證時應分別檢查用戶端 DNS 記錄、連線詳細資訊中的網域及最終套用的策略。瀏覽器內建的安全 DNS 可能使用獨立的解析路徑；只修改核心 DNS，無法證明瀏覽器的每次查詢都經過該核心。
TUN 與流量嗅探：接管範圍不同於規則模式
系統代理主要供會讀取系統代理設定的應用程式使用；TUN 則透過虛擬網路介面接管流量，適合處理不讀取系統代理設定的程式。TUN 決定流量如何進入核心，規則模式則決定流量進入後使用哪個出站方式，兩者並非互斥選項。
原版開源核心的能力不能與 Premium 的 TUN 功能混為一談。遷移至 mihomo 後，也不能只複製一段 tun 設定就認定功能已生效：用戶端可能要求安裝服務、授予系統管理員權限，或由圖形介面產生並覆寫相關欄位。
- 先用系統代理驗證訂閱、節點與規則；設定尚未通過前，不要再加入 TUN。
- 關閉其他 VPN 或虛擬網卡工具進行比對，避免預設路由互相競爭。
- 啟用 TUN 後，查看記錄中的虛擬介面與路由建立結果，確認沒有權限錯誤。
- 測試區域網路印表機、NAS 與公司內網位址，必要時設定明確的略過規則或路由排除。
mihomo 的流量嗅探可從部分 HTTP、TLS 或 QUIC 流量中擷取主機資訊，協助比對網域規則，但不等於解密 HTTPS 內容，也無法保證辨識所有連線。加密 ClientHello 等機制可能會限制可見資訊。嗅探設定應依照實際分流需求啟用，不應當成解決所有 DNS 問題的通用補丁。
遷移舊訂閱：依設定來源逐項處理
| 設定項目 | 一般處理方式 | 必須檢查項目 |
|---|---|---|
| mixed-port、mode、log-level | 可先沿用 | 連接埠衝突、用戶端覆寫值 |
| proxies、proxy-groups | 保留基本架構 | 協定欄位、群組內節點名稱、測試網址 |
| rules | 保留常用規則 | 引用名稱、規則順序、MATCH 位置 |
| rule-providers | 確認格式後再沿用 | behavior、format、檔案路徑及載入結果 |
| dns、tun | 分階段啟用 | 系統權限、路由、解析依賴與介面合併設定 |
| Premium script 腳本規則 | 不能假設可直接相容 | 改寫為 mihomo 支援的規則或規則集 |
實際遷移步驟
- 備份原始設定：分別保存訂閱原文與用戶端目前產生的執行設定。兩者可能不同，排查時不要只查看訂閱編輯器。
- 確認核心資訊：在用戶端的核心資訊或啟動記錄中查看名稱與版本。若使用獨立執行檔，請執行
mihomo -v查看版本。 - 先測試設定：在設定檔所在目錄執行
mihomo -t -f ./config.yaml。Windows 獨立執行檔可使用.\mihomo.exe -t -f .\config.yaml。 - 先確認單一路徑可用：選擇一個已知可用的節點，啟用系統代理，再以規則模式開啟測試頁面。
- 逐項恢復擴充設定：依序啟用規則集、DNS 策略與 TUN，每次只修改一類設定並查看記錄。
- 最後再更新訂閱：確認自訂規則沒有遺失，再設定自動更新與開機啟動。
設定測試通過，只能表示核心可以讀取設定，並不保證訂閱節點在線、規則集下載成功或系統代理已啟用。具圖形介面的用戶端也可能在啟動前合併設定，因此命令列測試所用的檔案應盡量與用戶端實際執行的檔案一致。
遷移後驗證：分開檢查連接埠、規則與 DNS
假設執行設定中的 mixed-port 為 7890，可以先透過明確指定代理來測試。這樣能排除系統代理設定是否正確這項變因；連接埠請替換為用戶端實際顯示的值。
curl -I --proxy http://127.0.0.1:7890 https://example.com在 Windows PowerShell 中可使用 curl.exe，避免部分環境中同名命令別名影響參數解析。這項測試只驗證此次 HTTP 代理請求，不代表 UDP、TUN 或其他應用程式也已正常運作。
- 提示連線遭拒：優先確認核心是否已啟動、本機連接埠是否正確，以及是否被其他程序佔用。
- 代理可連線，但請求逾時：檢查所選節點、節點網域解析及伺服器是否可連線。
- 頁面能開啟，但出口不符：在連線詳細資訊中確認命中的規則、策略組目前的選擇，以及是否實際處於全域模式。
- 只有某個應用程式無法使用：確認它是否會讀取系統代理；若確定不會，再評估使用 TUN，不要反覆更換訂閱。
最終選擇其實很直接：需要 VLESS Reality、Hysteria2、TUIC，或更細緻的規則與 DNS 控制，就使用支援這些功能的 mihomo 用戶端；遷移基本訂閱時，則先沿用穩定的設定。將核心相容性、設定合併與網路連線分開驗證，比一次替換所有設定更容易找出問題。
欄位詳情可參閱Clash 設定手冊；遇到連接埠佔用、系統代理未生效或權限問題，可參照常見問題逐項檢查。