選型比較 預計閱讀 12 分鐘

Clash for Windows 停止更新後如何遷移：Verge Rev、FlClash 等替代用戶端與設定搬移步驟

整理舊用戶端停止更新後的替代選項，比較介面、核心與平台支援，並說明如何完整遷移訂閱與本機設定。

停止更新後的遷移原則：分開處理用戶端、核心與設定

Clash for Windows 通常簡稱 CFW，已於 2023 年 11 月停止維護。舊版仍可能正常啟動，但原專案不再修復後續作業系統變更、相依元件問題或通訊協定相容性。遷移的重點不是讓新用戶端重現舊介面，而是保留訂閱來源、節點、代理群組與分流設定，再重新設定系統代理與網路接管功能。

請先區分三個層次：CFW 是圖形介面用戶端；Clash、Clash Premium、Clash Meta 與 mihomo 是核心相關專案；YAML 則是承載代理、規則與執行參數的設定格式。Clash Meta 後續以 mihomo 的名稱持續發展。安裝 mihomo 核心的用戶端，不代表 CFW 的所有介面設定都會自動轉換。

遷移前先記下這六項資訊

  • 目前啟用的 Profile 名稱，以及來源是訂閱網址還是本機 YAML。
  • HTTP、SOCKS 或混合連接埠的實際數值，例如 7890；請勿只憑預設值判斷。
  • 執行模式是 Rule、Global 還是 Direct，以及代理群組目前選用的節點。
  • 是否啟用 System Proxy、TUN、開機啟動與背景服務。
  • 是否使用 Parsers、自訂規則、DNS 修改或其他設定處理邏輯。
  • 瀏覽器、終端機或開發工具是否另行指定代理位址。

替代用戶端比較：Verge Rev、FlClash 與 Nyanpasu

選擇時先看作業系統與設定功能，再看介面。以下列出各專案通常提供的用戶端平台；支援的最低系統版本、CPU 架構與核心版本，請以下載頁面的發行說明為準。請勿將「支援 Windows」解讀為所有舊版 Windows 都能執行。

用戶端 主要平台 核心關係 遷移注意事項
Clash Verge Rev Windows、macOS、Linux 以 mihomo 為核心 適合管理桌面訂閱；需重新設定覆寫、服務與系統代理
FlClash Windows、macOS、Linux、Android 以 mihomo 為核心 適合跨桌面平台與 Android 使用；各平台的網路接管方式不同
Clash Nyanpasu Windows、macOS、Linux 提供 Clash 系列核心管理功能，實際選項依版本而異 請確認實際啟用的核心，勿只依用戶端名稱判斷語法支援情況

依使用情境選擇

  • 主要管理桌面設定：可先評估 Clash Verge Rev，確認訂閱更新、覆寫與日誌入口是否符合現有工作流程。
  • 電腦與 Android 都會使用：可評估 FlClash，但請勿將 Windows 的服務模式設定步驟直接套用到 Android；Android 通常透過系統 VPN 授權接管流量。
  • 需要檢查或切換核心：可評估 Clash Nyanpasu，匯入前先確認核心選擇與版本，再檢查訂閱欄位是否可用。

CFW 雖然名稱中有 Windows，過去的版本也支援其他桌面平台。遷移不必侷限於名稱相似的產品。設定能否載入，真正取決於目標核心、訂閱輸出格式及用戶端的覆寫實作，而不是介面看起來是否像 CFW。

備份訂閱與本機 YAML：保留來源，也留存可用副本

訂閱網址與目前的設定快照用途不同：網址可供日後更新；YAML 快照則能保留目前可用的節點與自訂內容。只保存網址，無法找回曾手動修改但已遭覆蓋的規則；只保存 YAML，則可能失去自動更新功能。

  1. 在 CFW 的 Profiles 頁面確認目前使用的設定。遠端設定請記錄原始訂閱網址；本機設定則請保存原始檔案。請勿只憑顯示名稱推測來源。
  2. 透過用戶端提供的設定目錄入口，找出實際資料目錄。若曾使用可攜式版本，目錄位置可能隨安裝位置改變，請勿只查看使用者主目錄。
  3. 將設定目錄複製到獨立的備份資料夾，並另外保存訂閱網址、設定名稱及彼此的對應關係。
  4. 保存 Parsers 內容、手動撰寫的規則與本機資源檔案。若 YAML 使用相對路徑引用檔案，請一併備份相關檔案。
  5. 記下備份當下的連接埠、模式與代理群組選擇。可以擷取相關設定頁面，但截圖不能取代 YAML 與訂閱網址。

