1. 先釐清用戶端、核心與訂閱的差異
Clash for Windows（CFW）原專案已停止維護。舊版安裝程式仍可能啟動，既有節點也可能繼續連線，但這不代表圖形介面、相依元件和代理核心仍會獲得修復。遷移的目的不是把舊程式換個名稱，而是將訂閱來源、本機規則和系統接管方式移轉到仍持續維護的用戶端。
Clash Meta 是 Clash 的衍生核心專案，後來更名為 mihomo。圖形用戶端負責管理訂閱、系統匣選單、系統代理和服務安裝；mihomo 核心則負責解析設定、建立連線、處理 DNS 與比對規則。選擇支援 mihomo 的用戶端，不代表它能直接讀取 CFW 的整個使用者目錄。
- 訂閱：通常是含有存取憑證的 URL，會回傳節點清單或完整的 YAML 設定。帳號權限、流量和有效期限仍由訂閱服務提供者管理。
- 核心設定：常見的設定鍵包括
proxies、proxy-groups、rules、dns和tun。 - 用戶端資料：包含訂閱索引、介面偏好設定、更新排程、覆寫掛載關係等，格式由各用戶端決定。
- 系統接管：系統代理、TUN 虛擬網卡和背景服務屬於另一層狀態，光複製 YAML 無法完成遷移。
2. 依平台挑選 mihomo 用戶端
先確認作業系統架構，再檢查設定編輯與覆寫功能。安裝套件名稱中的 x64、ARM64 代表不同處理器架構；macOS 的 Apple 晶片版和 Intel 版也要分清楚。用戶端版本號與核心版本號是兩套編號，安裝後應分別在「關於」或「核心」頁面確認，不能只憑介面名稱判斷目前使用的核心。
| 平台 | 可考慮的用戶端 | 遷移前應確認的項目 |
|---|---|---|
| Windows | Clash Verge Rev、Clash Nyanpasu、FlClash | 訂閱覆寫入口、服務安裝權限、開機啟動方式，以及 TUN 接管方式。 |
| macOS | Clash Verge Rev、FlClash、ClashX Meta | 晶片架構、系統代理授權，以及所選發行版提供的進階接管功能。 |
| Linux | Clash Verge Rev、FlClash，或獨立的 mihomo 核心 | 發行版套件格式、桌面系統匣支援、服務權限和設定目錄。 |
| Android | FlClash 等採用 mihomo 核心的用戶端 | VPN 授權、背景執行限制、依應用程式設定代理，以及訂閱更新方式。 |
| iOS / iPadOS | 先確認用戶端明確支援的訂閱格式 | 支援 Clash 設定不等於使用 mihomo；規則和指令碼可能需要重新調整。 |
桌面版先確認三個功能入口
- 在「訂閱」或「設定檔」頁面確認能否從 URL 匯入，並單獨更新目前的訂閱。
- 在「設定」中找出連接埠、系統代理、TUN 和核心記錄；先記下目前設定值，不必急著啟用所有功能。
- 找出設定覆寫、設定合併或指令碼入口，確認它套用於單一訂閱還是全域設定。
選單名稱會因用戶端和版本而異。以 Clash Verge Rev 為例，可先從「訂閱」匯入連結，再到「設定」尋找系統代理、虛擬網卡和服務相關選項。如果介面入口不同，請先查閱目前版本的文件，不要直接套用 CFW 的選單路徑。各平台的安裝入口請見用戶端下載頁。
3. 備份 CFW 設定並整理遷移清單
Windows 上 CFW 常見的使用者目錄是 %USERPROFILE%\.config\clash，但可攜式安裝、啟動參數或自訂目錄可能會改變位置。請在舊用戶端選取「General」→「Home Directory」，開啟實際目錄；若介面顯示路徑欄位或「開啟資料夾」按鈕，請以畫面顯示的位置為準。
結束舊用戶端後，將整個設定目錄複製到僅供本人存取的備份位置，再分項整理以下內容。只保留目前選取的 YAML，往往會漏掉訂閱網址和設定增強邏輯。
- 訂閱來源：保存原始 URL、訂閱名稱、更新間隔，以及是否為本機檔案。不要只記下節點名稱。
- 本機設定：保存
profiles中使用的 YAML 和相關資源，並註明哪些是手動編輯的設定檔、哪些會隨訂閱更新而刷新。 - 擴充內容：匯出或複製 CFW 的 Parsers、合併規則、指令碼及其比對條件。
- 執行參數：記下 HTTP、SOCKS 或混合連接埠、是否允許區域網路存取，以及 DNS、TUN 和略過位址設定。
- 策略選擇：記下常用代理群組目前選取的節點；選取狀態不一定能轉移到其他用戶端。
4. 先遷移訂閱，再檢查代理群組與規則
第一輪只確認基本連線
- 關閉舊用戶端的系統代理、TUN 和自動啟動功能，然後結束舊程式；如果曾安裝背景服務，也要確認服務已停止。
- 開啟新用戶端，使用原始訂閱 URL 建立訂閱。不要將舊用戶端的整個資料目錄覆蓋到新目錄。
- 更新訂閱並選取設定檔，查看記錄中是否出現 YAML 解析錯誤、未知通訊協定或代理群組參照不存在等訊息。
- 選擇規則模式，手動指定一個節點。先使用系統代理測試瀏覽器，暫時保持 TUN 關閉。
訂閱可能只包含節點，也可能包含完整的 proxy-groups 和 rules。只有節點的訂閱需要搭配用戶端範本或自行準備的主要設定；如果匯入後只有節點、沒有可用的策略群組，應先確認訂閱類型，而不是直接認定 mihomo 不相容。
遷移規則時，順序與參照必須一致
rules 會由上而下比對，MATCH 通常放在最後。自訂網域規則應插在預設規則之前；規則參照的代理群組名稱必須與 proxy-groups 完全一致，包括空格和大小寫。以下片段僅用來說明規則順序，不是完整的訂閱設定：
rules:
- DOMAIN-SUFFIX,example.com,DIRECT
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
- MATCH,出口選擇這段設定要求已存在名為「出口選擇」的代理群組。範例網域僅用來展示語法，請換成實際需要直連的網域。若使用用戶端的「前置規則」功能，通常只需填入清單項目，不要再多包一層 rules:。實際輸入格式請以該功能的說明為準。
使用 rule-providers 時，也要遷移每個 provider 的 type、behavior、format、url、path 和更新間隔。相對路徑 path 會依賴新核心的工作目錄；如果舊快取目錄沒有一併遷移，就必須允許重新下載，不能把「規則檔案不存在」誤判為節點故障。
5. 將 Parsers 與覆寫指令碼改寫為新用戶端格式
CFW 的 Parsers 不是 mihomo 通用的設定標準。即使兩者都能使用 JavaScript，接收設定的參數、回傳值、執行順序和可用介面仍可能不同。將舊指令碼原封不動貼到新用戶端，可能導致指令碼無法執行、訂閱更新失敗，或雖然執行成功卻覆蓋其他設定。
固定設定優先改用宣告式覆寫
連接埠、模式和區域網路開關等固定值，優先透過新用戶端的設定介面或合併設定處理。以下列出遷移時需要核對的設定鍵，不建議直接覆蓋訂閱中的整份設定：
mixed-port: 7890
allow-lan: false
mode: rule
log-level: infomixed-port: 7890 會讓同一個連接埠接收 HTTP 與 SOCKS 要求，但用戶端可能在產生最終設定時重新指定連接埠。修改後應開啟實際執行的設定確認，而不只是查看覆寫檔案。合併清單時也要特別留意：有些入口會取代整個 rules 陣列，有些則支援前置和附加，兩者結果截然不同。
需要指令碼時，逐項重建轉換邏輯
- 先說明舊指令碼的用途，例如刪除特定節點、新增代理群組或修改 DNS，避免把所有歷史遺留邏輯一併帶過去。
- 依照新用戶端文件提供的指令碼入口編寫，確認函式簽章、回傳完整設定的方式，以及錯誤如何顯示。
- 每次只遷移一項修改。執行後檢查節點數量、代理群組成員和規則順序，再處理下一項。
- 手動更新一次訂閱，確認本機修改仍然存在；更新後仍然生效，才能確認覆寫已正確掛載。
不要混淆舊版 Clash 的核心指令碼設定與用戶端的 JavaScript 預處理。遇到 script 等舊欄位時，請確認 mihomo 目前是否支援，並盡量改用明確的規則、規則集或用戶端預處理邏輯。
6. 分開測試連接埠、DNS 與 TUN 模式
瀏覽器可以連線，只能證明這一條存取路徑正常。命令列工具、遊戲、區域網路裝置和 UDP 流量可能使用不同路徑。遷移驗證應分層進行，每次只調整一個變數。
| 驗證項目 | 操作方式 | 觀察重點 |
|---|---|---|
| 本機連接埠 | 確認新用戶端的混合連接埠是否為 7890。 | 記錄中是否有連接埠占用錯誤；終端機的代理環境變數是否仍指向舊連接埠。 |
| 明確指定代理 | 使用 curl 指定 127.0.0.1:7890 發出要求。 | 是否出現連線記錄，以及命中的規則和出口是否符合預期。 |
| 系統代理 | 啟用系統代理後，用瀏覽器瀏覽實際使用的網站。 | 應用程式是否遵循系統代理，以及是否受舊 PAC 設定影響。 |
| DNS 與 TUN | 基本連線正常後再啟用 TUN，分別測試網域、區域網路和 UDP 應用程式。 | DNS 接管、路由衝突、虛擬網卡權限和本機服務存取。 |
可在 Windows PowerShell 使用以下命令檢查連接埠和明確指定的 HTTP 代理。這裡指定 curl.exe，避免舊版 PowerShell 中 curl 別名造成參數差異；測試網址請換成實際需要驗證的服務。
Get-NetTCPConnection -LocalPort 7890 -State Listen
curl.exe --proxy http://127.0.0.1:7890 --head --max-time 15 https://example.com明確指定 HTTP 代理的要求，無法證明 UDP 已被接管。啟用 TUN 後，還應另外測試需要 UDP 的應用程式，並查看連線記錄。DNS 方面，如果舊設定使用 enhanced-mode: fake-ip，也要確認 fake-ip-filter 是否符合本地域名解析需求；企業內網網域通常依賴內部 DNS，不應一律交由公共 DNS 解析。
必要時使用核心檢查設定
如果已取得獨立的 mihomo 執行檔，可在設定目錄執行語法檢查。以下範例適用於 Windows 目前目錄中同時有核心和設定檔的情況；用戶端內部產生的設定應優先使用內建檢查功能。
.\mihomo.exe -t -d . -f .\config.yaml-t 用來測試設定，-d 指定工作目錄，-f 指定設定檔。檢查通過不代表節點可連線，也無法驗證訂閱權限、遠端規則下載和實際 DNS 行為，仍須搭配執行記錄進行排查。
7. 完成更新測試後，再清理舊用戶端
建議至少完成一次手動訂閱更新、一次系統重新啟動，以及一次日常網路切換。重新啟動後確認只有新用戶端會自動啟動；從有線網路切換至 Wi-Fi 後，再檢查 TUN 路由和區域網路存取。這類驗證比只測一次延遲更貼近日常使用情況。
- 更新檢查：訂閱刷新後，自訂規則、策略群組和 DNS 覆寫仍然有效。
- 應用檢查：分別測試瀏覽器、終端機、開發工具和區域網路服務，不能只測一個網頁。
- 服務檢查：舊用戶端的背景服務、開機工作和系統代理設定不再接管網路。
- 回復準備：保留受保護的原始備份，並記錄新用戶端版本、核心版本和遷移日期。
等新設定穩定後，再透過舊用戶端原有的服務管理入口解除安裝背景服務並清理程式。如果遷移失敗而需要回復，請先關閉新用戶端的 TUN 和系統代理並停止核心，再還原舊環境；不要同時啟動兩套程式比較結果。