CFW 到底發生了什麼
如果你只想先看一句結論：到了 2026 年，Clash for Windows 已經不適合再當成主力客戶端。Windows 使用者最穩的遷移方向是 Clash Verge Rev；如果你想趁機轉到更多協議，就考慮 V2RayN；Mac 使用者則通常直接改用 ClashX 更合理。
Clash for Windows 在 2023 年 11 月實質停更，最後一個公開版本是 0.20.39，發佈時間為 2023 年 11 月 3 日。之後開發者 Fndroid 刪除了 GitHub 倉庫，而且沒有給出清楚的公開說明。對一般使用者來說，這代表官方發佈頁、問題回報管道，以及後續更新路徑同時消失。
這次停更並不是單一事件。同一波圍繞 Clash 生態的壓力，也影響了早期的 Clash Verge 專案，所以社群後來才逐漸轉向 Clash Verge Rev 這類持續維護的分支。現在你仍然能在社群鏡像或歸檔分支裡找到 CFW，例如 github.com/clashdownload/Clash_for_Windows，但那解決的是「還能不能下載」，不是「還能不能長期放心使用」。
時間線重點：
- 2023-11-03：最後可見公開版本為 CFW 0.20.39。
- 2023-11：原始倉庫消失，專案停止正常維護。
- 2024-2026：使用者愈來愈依賴分叉、鏡像與替代客戶端。
Clash for Windows 現在還安全嗎
坦白說，不適合再當作長期日用客戶端。這不代表每一個舊安裝今天就一定立刻出事，但它的安全緩衝正隨著時間不斷縮小。最直接的原因是它依賴舊的 Electron 外殼，而 Electron 需要持續接收瀏覽器與執行環境的安全更新；一旦前端殼停住，風險只會累積。
第二個問題是核心組件落後。代理客戶端不是只有圖形介面，它還依賴核心引擎、網路堆疊、規則解析、憑證處理與系統代理整合。只要這些部分停止更新，你就會慢慢失去對新協議、新系統版本與新安全要求的相容性。
第三個問題是下載來源。因為官方倉庫已經不存在，很多人只能改從第三方鏡像、網盤或論壇轉載下載安裝包。這裡最現實的風險不是「功能變少」，而是供應鏈風險：你很難確認安裝包是否被修改、重新封裝或換過簽章。
繼續使用 CFW 的主要風險：
- Electron 不再接收持續安全修補，已知問題只會增加。
- 核心組件愈來愈落後，長期相容性會持續變差。
- 第三方鏡像帶來明顯的供應鏈與安裝包竄改風險。
因此實際建議很簡單：CFW 只適合短期應急，例如匯出訂閱、核對舊規則或做一兩天過渡；它已經不適合成為 2026 年的主要方案。越早遷移，之後要處理的兼容性問題越少。
遷移前一定要備份什麼
多數遷移失敗，並不是因為新客戶端不好用，而是因為舊配置沒有先備份完整。你的訂閱、策略組與手動規則往往已經累積很久，只要備份順序做對，切換其實相當順。
- 先匯出訂閱 URL： 到 CFW 的 Profiles 分頁，找到你現在正在用的訂閱連結，先複製出來另存。這一步最重要，因為它直接決定你能不能在新客戶端裡快速還原節點清單。
- 備份
profiles/list.yml： 這個檔案通常記錄訂閱清單、名稱與一些中繼資訊。即使你已經複製了訂閱地址，也建議連這個檔一起備份，方便之後回看。 - 備份本地 YAML 配置： 如果你不是純訂閱使用者，而是維護過本地配置檔，請把所有自訂 YAML 一起封存，尤其是曾經為了相容某家服務商而手動調整過的檔案。
- 記下自訂規則與代理組： 重點檢查
rule-providers、rules、proxy-groups。很多人以為只要訂閱連結還在就夠了，結果遷移後發現分流結果完全不同，問題往往就出在這裡。 - 補一份截圖或文字記錄： 建議順手截下目前模式、系統代理、TUN 狀態、連接埠與常用策略組名稱。即使新客戶端支援直接匯入，這份對照也能讓你更快確認是否遷移成功。
如果你是在幫別人搬家，最好先把這些備份打包完再開始安裝新工具。備份完整，就等於保留了一條可回退的安全路線。
替代方案 1：Clash Verge Rev（首選）
對多數前 CFW 使用者來說，Clash Verge Rev 是最自然、也最省心的替代品。它在 2026 年 2 月的穩定版本為 v2.4.6，GitHub 約有 102k stars，底層使用 mihomo v1.19.19，前端則改用 Tauri 而不是 CFW 長期依賴的 Electron。直接一點說，它更輕、更快，常駐負擔也比較小。
更關鍵的是，它沒有逼你放棄原本的 Clash 工作流。你可以直接把 CFW 裡同一條訂閱 URL 貼進去，也可以把既有 YAML 配置直接匯入。對很多人來說，這讓遷移更像是「原樣搬家」，而不是重新學一套完全不同的工具。
- 優點： UI 邏輯仍接近 Clash 生態、維護活躍、資源占用較低，並支援 Windows、macOS、Linux。
- 遷移體驗： 同樣的 Clash 訂閱通常可以直接用，本地 YAML 也能直接匯入。
- 適合誰： 主要使用 Clash YAML 訂閱、希望以最低成本離開 CFW 的人。
- 要注意的點： 它仍然建立在 Clash 配置格式上。如果你之後想全面轉向 sing-box 原生生態，未來仍可能遇到第二次遷移。
如果你只問一句「停更後先裝哪個最穩」，我們的預設答案就是 Clash Verge Rev。它的價值不在於花俏，而在於把你熟悉的工作流放回一個仍然持續更新的環境裡。
替代方案 2：V2RayN
如果你對「繼續留在 Clash 格式」這件事本身就沒有執著，那麼 V2RayN 是另一條很強的路。它目前主流版本是 v7.18.0，GitHub 約 98.6k stars，可呼叫 Xray、sing-box、mihomo 等多個核心，涵蓋 VMess、VLESS、Trojan、Shadowsocks、Hysteria2 等協議。
V2RayN 的核心價值不是它像不像 CFW，而是它給你更高的協議自由度。近兩年很多服務商逐漸把重點放在 VLESS、Reality、Hysteria2 或 sing-box 相容格式上，這時若你繼續死守舊 Clash 工作流，反而更容易被格式限制卡住。V2RayN 的優勢就是一次遷移後，後面更不容易被單一格式綁死。
它的代價也很清楚：你會離開原本熟悉的 CFW 心智模型，節點管理與核心選擇方式都比較像工具箱。若你的需求是「今天先把 CFW 平移出去」，它不如 Clash Verge Rev 順手；若你的需求是「順便升級整套協議能力」，它的上限會更高。你可以再讀我們的 V2RayN 指南 了解更多。
- 優點： 多核心、多協議，對不同服務商與不同網路環境的適應力更強。
- 不足： 與 CFW 的介面與配置邏輯差異更大，初次遷移需要重新理解一些概念。
- 最適合： 已經在用或準備轉向 VMess、VLESS、Trojan、Hysteria2 的使用者。
替代方案 3：ClashX（macOS 使用者首選）
如果你雖然曾經使用 CFW，但現在主要工作設備其實已經是 Mac，那麼最自然的接班人往往不是 Windows 圈的新分支，而是原生 macOS 的 ClashX。它一直是 Mac 上成熟度很高的 Clash 系客戶端之一，訂閱格式與 CFW 高度一致，遷移門檻很低。
ClashX 的價值在於它不是把跨平台介面硬套到 Mac 上，而是沿著 macOS 的使用方式來做：選單列、系統代理切換、原生互動與較低的資源負擔。對只是想讓工作機穩定跑起來的人來說，這種原生感通常比額外功能更多更重要。
如果你的服務商仍提供 Clash 格式，那麼直接從我們的 下載頁 開始即可。你可以繼續使用同一條訂閱 URL，也可以匯入本地 YAML；對 Mac 使用者來說，這是非常順的過渡路線。
- 優點： 原生 macOS 體驗、持續支援 Clash 訂閱格式、適合長期穩定使用。
- 不足： 主要面向 macOS，不是 Windows 使用者的主線方案。
- 最適合： 已經改用 Mac，或想徹底擺脫 CFW 跨平台外殼感的人。
替代方案 4：Clash Nyanpasu
Clash Nyanpasu 是社群裡另一條值得注意的分支，專案位址在 github.com/LibNyanpasu/clash-nyanpasu。它支援 Windows、macOS、Linux，功能演進積極，社群活躍度也不錯，因此在喜歡嘗試新功能的使用者裡相當有存在感。
不過它和 Clash Verge Rev 的定位並不完全一樣。Clash Verge Rev 更像是「穩妥遷移路線」，Nyanpasu 則比較像「發展快速的社群試驗場」。如果你願意接受更快的功能迭代、偶爾變動的互動細節，Nyanpasu 會很有趣；如果你只是想穩穩地把 CFW 換掉，優先順序仍然應該放在 Clash Verge Rev 前面。
- 優點： 社群活躍、功能推進快、跨平台覆蓋完整。
- 不足： 整體氣質更偏實驗與探索，保守遷移使用者需要一些適應時間。
- 最適合： 喜歡追新、願意跟著社群版本節奏走的人。
CFW 與主流替代工具對比
如果你不想逐段看完，下面這張表可以先幫你做第一輪篩選。真正決定遷移難度的，不是「哪個專案最紅」，而是它和你目前的配置格式、設備平台，以及日常操作習慣有多接近。
| 客戶端 | 狀態 | 平台 | 核心 | GitHub Stars | 配置格式 | 從 CFW 遷移難度 |
|---|---|---|---|---|---|---|
| Clash for Windows | 已停更 | Windows | 舊版 Clash Core | 原倉庫已刪除 | Clash YAML | 不需遷移，但不建議繼續用 |
| Clash Verge Rev | 活躍維護 | Win / Mac / Linux | mihomo v1.19.19 | 約 102k | Clash YAML | 最低，幾乎可原樣遷移 |
| V2RayN | 活躍維護 | Win / Mac / Linux | Xray / sing-box / mihomo | 約 98.6k | 多協議格式 | 中等，需要適應新工作流 |
| ClashX | 活躍維護 | macOS | Clash 相容核心 | 見專案頁 | Clash YAML | 對 Mac 使用者很低 |
| Clash Nyanpasu | 活躍維護 | Win / Mac / Linux | mihomo | 社群成長中 | Clash YAML | 中低，適合願意嘗鮮的人 |
如果你是最典型的「CFW + Clash 訂閱」使用者，這張表最直接的結論就是：先遷到 Clash Verge Rev，等你真的需要更多協議彈性時，再決定要不要進一步轉向 V2RayN。
如何一步步遷移到 Clash Verge Rev
下面這條路線是目前最常見、也最不容易翻車的做法。核心原則不是「趕快裝新客戶端」，而是先把舊配置凍結，再用最少變數完成切換。
第 1 步：先凍結目前的 CFW 配置
在你安裝任何新工具之前，先確認目前的 CFW 還能正常連線，然後記下目前模式、訂閱名稱與常用策略組。這樣做的目的，是保留一份可正常工作的對照樣本，方便你後面逐項驗證。
第 2 步：匯出訂閱並備份本地 YAML
到 Profiles 分頁複製訂閱 URL，再把 profiles/list.yml 與所有本地 YAML 一起打包。若你曾經手動改過規則，務必確認備份裡有帶到代理組名稱與規則提供器設定。
第 3 步：安裝 Clash Verge Rev 並匯入原配置
安裝完成後，先用和 CFW 一樣的訂閱 URL 直接匯入；如果你是本地配置使用者，就直接匯入 YAML。這個階段不要急著玩進階功能，先確認節點清單、策略組與模式切換都能正常顯示。
第 4 步：核對規則、DNS、TUN 與系統代理
真正容易出錯的地方通常在這裡。請把新客戶端裡的策略組順序、規則提供器、DNS 設定、TUN 開關、連接埠與系統代理狀態，和舊 CFW 逐項比對。只要這些地方一致，多數路由差異都能提前排除。
第 5 步：用常用站點實測，再移除 CFW
最後用你最常碰的幾類服務做驗證，例如本地直連站、串流平台、工作後台，以及依賴 TUN 的應用。確認新客戶端穩定跑幾天後，再移除 CFW。舊客戶端可以短暫保留作為回退參考，但不要繼續長期並行使用。
最常見的遷移翻車點：
- 只保存了訂閱，卻忘了本地 YAML 或自訂規則。
- 匯入後沒有核對代理組名稱，導致分流邏輯失效。
- 把 TUN 或系統代理狀態弄反，誤以為新客戶端有問題。
常見問題（FAQ）
Q: 還能下載 CFW 0.20.39 嗎？
A: 可以，社群分叉與鏡像仍然能找到 0.20.39，但它已經不是官方維護版本。請把它視為臨時應急方案，而不是值得長期安裝的主要工具。
Q: 我的 CFW 配置能直接用在 Clash Verge Rev 嗎？
A: 大多數情況下可以。Clash Verge Rev 仍然理解 Clash YAML 訂閱與本地配置，所以遷移通常很直接，除非你的舊設定包含少數冷門舊欄位。
Q: 自訂規則怎麼辦？
A: 把 rule-providers、rules、proxy-groups 與所有手動修改過的 YAML 一起帶走。匯入後再用實際分流結果驗證，不要只看節點有沒有出現。
Q: Clash Verge Rev 安全嗎？
A: 和已停更的 CFW 相比，答案是肯定的。它有約 102k GitHub stars、活躍維護節奏、公開社群審視，而且 Tauri 前端比老舊 Electron 外殼更輕也更可控。
Q: 如果我的服務商只提供 Clash 格式怎麼辦？
A: 那就先選 Clash Verge Rev 或 ClashX。它們都維持對 Clash 訂閱與 YAML 配置的支援，不需要你先做格式轉換。
Q: 我應該改用 V2RayN 還是 Clash Verge Rev？
A: 如果你想保留熟悉的 Clash UI 與使用邏輯，先選 Clash Verge Rev；如果你更重視多協議支援與彈性，再轉向 V2RayN。
繼續了解 CFW
想了解 CFW 的歷史和基本資訊，請查看我們的 Clash for Windows 介紹頁。如果你已經決定遷移，也可以順手閱讀 代理客戶端對比 與 基礎教程，這樣更容易判斷哪些問題來自工具差異，哪些其實只是訂閱本身造成的。
最後再提醒一次：繼續把 CFW 當主力，已經不是中立選項，而是在主動接受一個愈來愈不可控的舊環境。越早換到仍在維護的客戶端，你後面的排錯成本就越低。