一、先釐清客戶端、核心與訂閱的差異
Clash for Windows（簡稱 CFW）停止維護後，既有設定或許仍能連線，但客戶端相容性調整、相依套件更新與錯誤修正都不會再持續。遷移的目的不是把舊資料夾整個複製到新程式，而是分別還原訂閱來源、個人規則及系統流量接管方式。舊版客戶端的資料庫與服務元件也無法直接沿用於新客戶端。
Clash Verge Rev 是桌面圖形介面客戶端；Mihomo 則是負責解析設定、比對規則與建立連線的核心。Mihomo 延續 Clash Meta 的技術路線，可用的設定欄位不等同於早期 Clash 核心。訂閱是遠端設定來源，可能包含節點、策略群組、規則與 DNS 設定。這三者都要分別檢查，不能只憑「訂閱匯入成功」就認定全部設定正常。
二、如何挑選替代客戶端：先確認設定工作流程
Windows 使用者可優先評估採用 Mihomo 的 Clash Verge Rev、Clash Nyanpasu 和 FlClash。專案是否仍在維護，應以遷移當天的發布紀錄、問題回報處理情形及核心更新紀錄為準，不要只看下載頁標示「最新版」。名稱相似的分支也不代表是同一個專案。
| 候選客戶端 | 適合的遷移需求 | 安裝前確認事項 |
|---|---|---|
| Clash Verge Rev | 訂閱管理、本機 Merge 或腳本處理、桌面系統代理與 TUN | 目前版本的覆寫綁定方式、服務安裝狀態與核心版本 |
| Clash Nyanpasu | 桌面設定管理與設定處理流程 | 目前版本採用的核心，以及本機設定處理功能 |
| FlClash | 希望在桌面與行動裝置上維持相近的操作習慣 | 支援平台、設定匯入方式與本機規則編輯方式 |
如果舊 CFW 主要用來管理訂閱和少量 YAML 參數，Verge Rev 的 Merge 工作流程通常比較容易對照。若仰賴複雜的 Parsers 腳本，選型時應著重腳本介面、執行順序與更新行為，而非介面是否相似。其他平台的資訊可參考客戶端比較。
三、舊 CFW 要備份哪些內容？
趁舊客戶端還能啟動時完成備份。從 CFW「Settings」中的設定資料夾入口開啟使用者資料目錄；目錄位置可能因安裝方式與版本而異，不要只搜尋安裝目錄。先將整個使用者設定資料夾複製到離線備份位置，再整理下方的遷移清單。
- 原始訂閱網址：記下每個訂閱的名稱、網址與更新間隔。含有權杖的訂閱網址等同存取憑證，請勿貼到公開的問題回報中。
- Parsers 內容：保留比對條件、YAML 修改項目與原始腳本，並註明各自套用在哪個訂閱。
- 本機規則：記下規則順序、引用的策略群組名稱、規則集網址及相依的本機檔案。
- 連接埠與系統接管設定：記下 HTTP、SOCKS、混合連接埠、是否允許區域網路連線，以及系統代理和 TUN 的狀態。
- 個人偏好：記下規則模式、常用策略群組所選的節點，以及自訂 DNS 項目。
不要只把訂閱暫時產生的節點清單當成唯一備份。訂閱更新時，節點名稱、憑證或策略群組可能會變更；只複製目前的 YAML，可能會失去後續更新能力。如果已找不到原始網址，可以先匯入現有 YAML 作為本機設定並確認能否運作，再向訂閱服務提供者索取更新網址。
備份完成後，關閉 CFW 的系統代理、TUN 和開機啟動功能，再結束程式。如果舊服務仍在接管網路，請先停止服務。保留舊程式以便回復即可，不要讓兩個客戶端同時控制系統代理或虛擬網卡路由。
四、匯入訂閱：先確認未套用覆寫的基準狀態
- 啟動 Clash Verge Rev，前往「訂閱」頁面，透過新增或匯入功能加入原始訂閱網址。按鈕名稱可能因版本而異。
- 更新訂閱並設為目前使用的設定。確認代理群組與節點都已顯示；只看到訂閱名稱而沒有節點，並不算匯入完成。
- 在「代理」頁面選擇規則模式，再檢查主要策略群組的選項。自動選擇群組和手動選擇群組的運作方式不同，舊客戶端的選取狀態通常不會自動遷移。
- 暫時關閉 TUN，只開啟系統代理；用瀏覽器測試一個直連網站和一個需要代理的網站，再前往「連線」頁面查看規則與連線出口。
匯入失敗時，依錯誤類型排查
HTTP 401 或 403 通常應檢查權杖、帳戶權限與訂閱網址；發生逾時則要分別確認 DNS、網路連線及下載路徑。若是 YAML 解析錯誤，請確認伺服器回應內容是否其實是網頁或錯誤訊息。若缺少策略群組或引用了不存在的節點，應查看核心記錄，而不是一再切換系統代理。
不要隨意把原訂閱提交到線上轉換網站。若必須轉換，先確認服務提供者是否直接支援 Mihomo 設定；透過第三方轉換就必須額外交付訂閱憑證。基準狀態尚未確認正常前，先不要再疊加 DNS、規則與 TUN 設定。
五、將 Parsers 改為 Merge：依實際修改內容遷移
CFW Parsers 是客戶端端的設定處理機制，不是核心通用欄位。舊檔案中的 parsers:、比對條件或 JavaScript 函式，不能直接貼進 Mihomo 主設定。遷移時應先釐清「修改了哪些設定」，再選擇 Verge Rev 的 Merge 或腳本處理方式。
| 舊 Parsers 的處理方式 | 遷移方式 | 需確認的重點 |
|---|---|---|
| 覆寫純量或物件欄位 | 優先使用 Merge，並依目標設定的 YAML 結構撰寫 | 欄位階層、值的型別與執行時的最終值 |
| 在規則前方或後方加入規則 | 使用目前版本明確支援的清單操作；否則改用腳本 | 是否保留訂閱原有規則，以及規則插入位置 |
| 重新命名節點、依條件修改策略群組 | 重新撰寫符合新客戶端介面的腳本 | 同步更新名稱引用，並確保腳本回傳完整設定 |
| 依訂閱網址套用不同處理方式 | 將相應覆寫綁定至對應的訂閱 | 切換訂閱後，是否會誤套用到其他設定 |
Merge 範例：遷移記錄層級與 DNS 快取策略
以下 YAML 適用於目前核心支援 cache-algorithm 的情況。範例只修改兩個明確欄位，不會改寫訂閱中的上游 DNS、代理群組或規則。如果舊 Parsers 的用途就是設定這兩個參數，可在「訂閱」頁面新增 Merge 類型的本機處理項目，並透過目前版本提供的管理功能綁定至目標訂閱。
log-level: info
dns:
cache-algorithm: arc儲存後重新套用設定，確認執行時設定中的 log-level 是否為 info，以及 dns.cache-algorithm 是否為 arc。如果核心提示欄位不存在，請先確認實際使用的核心版本與設定文件，不要忽略錯誤來完成遷移。若原訂閱未啟用 DNS，這段範例也不會替你啟用 DNS。
規則陣列不能當成一般欄位直接搬移
YAML 中的 rules 是有順序的清單，通常由上而下比對，第一個符合的規則就會生效。把只有兩條規則的 rules: 放進 Merge，不代表一定會得到「在前方插入兩條規則」的結果；清單處理方式取決於客戶端的實作與版本，也可能直接覆蓋原清單。舊 Parsers 的 prepend-rules 也不是可直接交給 Mihomo 使用的欄位。
- 先用範圍很小的測試規則確認結果，例如
DOMAIN,example.com,DIRECT，不要一開始就修改全域預設規則。 - 檢查最終規則清單：測試規則應位於預期位置，訂閱原有規則仍然存在，而且
MATCH仍位於最後。 - 引用訂閱中的策略群組時，群組名稱必須完全一致；空格、大小寫或符號不同，都可能導致引用失效。
- 舊腳本若包含條件判斷，請依新客戶端的腳本函式簽章重新撰寫。不要假設 CFW 的參數、輔助函式與回傳方式都能原封不動沿用。
六、遷移連接埠：維持使用方式，不要照抄預設值
舊 CFW 常見的 HTTP 連接埠是 7890、SOCKS 連接埠是 7891，但實際值可能已經修改。Verge Rev 的預設連接埠也可能因版本或既有使用者資料而不同。請以「設定」中的連接埠項目和執行時設定為準；遷移時要嘛沿用原連接埠，要嘛同步更新所有呼叫端。
例如，若決定統一使用 127.0.0.1:7890 作為混合連接埠，可在客戶端對應的連接埠設定中調整，再確認最終欄位。混合連接埠可同時接收 HTTP 與 SOCKS 請求，但不代表舊的獨立連接埠會自動轉送至此。
mixed-port: 7890
allow-lan: false這段設定只表示本機混合連線入口；GUI 管理的欄位可能會覆蓋 Merge 中的同名項目，請優先在客戶端對應設定中調整。一般本機使用不需要開啟區域網路存取。若確實要讓其他裝置使用代理，還應另外設定監聽位址、驗證方式與防火牆範圍。
Windows 上的兩項檢查
netstat -ano | findstr :7890
curl.exe --proxy http://127.0.0.1:7890 https://example.com/ -I第一個指令用來檢查連接埠是否被占用，以及占用程序的編號；若是舊客戶端占用，請先停止舊程序。第二個指令會明確透過 HTTP 代理送出請求，可用來區分「代理入口可用」與「應用程式是否使用系統代理」。HTTP 回應狀態仍須配合目標網站判斷，不能只因指令執行完畢就認定代理連線正常。
終端機環境變數、Git 的代理設定、瀏覽器擴充功能和下載工具，都可能仍使用舊連接埠。系統代理通常不會替這些應用程式改寫各自的設定。外部控制介面 external-controller 是管理 API，不是上網用的代理連接埠；不要填入瀏覽器代理位址，也不要為了遷移而開放給所有網卡使用。
七、最後恢復 TUN 與 DNS，避免重複接管流量
系統代理需要應用程式遵循系統代理設定；TUN 則透過虛擬網卡與路由接管更多流量，兩者不是同一個開關。確認基準設定與覆寫都穩定後，再依客戶端提示安裝或啟動所需服務、開啟 TUN，並查看虛擬網卡、路由與記錄。Windows 若遇到服務權限問題，應檢查服務狀態，不要直接搬用舊 CFW 的服務檔案。
- 確認舊 CFW 的 TUN 已關閉，並結束其他可能接管預設路由的 VPN 工具；若使用企業 VPN，請先遵守組織的網路規範。
- 啟用 Verge Rev 的 TUN，先測試一般網站，再測試原本不遵循系統代理設定的應用程式。
- 查看連線頁面是否顯示相應的程序、目標與規則。如果請求沒有進入核心，應先排查流量接管範圍，而不是修改節點。
- 若網域解析失敗但 IP 位址可連線，請檢查 DNS 上游、DNS 劫持設定與記錄；不要同時修改解析模式和所有 DNS 伺服器。
使用 Fake-IP 時，應用程式可能會取得合成位址，常見的位址池為 198.18.0.1/16，實際情況以設定為準。這不是目標的真實位址，也不能據此判定 DNS 遭到污染。切換舊 DNS 模式後，如果 Windows 仍快取舊結果，可執行 ipconfig /flushdns 清除快取，再重新啟動受影響的應用程式。
區域網路印表機、NAS 或公司內部網域發生異常時，請分別確認 DNS 是否能解析內部名稱、規則是否設為直連，以及 TUN 路由是否涵蓋相關網段。只新增一條 DIRECT 規則，不代表內部 DNS 就會立即正常。詳細欄位請參閱進階用法。
八、完成遷移前的驗收與回復清單
至少完成一次訂閱更新和一次客戶端重新啟動，再考慮移除舊環境。更新可確認覆寫是否獨立保留；重新啟動則能檢查服務是否自動啟動、連接埠是否儲存，以及系統代理是否恢復等問題。以下項目全數通過，才算完成遷移。
- 訂閱可正常更新，節點與策略群組完整，選取的訂閱也符合預期。
- 在規則模式下，直連與代理請求都會比對到正確的規則與連線出口。
- 本機 Merge 或腳本在訂閱更新後仍然生效，且原有規則清單沒有遺失。
- 瀏覽器、終端機與常用下載工具都使用新連接埠，舊程序也不再監聽。
- 需要 TUN 時，重新啟動後服務與虛擬網卡狀態正常；不需要時則保持關閉。
- 將暫時調試用的記錄層級恢復為日常設定。分享記錄前，請移除訂閱權杖、節點憑證與敏感網域名稱。
如果仍無法穩定運作，先關閉新客戶端的系統代理和 TUN，再結束程式；確認路由與代理設定已還原後，才啟動舊客戶端進行比對。回復期間，同一時間只保留一套流量接管機制。不要把「兩個客戶端同時執行時偶爾能上網」當成正常結果，這往往會掩蓋真正的連接埠或路由衝突。