Clash for Windows 停止更新後的遷移指南：替代用戶端與設定搬遷

遷移重點：更換用戶端，保留訂閱與規則

Windows 使用者可先比較 Clash Verge Rev 與 FlClash；macOS 使用者可考慮 ClashX Meta；Linux 使用者依發行版選擇安裝套件；Android 使用者可從 FlClash 開始。舊版 CFW 不必先解除安裝。先備份，再匯入新用戶端，確認規則、DNS 與代理接管正常，最後停用舊程式的開機自動啟動。

Clash for Windows 通常簡稱 CFW，原專案已於 2023 年停止維護。常見的末期版本為 0.20.39。它是圖形介面用戶端，不代表所有 Clash 核心，也不等同於訂閱服務。更換介面不會自動更換服務供應商；使用相同訂閱時，可用的代理仍取決於訂閱提供者。

遷移時先釐清三個層次

用戶端：管理訂閱、系統代理、服務權限與設定覆寫；各用戶端的選單和檔案結構都不同。
核心：解析 YAML、執行代理協定、規則與 DNS。Clash Meta 後續以 mihomo 的名稱發展；新用戶端是否支援特定欄位，須視實際使用的核心而定。
訂閱：提供節點或完整設定。節點清單與完整的 Clash 設定並非同一種輸入，匯入前要先確認格式。

替代用戶端：依平台與設定需求選擇

優先選擇仍有更新發布紀錄、清楚標示核心版本，並支援匯出設定與查看記錄的專案。維護狀態可能變動，以下僅列出可考慮的遷移選項，不代表專案承諾永久維護。安裝前請至專案發布頁確認近期版本、系統需求與已知問題；也可從用戶端下載頁前往。

平台	候選用戶端	遷移重點
Windows	Clash Verge Rev、FlClash	確認設定覆寫方式、服務模式、系統代理與 TUN 權限；不要整個複製 CFW 使用者目錄。
macOS	Clash Verge Rev、FlClash、ClashX Meta	確認安裝檔適用於 Apple Silicon 或 Intel；重新授權網路接管所需的元件。
Linux	Clash Verge Rev、FlClash	確認套件格式（如 DEB、RPM）及發行版需求；分別測試桌面代理設定與 TUN 路由。
Android	FlClash	依裝置架構選擇安裝檔，確認 VPN 授權、應用程式分流與背景執行限制。
iOS	支援相應訂閱格式的 iOS 用戶端	先確認設定格式與網路延伸功能；無法安裝桌面版 CFW，也不能假設 CFW 腳本可直接執行。

需要覆寫設定時，先確認設定機制

如果只需要匯入訂閱和手動選擇代理，遷移相對簡單。若有自訂規則、DNS 或腳本，應先確認新用戶端能否將本機修改持續套用至訂閱設定。Clash Verge Rev 的合併設定、腳本處理方式與 CFW 的 Parsers 機制並不相同；FlClash 的設定處理方式也不能從 CFW 檔案結構推斷。功能名稱請以安裝版本的介面為準。

不要把「內建 mihomo」理解成「完全相容 CFW 的所有功能」。核心能辨識哪些 YAML 欄位，與介面如何儲存、更新及產生設定，是兩回事。更多選擇差異請參閱用戶端比較。

備份清單：訂閱網址、最終設定與本機修改

先在舊版 CFW 關閉訂閱自動更新，避免整理期間設定變動。開啟 Profiles（設定檔），記下目前啟用的設定、訂閱來源與更新時間；開啟 Proxies（代理），記下各手動選擇群組目前使用的選項；再到 General（一般） 與 Settings（設定） 記下連接埠、系統代理、TUN 與設定處理選項。

保存訂閱網址：保留完整 URL，包含查詢參數。訂閱 URL 可能含有存取權杖，請當作密碼妥善管理，不要貼到公開討論區。
保存原始 YAML：為目前使用的設定建立副本，並註明它是訂閱原始檔還是處理後的檔案。介面中的編輯功能不一定會顯示實際執行的最終內容。
保存覆寫來源：分別複製 Parsers 設定、外部腳本、自訂規則、規則提供者網址與本機檔案。
記錄執行參數：例如實際使用的混合連接埠 7890、監聽位址、代理模式、DNS 模式與 TUN 開關。7890 是常見連接埠，並非每台裝置的固定值。
記錄特殊用途：瀏覽器擴充功能、終端機環境變數、區域網路裝置或開發工具，是否明確連線至舊代理連接埠。