檢查 provider 引用與相對路徑

設定中的 proxy-providers 與 rule-providers 可能依賴遠端網址，也可能依賴本機的 path。複製主要 YAML 不代表所有相依檔案也都已複製。新用戶端的資料目錄變更後，相同的相對路徑可能指向不同位置，請依目標用戶端的工作目錄重新確認。

匯入與切換步驟：先使用規則模式，再啟用系統代理

第一次遷移建議只接管一般應用程式流量，暫時關閉 TUN。如此一來，便能分開確認「設定是否正確」與「系統路由是否正常」。整個過程只讓一個用戶端管理系統代理，避免兩個背景程式反覆修改同一組設定。

  1. 停止舊用戶端接管流量。在 CFW 的 General → System Proxy 關閉系統代理；若已啟用 TUN，也請先關閉。接著退出 CFW，並確認它不會因開機啟動而再次執行。
  2. 安裝目標用戶端。從用戶端下載頁面選擇作業系統與架構。首次啟動時先確認核心可正常使用，再設定服務模式等附加功能。
  3. 匯入一份設定。遠端設定請使用原始訂閱網址，本機設定則使用已保存的 YAML。不同用戶端可能將匯入入口標示為「設定」或「訂閱」，請以安裝版本的介面為準。
  4. 啟用剛匯入的設定。設定出現在清單中，不代表核心目前正在使用它。請檢查目前設定的標記與載入日誌，確認沒有 YAML 解析錯誤或不支援的欄位。
  5. 選擇 Rule 模式。開啟相應的代理群組，先手動選擇一個可用節點。代理群組名稱相同，不代表先前選擇的狀態會保留下來。
  6. 確認監聽連接埠。確認新用戶端實際使用的連接埠，再啟用系統代理。若瀏覽器裝有代理擴充功能，請先停用擴充功能接管，或將其設定為跟隨系統。

連接埠遷移範例：從 7890 改為 17890

如果舊用戶端使用 127.0.0.1:7890，新用戶端使用 127.0.0.1:17890，所有寫死舊位址的終端機變數與工具設定都需要更新。以下是 mihomo 的局部參數範例，並非包含節點與規則的完整訂閱。請透過用戶端支援的設定或覆寫機制套用。

mixed-port: 17890
allow-lan: false
mode: rule
log-level: info
tun:
  enable: false

mixed-port 可同時接受 HTTP 與 SOCKS 代理連線，與核心控制介面的連接埠不同；控制介面用於管理，不應填入瀏覽器的 HTTP 代理欄位。若現有應用程式明確使用獨立的 SOCKS 監聽連接埠，也請依新設定重新確認。

規則、覆寫與 TUN：無法直接沿用的設定

必須重新實作 CFW Parsers

Parsers 是 CFW 的設定處理機制，並非 mihomo YAML 通用的頂層欄位。將 Parsers 原文貼到訂閱檔案中，並不會自動產生相同效果。請先列出它實際執行的操作，例如新增區域網路直連規則、修改 DNS 或新增代理群組，再使用目標用戶端支援的合併設定或指令碼覆寫，逐項重新實作。

先保存原始訂閱，再保存自訂修改。直接編輯下載的遠端 YAML，下一次更新時可能會覆蓋修改。驗證方式很明確：記下一條自訂規則，執行一次訂閱更新，再查看執行中的設定是否仍保留該規則，且位置是否正確。

規則順序與群組名稱都要檢查

  • 規則通常依序比對，第一條符合的規則會決定後續策略。需要優先處理的例外規則，應放在預設規則之前。
  • MATCH 是常見的預設規則，請確認它實際指向的策略群組，不能只看檔案中是否有節點。
  • 規則引用的代理群組名稱必須與定義完全一致，包括大小寫、空格與符號。重新命名代理群組後，也要一併修改引用。
  • 若訂閱提供 Clash 與 Clash Meta 兩種輸出格式，使用 mihomo 時請優先確認服務提供者建議的相容格式；不要只將其他格式的內容改成 .yaml 副檔名後匯入。

最後再單獨啟用 TUN 與 DNS

TUN 會建立虛擬網路介面，並可能調整路由與 DNS 處理方式。它並不是「更強的全域模式」：即使由 TUN 接管流量，規則模式仍會生效。請先確認一般系統代理正常運作，再依目標用戶端的要求啟用服務或授予權限，最後才開啟 TUN。

