用戶端選型 預計閱讀 12 分鐘

Clash for Windows 停止更新後：替代用戶端怎麼選、舊設定如何移轉

整理停止更新的用戶端現況，比較仍在維護的替代方案，並提供將訂閱、規則與覆寫設定移轉至新用戶端的步驟。

先說結論：移轉設定，不要整個複製用戶端資料夾

Clash for Windows（以下簡稱 CFW）已於 2023 年停止維護，常見的最後公開版本為 0.20.39。現有安裝可能仍能啟動，但能啟動不代表核心、相依元件與系統相容性仍持續更新。若遇到無法辨識新協定、系統升級後服務異常等問題，建議優先移轉，而不是一再重裝同一個舊安裝檔。

Windows 使用者可先比較 Clash Verge Rev 與 Clash Nyanpasu；若希望在桌面與 Android 上採用相近的操作方式，也可以將 FlClash 納入考量。選擇時應分別確認圖形用戶端與隨附核心的發布狀態，不能只憑專案名稱中有 Clash 就判定相容。安裝檔來源、目前支援的平台與架構，可至用戶端下載頁確認。

如何選擇替代用戶端：檢視核心、設定入口與系統整合

圖形用戶端主要負責管理訂閱、系統匣選單、系統代理與服務安裝；核心則負責代理協定、規則比對、DNS 與連線轉送。Clash Meta 後續以 mihomo 之名持續發展，但這不代表每個名稱中帶有 Clash 的用戶端都使用相同核心，更不代表舊介面的腳本能直接交由新核心執行。

候選用戶端 適合優先考量的需求 移轉時應優先確認
Clash Verge Rev Windows、macOS、Linux 桌面的訂閱與系統整合 mihomo 設定相容性、服務模式、設定合併與腳本入口
Clash Nyanpasu 希望採用不同的桌面操作介面與設定管理方式 實際使用的核心、設定處理順序、系統代理與 TUN 設定
FlClash 需要同時考量桌面與 Android 的使用流程 各平台安裝檔、背景執行權限、設定覆寫能力
原有 CFW 離線檢視舊設定，作為短期移轉參考 已停止維護，不適合作為長期更新方案

下載前確認三項條件

不建議只以「支援更多選項」作為選擇標準。對於現有訂閱已能正常使用的使用者而言，能看清最終設定、保留本機規則並穩定還原系統網路，通常比介面上多一個實驗性選項更重要。

移轉前備份：分別保存訂閱、規則與介面設定

先在 CFW 的「Profiles」記下目前啟用的設定檔，在「Proxies」記下模式與各代理群組的選擇，再到「Settings」找到並開啟實際的設定資料夾。一般安裝常見的資料夾為 %USERPROFILE%\.config\clash，但免安裝版本或自訂路徑可能不同，請以用戶端開啟的資料夾為準。

  1. 保存訂閱來源：記下訂閱網址、更新間隔與服務提供者的說明。訂閱連結通常包含存取憑證，請存放在受保護的本機記錄中，不要貼到公開論壇或截圖分享。
  2. 備份設定檔：退出 CFW 後複製設定資料夾；另外保存目前設定的 YAML 文字，方便逐項比對。匯出的節點清單不能取代訂閱網址，後續自動更新仍需要原始來源。
  3. 另行保存自訂內容：包括 Parsers、Mixin、自訂規則、規則集網址、本機檔案與 DNS 覆寫。記下哪些內容來自訂閱，哪些是之後手動新增的。
  4. 記錄系統整合設定：保存 HTTP、SOCKS 或 mixed 連接埠，以及系統代理、開機啟動、服務模式和 TUN 的啟用狀態。不要把快取、舊服務程式與舊核心一併覆蓋到新安裝資料夾。

備份資料夾可能包含節點密碼、訂閱權杖與外部控制介面金鑰。移轉完成後仍應妥善保管；若曾不慎公開這些內容，應至對應服務端更換憑證，而不只是刪除本機截圖。

移轉訂閱：先確認原始設定能正常運作

第一輪只匯入訂閱，不啟用舊腳本

退出 CFW，並關閉其系統代理、TUN 與開機啟動。開啟新用戶端，在訂閱管理區使用原訂閱網址匯入；例如 Clash Verge Rev 通常會在「訂閱」頁提供匯入入口，按鈕名稱與位置請以安裝版本為準。匯入成功後手動更新一次，並確認已選取並啟用這份設定，而不只是看見它出現在清單中。

接著檢查代理群組是否完整，尤其是自動選擇、故障轉移與自行命名的分流群組。舊用戶端中保存的節點選擇不一定會移轉，群組名稱相同也不代表已選到相同節點。先手動選擇一個確定可用的節點，再開啟規則模式測試基本連線。

匯入失敗時，依錯誤類型處理

移轉本機 YAML 時，請特別檢查 rule-providers 與 proxy-providers 中的相對路徑。將舊檔案複製到新資料夾後，參照路徑未必仍有效；外部規則集的格式也必須符合宣告的 type、behavior。