使用者目錄僅供備份，不要直接覆蓋新程式

Windows 上 CFW 常見的使用者設定路徑為 %USERPROFILE%\.config\clash；可攜模式或自訂目錄可能不同，請以舊用戶端顯示的實際路徑為準。可以複製整個目錄留作回復備份，但不要將其中的資料庫、快取與用戶端設定直接覆蓋到新用戶端目錄。

遷移訂閱：先確認原始設定，再套用覆寫

首次匯入時，先關閉新用戶端的系統代理與 TUN，暫時不要接管網路。使用新用戶端的訂閱或設定匯入功能加入原始網址；如果訂閱暫時無法存取，可匯入備份 YAML 進行離線測試，但之後不會自動取得節點更新。

檢查匯入記錄，確認內容是 YAML 設定，而不是登入頁面、錯誤頁面或僅含代理連結的文字。
確認代理數量、策略群組名稱與規則數量，並檢查原本的手動選擇群組是否仍存在。
啟用這份設定，先執行核心設定檢查，再查看啟動記錄是否出現欄位不支援、目標不存在或檔案讀取失敗等訊息。
檢查實際產生的設定。用戶端的全域設定可能會覆蓋訂閱中的連接埠、DNS 或 TUN 欄位。
原始設定確認可啟動後，再逐項加入覆寫，每次只遷移一類修改。

訂閱匯入成功，不代表行為完全相同

舊設定可能仰賴 CFW 專用的前處理，而服務供應商提供的原始內容不含這些修改。另一種情況是，訂閱包含新版核心支援的協定，但舊用戶端無法完整辨識；遷移至 mihomo 後，代理清單反而可能出現差異。請比較實際產生的設定內容，不要只憑「匯入成功」就判定遷移完成。

保留服務供應商提供的相容訂閱入口。需要轉換格式時，優先使用服務供應商或用戶端明確支援的方法；將含有權杖的網址交給不熟悉的線上轉換網站，會增加訂閱資訊外洩風險。

自訂規則與腳本：遷移功能，不照搬介面

CFW 的 Parsers 可透過比對訂閱 URL、合併欄位或使用 JavaScript 改寫設定。新用戶端的腳本入口參數、回傳值與執行環境可能不同。即使同樣使用 JavaScript，也不代表舊檔案能直接執行。先將腳本拆解成具體需求：新增規則、調整策略群組、更換 DNS，還是修改代理名稱。

規則順序比複製數量更重要

規則通常由上而下比對，符合後便使用對應目標。明確的網域規則應排在較寬泛的規則之前，最後再放預設規則 MATCH。以下僅為可合併至完整設定的規則片段，用來讓本機名稱與私有 IPv4 位址直連；不含代理節點，也不是完整訂閱。

rules:
  - DOMAIN-SUFFIX,lan,DIRECT
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve

遷移時應將這些項目插入現有規則的適當位置，不要用片段取代整個 rules 清單。陣列會被附加、置前或整體覆蓋，取決於新用戶端的覆寫機制；請檢查產生後的設定。

策略群組參照：原規則引用的群組名稱必須存在於完整設定的 proxy-groups 中，名稱與大小寫都要完全一致。
規則提供者：遷移 rule-providers 時，一併檢查 behavior、格式、URL 與本機路徑，不要只複製 RULE-SET 項目。
本機檔案：舊目錄中的絕對路徑通常會在新用戶端失效；相對路徑也要確認是以哪個設定目錄為基準。
重複規則：訂閱已有的私有網路直連規則不必重複新增；重點是比對順序與目標正確。

依功能分批重寫腳本

先遷移可用純 YAML 表達的修改，再處理必須使用腳本的部分。每次執行後比對策略群組、規則與 DNS，留意腳本是否改動節點名稱，導致策略群組仍參照舊名稱。不要假設舊腳本使用的檔案存取、網路請求或第三方相依項目在新環境也一定可用。