啟用後若內網網域、公司 VPN 或本機裝置連線異常，請檢查路由排除設定、DNS 策略與其他 VPN 是否占用資源。fake-ip 是 DNS 處理模式，不能只搬移單一開關而忽略相關過濾與規則。請勿同時啟用兩個用戶端的 TUN 來比較速度，否則更難找出問題來源。

遷移驗收：分別測試設定載入、代理連線與更新

看到節點延遲數值，只代表在特定條件下收到某個測試目標的回應，並不足以證明瀏覽器、終端機與規則都正常。以下以 Windows PowerShell 為例，假設新用戶端的混合連接埠為 17890；若使用其他連接埠，請同步修改命令。

1. 確認本機連接埠與明確指定的代理

Get-NetTCPConnection -State Listen -LocalPort 17890
curl.exe --proxy http://127.0.0.1:17890 --connect-timeout 10 --max-time 20 -I https://example.com/

第一個命令會檢查是否有程序正在監聽該連接埠，並可依輸出中的 OwningProcess 進一步確認所屬程式。第二個命令會明確指定 HTTP 代理，連線逾時為 10 秒，總時限為 20 秒；使用 curl.exe 是為了避免部分 PowerShell 環境中的命令別名差異。

收到 HTTP 回應表示這次請求已完成，但不代表一定經過代理節點：Rule 模式也可能命中 DIRECT。請同時查看用戶端的連線記錄，確認符合的規則、策略群組與最終出口符合預期。若明確指定代理後可正常使用，但瀏覽器不行，請優先檢查系統代理、瀏覽器擴充功能與代理例外清單。

2. 檢查終端機變數與系統設定

Get-ChildItem Env:*proxy*
netsh winhttp show proxy

第一個命令可找出仍指向舊連接埠的代理環境變數。第二個命令只會顯示 WinHTTP 代理設定，無法代表 Windows 使用者層級系統代理的完整狀態。在 Windows 11 中也請前往「設定 → 網路和網際網路 → Proxy」，確認目前手動代理的位址與連接埠。終端機工具是否讀取系統代理取決於工具本身，不能只因用戶端開關已開啟就認定有效。

3. 完成更新與重新啟動驗收

  • 手動更新一次訂閱，確認節點清單仍能載入，且自訂規則沒有消失。
  • 分別造訪一個應直連的目標與一個應走代理的目標，並在連線記錄中確認使用的策略。
  • 關閉並重新啟動新用戶端，確認目前設定、模式與代理群組選擇都符合預期。
  • 若需要 TUN，請單獨啟用後，再測試本機網路、DNS 與日常應用程式。
  • 重新啟動系統，確認只有新用戶端會自動啟動，舊用戶端不再修改連接埠或系統代理。

常見遷移問題與復原方式

訂閱匯入成功但節點清單空白，該先檢查什麼？

先查看訂閱請求與設定載入日誌。網址可能回傳登入頁面、錯誤訊息或不相容格式，而非有效的 YAML。也可能使用了 proxy-provider，但提供者下載失敗，或未透過代理群組的 use 引用。請先確認原始訂閱仍然有效，再檢查目標核心的支援情況；不要反覆切換系統代理來掩蓋設定問題。

新用戶端提示連接埠已被占用，可以直接更改嗎？

可以，但請先確認占用連接埠的程序。如果是舊版 CFW 或殘留的背景服務，應先正常退出或停止相關服務。若確實需要改用 17890 等其他連接埠，瀏覽器手動代理、終端機變數與開發工具設定都必須一併更新。請勿結束用途不明的系統程序。

遷移失敗後，如何還原舊設定？

先關閉新用戶端的系統代理與 TUN，再退出新用戶端，接著啟用舊用戶端與備份設定。還原只是短期復原方式，舊專案停止維護的現況並未改變。若暫時不再使用代理，也請一併清除仍指向已關閉連接埠的手動代理設定與環境變數，避免應用程式持續連線失敗。

遷移完成的標準是：原訂閱仍可更新、本機修改得以保留、規則命中原因清楚，且系統重新啟動後仍能依預期接管流量。確認這些項目後，再移除舊用戶端的自動啟動項目與服務，並保留一份安全備份。需要確認設定欄位時，可繼續參閱通訊協定參考；若系統代理異常，可依問題現象前往說明中心排查。

下載用戶端