移轉規則與覆寫：依最終產生的 YAML 逐項處理

CFW 的 Parsers 是用戶端端的設定處理機制，不能直接當成 mihomo 核心欄位使用。舊腳本的函式入口、注入物件與執行時機，可能都和新用戶端不同。請將舊邏輯拆解成「新增規則」、「修改 DNS」、「調整代理群組」等具體需求，再使用目標用戶端支援的設定合併或腳本機制重新編寫。

先移轉明確的規則，再還原複雜處理

以下僅示範兩條區域網路直連規則的寫法，不是完整訂閱，也不應直接取代原有的 rules 清單。若確實需要這些規則，請透過用戶端提供的規則前置功能或設定編輯入口，將規則加入原有規則鏈，並保留最後的兜底規則：

rules:
  - DOMAIN-SUFFIX,home.arpa,DIRECT
  - IP-CIDR,192.168.50.0/24,DIRECT,no-resolve

192.168.50.0/24 只是範例網段，請依實際區域網路位址調整。規則通常由上而下比對；本機例外應放在可能優先命中的廣泛規則之前，最後的 MATCH 則負責兜底。若規則目標是自訂代理群組，該群組必須確實存在；不要照抄舊名稱後就認定設定有效。

DNS 與 Fake-IP 請分開移轉

不要一次複製整段舊 DNS 設定。先使用新用戶端的預設方案建立可運作的基礎，再視需要移轉自訂 DNS 伺服器、網域策略與 Fake-IP 排除項目。Fake-IP 使用保留位址建立網域對應，並非實際代理節點位址；啟用後若出現異常，應參考用戶端 DNS 記錄與應用程式行為進行排查，不要看到虛擬位址就認定設定錯誤。

若應用程式依賴區域網路探索、私有網域或固定 DNS，請分別確認解析結果與連線路徑。修改 DNS 模式後，可以關閉相關應用程式再重新測試；Windows 也可執行 ipconfig /flushdns 清除系統 DNS 快取，但這不會清除所有瀏覽器與應用程式自己的快取。

連接埠、系統代理與 TUN：分三步驗證

第一步：確認本機代理正在監聽

CFW 常見的 HTTP 連接埠是 7890、SOCKS 連接埠是 7891，外部控制介面常見連接埠為 9090；實際值仍以舊設定為準。新用戶端可能使用其他連接埠，例如 7897。控制介面不是瀏覽器代理連接埠，不能填入應用程式的 HTTP 代理設定。

假設新用戶端明確顯示 mixed 連接埠為 7897，可在 PowerShell 執行以下指令。第一個指令確認監聽中的程序，第二個透過明確指定的代理存取測試網址；測試前不必先開啟系統代理。

Get-NetTCPConnection -State Listen -LocalPort 7897
curl.exe -I --proxy http://127.0.0.1:7897 https://example.com/

收到 HTTP 回應表示該次要求已取得回應，但不代表所有分流規則都正確。若顯示連線遭拒，先檢查核心是否已啟動以及連接埠是否一致；若顯示連接埠已被占用，請確認舊用戶端或其他代理程式是否仍在背景執行，不要貿然終止不明的系統程序。

第二步：啟用系統代理

本機代理測試通過後，開啟新用戶端的系統代理，再到 Windows「設定」→「網路和網際網路」→「Proxy」檢查位址與連接埠。瀏覽器可以連線但某個應用程式不行，可能是該應用程式不遵循系統代理、使用獨立的代理設定，或受到其他網路限制；請先檢查應用程式本身的設定。

第三步：視需求啟用 TUN

TUN 透過虛擬網路介面接管流量，通常會涉及服務權限、路由與 DNS。系統代理正常運作後，再依用戶端提示安裝或啟用服務模式，最後才開啟 TUN。每一步都測試一次，避免服務、DNS 與路由同時變動，導致難以定位原因。

若啟用 TUN 後企業 VPN、區域網路存取或虛擬機器網路出現異常，請先關閉 TUN，確認是否恢復正常，再檢查路由衝突與排除設定。不要讓兩個用戶端同時執行 TUN，也不要為了啟用 TUN 而長期以系統管理員身分執行所有桌面程式。

移轉驗收與回復檢查清單

成功開啟一個網頁，只能證明其中一條連線路徑可用。完成以下檢查後再移除舊用戶端，才能區分問題來自訂閱、規則或系統接管。

需要回復時，先關閉新用戶端的系統代理與 TUN，再退出其核心；接著還原備份中的舊設定，並確認只有一個用戶端接管網路。回復是為了對照故障，不代表停止維護的用戶端重新獲得維護。確認新環境穩定後，可解除安裝舊程式，並依舊用戶端提供的方式移除不再使用的服務，只保留必要的離線備份即可。

整個移轉過程最重要的是每一步都能驗證：先保留訂閱原貌，再移轉個人化規則；先確認本機連接埠，再啟用系統接管。若想進一步了解規則、DNS 與 TUN 的關係，請參閱使用手冊；常見安裝與連線問題則可在常見問題依現象排查。

下載 Clash