停更意味著什麼,不意味著什麼
Clash for Windows(社群常簡稱 CFW)在開發者宣布封存後,不再有新版本發布、不再修復漏洞、不再適配新核心特性。這是一個明確的事實,但它常被過度解讀成「現在立刻不能用了」或「設定檔全部作廢」,這兩點都不準確。
先說清楚風險邊界。停更帶來的實際影響主要有三條:一是客戶端內建的核心版本被鎖定在封存時的那個版本,後續核心新增的協定類型(例如更新的傳輸層混淆方式)或規則語法擴充,CFW 都不會再支援;二是客戶端本身若存在未修復的介面或連線穩定性問題,不會再有修補程式;三是作業系統升級後(尤其是 Windows 的網路堆疊調整),舊客戶端與系統元件的相容性問題只能靠使用者自行繞過,沒有官方回應管道。
不需要恐慌的部分同樣值得說清楚。首先,已經寫好的訂閱連結、規則集、DNS 設定這些內容都保存在你自己的設定檔裡,不依賴客戶端本身,換客戶端不等於重新設定一切。其次,mihomo(Clash Meta)核心仍在活躍維護,只要新客戶端內建的是較新的 mihomo 核心,你此前遇到的協定不支援、規則不生效等問題反而可能被順帶解決。第三,設定檔語法(YAML 結構、代理群組寫法、規則比對邏輯)在主流客戶端之間高度相容,遷移的核心工作量不是重寫設定,而是把現有檔案正確匯入到新客戶端並核對少數欄位差異。
如果你的設定檔裡手寫了大量自訂規則或覆寫腳本,且這些內容依賴 CFW 特有的欄位寫法,遷移前建議先備份原始檔案再逐項核對,不要直接刪除舊客戶端。
遷移前的準備:備份與清點
動手換客戶端之前,先把現有資產完整備份,這一步能避免絕大多數「遷移完發現規則丟了」的問題。
-
定位設定檔目錄
CFW 的設定檔一般存放在使用者目錄下的
.config\clash或客戶端安裝目錄內的profiles資料夾,檔名通常是訂閱產生的一串字元加.yaml或.yml副檔名。找到全部訂閱對應的設定檔並複製到一個新建的暫存資料夾。 -
記錄訂閱原始連結
設定檔是訂閱拉取後產生的結果,更可靠的遷移方式是重新用訂閱連結產生設定,而不是直接搬運舊檔案。開啟 CFW 的訂閱管理介面,把每一條訂閱的原始 URL 完整複製出來,單獨存成一個文字檔。
-
檢查是否使用了覆寫(Override)腳本
如果你在 CFW 裡為某條訂閱新增過覆寫規則或 JavaScript 覆寫腳本(用於強制修改連接埠、追加規則、封鎖廣告分組等),這部分內容不會自動跟隨訂閱連結遷移,需要單獨複製腳本正文,新客戶端裡重新貼上設定。
-
確認系統代理與 TUN 設定
記下目前使用的是系統代理模式還是 TUN 模式,以及混合連接埠(mixed-port)、允許區域網路連線(allow-lan)等欄位的數值,這些是遷移後最容易被忽略、但直接影響能否正常上網的開關項目。
設定檔遷移的具體步驟
備份清點完成後,正式的遷移操作分為三種情況,按你的實際使用習慣選擇即可。
方式一:重新匯入訂閱連結(推薦)
在新客戶端的訂閱管理介面貼上原始訂閱 URL,讓新客戶端自己拉取並產生設定檔。這種方式的好處是設定內容始終由訂閱方維護,如果訂閱方後續更新了節點列表或規則集,你不需要手動同步。缺點是如果你在舊客戶端裡做過手動修改(比如調整過某個代理群組的策略),這部分修改不會帶過來,需要重新設定。
方式二:直接匯入本機設定檔
把備份出來的 .yaml 檔案透過新客戶端的「從檔案匯入」功能載入。這種方式保留了你手動改過的全部內容,但訂閱方後續更新時,你需要自己判斷是否要用新版本覆蓋目前檔案。
# 典型的 Clash / mihomo 設定檔頂層結構,遷移時核對欄位是否被新客戶端識別
mixed-port: 7890
allow-lan: true
mode: rule
log-level: info
dns:
enable: true
nameserver:
- 223.5.5.5
- 119.29.29.29
proxies:
- name: "示例節點"
type: vmess
server: example.com
port: 443
proxy-groups:
- name: "自動選擇"
type: url-test
proxies: ["示例節點"]
rules:
- DOMAIN-SUFFIX,example.com,自動選擇
- MATCH,DIRECT匯入後重點核對三處:一是 proxy-groups 裡引用的節點名稱是否和 proxies 列表完全一致(大小寫、空格都會導致比對失敗);二是 rules 裡的策略群組名稱是否存在,新客戶端如果對未定義的分組報錯,通常就是這個原因;三是 DNS 設定區塊的寫法,新版核心對 nameserver-policy、fake-ip-filter 等欄位的解析可能比舊核心更嚴格。
方式三:混合遷移
先用訂閱連結產生基礎設定,再把舊設定裡的覆寫腳本正文單獨貼到新客戶端的覆寫功能裡。這是多數長期使用者實際採用的方式,既能享受訂閱方的持續維護,又不丟失自己的客製內容。
切換完成後,依次確認:節點列表能正常測速、代理群組的自動選擇策略生效、指定網域走對了分組(用規則裡設定過的網域做一次實測)、DNS 解析沒有異常(用命令列工具查一次網域解析結果)。四項都正常再卸載舊客戶端。
三款接手客戶端橫向對比
CFW 停更後,社群裡逐漸形成了幾個公認的接手方向,思路各有側重,選擇時可以按下面的維度對照自己的實際需求。
| 客戶端 | 技術路線 | 介面風格 | 適合人群 |
|---|---|---|---|
| Clash Plus | 基於 mihomo 核心,官方持續維護 | 貼近 CFW 原有互動習慣,上手成本低 | 希望遷移後操作邏輯變化最小的使用者 |
| Clash Verge Rev | Rust 編寫外殼 + mihomo 核心,社群活躍維護 | 輕量,提供圖形化規則編輯與訂閱管理 | 喜歡自訂細節、願意折騰設定的使用者 |
| FlClash | 跨平台外殼,支援桌面與行動裝置統一體驗 | 簡潔,強調多裝置設定同步的一致性 | 同時在多台裝置之間切換使用的使用者 |
三者的共同基礎都是 mihomo 核心,這意味著協定支援範圍和規則語法的核心能力是一致的,真正的差異體現在介面互動深度、訂閱管理便利性、以及是否提供額外的圖形化設定能力。如果你此前在 CFW 裡習慣用最基礎的訂閱+規則模式,幾款客戶端切換後都不會有明顯的功能缺失感;如果你依賴過 CFW 的某些細節功能(比如特定的流量統計顯示方式),建議先用小範圍測試確認新客戶端是否提供等價能力,再做正式切換。
選擇時的幾個實際判斷點
- 是否需要頻繁手動改規則:如果經常手動增刪規則,優先選擇提供圖形化規則編輯介面的客戶端,能減少直接改 YAML 檔案出錯的機率。
- 是否多裝置使用:如果同一套設定要在電腦和手機之間切換,優先考慮設定同步能力更完善的方案,減少重複維護訂閱的工作量。
- 是否追求核心更新速度:三者都跟隨 mihomo 上游更新,但發版節奏存在差異,對新協定特性有迫切需求的使用者可以關注各自的更新日誌頻率。
遷移完成後如何避免「二次踩坑」
換了客戶端不代表萬事大吉,以下幾點是實際遷移中最常被忽略、事後又最容易返工的細節。
訂閱更新週期要重新確認。不同客戶端對訂閱的自動更新間隔設定位置不同,遷移後建議重新開啟訂閱詳情,確認自動更新週期(通常以小時為單位)是否符合預期,避免節點資訊長期未刷新導致連線失敗卻找不到原因。
開機自動啟動與靜默模式要重新勾選。這是最容易被忘記的一項——舊客戶端設定的開機自動啟動不會帶到新客戶端,重裝後系統重啟時會發現代理沒有自動啟動,需要在新客戶端的系統設定裡重新勾選。
本機覆寫腳本要逐條測試。如果覆寫腳本裡有依賴 CFW 特定 API 或欄位名稱的寫法,新客戶端解析時可能靜默忽略而不報錯,建議逐條註解掉部分規則再逐步恢復,定位到底哪一段生效、哪一段沒生效。
確認核心版本號。遷移後在新客戶端裡查看目前使用的 mihomo 核心版本號,和你此前遇到的問題對照的話,能確認是否是因為核心升級順帶修復了舊問題,還是需要額外設定才能解決。
不建議為了「省事」繼續長期使用已停更的 CFW 且完全不關注後續風險。協定相容性問題會隨時間推移逐漸累積,越晚遷移,屆時需要核對的設定差異往往越多。
總體上,從 CFW 遷移到接手客戶端是一次性的、可控的工作量,核心步驟是備份訂閱連結與覆寫腳本、選定一款基於 mihomo 核心的新客戶端、逐項核對規則與 DNS 欄位、完成後走一遍驗證清單。只要按順序做完,原有的使用習慣和設定邏輯基本能夠無損保留。