更新訂閱後再檢查一次：如果自訂規則消失，表示修改只套用在暫時產生的檔案中，沒有納入持續生效的覆寫層。相關欄位可參閱YAML 設定說明。

連接埠、DNS 與 TUN：切換網路接管時避免雙重執行

設定確認能啟動後，再切換網路接管。先關閉 CFW 的系統代理與 TUN，再正常結束 CFW；確認背景服務或殘留程序沒有繼續監聽連接埠，之後才開啟新用戶端的系統代理。兩個程式同時爭用系統代理或路由，常會造成連線時好時壞。

混合連接埠變更，應用程式代理設定也要同步調整

假設舊用戶端監聽 127.0.0.1:7890，新用戶端實際監聽 127.0.0.1:7897，瀏覽器擴充功能、終端機與開發工具中的手動代理設定也要同步更新。連接埠可以維持原值，但前提是舊程序已釋放該連接埠。以下為監聽參數範例，請以新用戶端的最終執行設定為準。

mixed-port: 7897
allow-lan: false
bind-address: 127.0.0.1
mode: rule
log-level: info

mixed-port 同時提供 HTTP 與 SOCKS 代理入口，不等於外部控制 API 連接埠。不要為了遷移而將外部控制介面開放至所有網路介面；原本有區域網路分享需求的裝置，應另行確認監聽範圍、防火牆與存取限制。

DNS 設定不宜連同舊快取一起搬遷

記下舊設定使用 fake-ip 還是 redir-host，以及上游解析器、網域策略與過濾清單，再檢查新用戶端是否覆蓋這些設定。遷移後若出現「節點可連線、網站無法開啟」，應查看 DNS 請求與規則命中狀況，不要立刻反覆更換節點。清除快取或切換模式只能作為有根據的排查步驟，不能取代設定檢查。

最後再啟用 TUN

先用系統代理測試瀏覽器，再啟用 TUN，確認不使用系統代理的程式也能正常連線。Windows 可能需要用戶端服務與系統管理員授權；macOS 需要授權相關元件；Linux 需要足夠的網路管理權限；Android 則須透過系統 VPN 授權。若已使用企業 VPN、其他代理軟體或虛擬機網路，還要額外檢查路由與 DNS 衝突。

驗收與回復：更新一次訂閱後再解除安裝 CFW

遷移完成的標準，是能重現原本的使用情境，而不是延遲測試跑出數字。建議依照下列檢查清單逐項記錄結果。不要編造測速數據當作成功證明；同一節點在不同時間的延遲，也無法證明規則與 DNS 設定正確。

網頁連線：分別造訪預期直連與預期使用代理的網站，並在記錄或連線清單中確認命中的規則與策略群組。
本機資源：確認路由器管理頁面、區域網路服務與公司內部網路仍可依預期存取。
應用程式連線：檢查瀏覽器以外的開發工具或其他程式，確認它們使用的是系統代理、手動代理還是 TUN。
訂閱更新：手動更新一次，確認自訂規則、策略群組調整與 DNS 覆寫仍然存在。
重新啟動：重新啟動新用戶端，檢查目前設定、選用代理、服務權限與開機啟動狀態。
權限收尾：停用舊版 CFW 的開機自動啟動並關閉舊服務，保留離線備份，確認新程式結束後系統代理能正常還原。

發生異常時，分層回復

新程式無法啟動時，先移除覆寫並測試原始訂閱；能啟動但無法上網時，先關閉 TUN，只測試系統代理；瀏覽器正常但某個應用程式失敗時，再檢查該應用程式的代理位址與路由。請依操作時間查看記錄，先找出第一個設定或連線錯誤，避免被後續重複逾時訊息誤導。

若確實需要短暫改回舊用戶端，先關閉新用戶端的網路接管並結束程式，再啟動備份的舊環境。不要同時啟用兩套系統代理或 TUN。備份可能含有訂閱權杖、控制介面金鑰與代理憑證，請存放在受保護的位置；等新設定穩定，且更新與重新啟動都通過驗證後，再處理舊版安裝。

遷移最重要的四件事：保留訂閱來源、確保覆寫來源可追溯、讓連接埠與網路接管設定一致，以及確認更新後規則仍有效。依此順序操作，更換用戶端就不必演變成整套設定重建。