Clash 客戶端停更後的遷移方案:設定轉移與替代客戶端選型

如何判斷一個客戶端已經停止維護

Clash 生態裡的客戶端大多是圍繞同一套代理核心(早期的 Clash Premium,現在更多是 Clash Meta 及其繼任者 mihomo)搭建的圖形介面外殼。核心負責規則比對、協定解析和流量轉發,客戶端負責設定管理、介面呈現和平台適配。當某個客戶端專案的儲存庫連續數月無提交、Release 頁面停留在舊版本、Issue 區堆積大量未回應的相容性問題時,基本可以判斷它已進入停更狀態。

比停更本身更值得關注的是停更的原因。如果是維護者精力轉移到了另一個繼任專案(常見做法是在儲存庫 README 裡註明「請遷移至 XXX」),遷移路徑通常很平順,設定格式幾乎不變。如果是因為上游核心 API 變化導致客戶端徹底無法適配,或者專案本身涉及散布合規問題被下架,處理起來就需要更謹慎,建議直接換用架構不同的替代方案,而不是在舊客戶端上繼續等待。

判斷停更還有幾個具體訊號可以交叉驗證:客戶端啟動後長期無法拉取新版本提示、內建的規則集更新來源持續 404、開發者在社群(Telegram 群組、Discord 或 GitHub Discussions)明確發布了停更公告。任何單一訊號都可能是暫時性的網路問題或誤判,建議至少滿足兩條才動手遷移,避免在專案短暫沉默期做了不必要的搬家。

確認設定與訂閱能否直接複用

遷移的第一步不是急著卸載舊客戶端,而是先確認現有的設定檔和訂閱連結在新客戶端上能不能直接吃下。Clash 系列設定檔本質是一份 YAML,核心欄位(proxies、proxy-groups、rules)在絕大多數客戶端之間是通用的,因為它們遵循的是核心規範而不是客戶端自己定義的格式。但客戶端專屬的擴充欄位並不通用,常見的差異點包括:

• 某些客戶端支援的 proxy-providers 遠端代理提供者語法版本不同,欄位名稱或必填項略有差異;
• GUI 客戶端常在設定檔頂部或末尾插入自己的私有欄位(比如介面主題、系統匣圖示偏好),這些欄位遷移到新客戶端時會被忽略,不影響代理功能,但也不會被繼承;
• TUN 模式的實作方式在不同核心版本間存在差異,部分舊版客戶端使用的 tun 欄位結構(如 stack 取值範圍)在新版 mihomo 核心上已經更新,直接複製可能需要手動調整。

訂閱連結層面通常不需要額外處理——訂閱位址回傳的是標準設定或 Base64 編碼的節點清單,客戶端只是扮演下載和解析的角色,換一個客戶端重新加入同一條訂閱位址即可,不涉及訂閱商家端的任何改動。真正需要手動搬運的,是你在舊客戶端裡做的本機覆寫和自訂規則,這些內容只存在於本機,訂閱來源不會包含。

匯出本機覆寫與自訂規則的具體步驟

本機覆寫(override)是大多數 Clash 客戶端提供的機制,用於在不修改訂閱原文的前提下,對下發的設定做局部調整——比如追加自訂規則、修改 DNS 設定、啟用 TUN 模式、調整區域網路監聽埠。這部分內容只存在於客戶端本機儲存中,換客戶端前必須手動匯出,否則遷移後所有個人化設定都要從零設定。具體建議按以下順序操作:

1. 定位覆寫檔案的實際路徑

   大多數客戶端會把覆寫內容以獨立 YAML 檔案的形式存放在設定目錄下(通常與訂閱快取檔案同層),而不是直接寫進訂閱檔案。找到這個目錄後複製出來,比在介面裡逐項截圖記錄更可靠。

2. 區分規則覆寫與參數覆寫

   規則覆寫(自訂 DOMAIN、IP-CIDR 規則)通常可以整段複製到新客戶端的對應位置;參數覆寫(埠號、DNS、TUN 網卡名稱)則需要對照新客戶端的欄位命名重新填寫,因為不同客戶端的介面選項和底層欄位名稱並不總是一一對應。

3. 記錄策略群組的自訂排序

   如果你手動調整過策略群組內節點的順序或分組邏輯(而不是完全依賴訂閱預設分組),這部分資訊一般不會體現在覆寫檔案裡,而是儲存在客戶端的介面狀態中,需要單獨截圖或文字記錄後在新客戶端裡重新排列。

4. 備份客戶端自身的執行參數

   包括開機自動啟動、系統代理模式、混合埠設定等,這些都是客戶端層級的偏好,和代理設定無關,遷移後需要在新客戶端裡逐一重新勾選。

按平台選擇仍在積極維護的替代客戶端

選擇替代客戶端時,優先看兩個硬指標:儲存庫的提交活躍度,以及是否跟進了最新的 mihomo 核心版本。核心決定了協定支援範圍和規則比對的準確性,客戶端跟得慢,新協定(如新版 Hysteria2 參數)可能用不到。桌面端和行動端的替代邏輯不太一樣,分開來看更清楚:

Windows / macOS / Linux 桌面端:目前主流的替代路徑是轉向基於 Tauri 或類似輕量框架的新一代客戶端,這類客戶端資源占用更低,更新頻率也更穩定,並且大多預設整合了最新的 mihomo 核心,不需要使用者手動更換核心檔案。遷移時重點確認新客戶端的系統代理接管方式(是走 PAC 還是直接設定系統代理),以及 TUN 模式是否需要額外安裝虛擬網卡驅動。

Android:Android 端客戶端普遍圍繞 VpnService 系統介面實作全域代理,更換客戶端後需要重新授權 VPN 權限,並檢查是否需要把新客戶端重新加入系統的省電白名單,否則容易出現背景被系統關閉導致斷線的問題。分應用程式代理(依套件名稱選擇走代理的 App)的清單也需要在新客戶端裡重新設定,舊客戶端的清單不會自動遷移。

iOS:iOS 端客戶端受 App Store 審核政策影響較大,選擇替代品前建議先確認目標客戶端在目前系統版本下能否正常安裝並取得網路擴充功能權限。設定檔的相容性處理方式與桌面端一致,訂閱連結可以直接複用。

遷移完成後需要重新檢查的項目清單

設定匯入新客戶端後,不要直接假設一切照舊,以下幾項是實際遷移中最容易被漏檢、導致「看似正常但實際不對」的問題點:

• DNS 設定:新客戶端的預設 DNS 策略可能與舊客戶端不同(比如是否啟用 fake-ip 模式),直接影響網域名稱解析結果和分流準確性,建議對照舊設定裡的 dns 欄位逐項核對。
• 區域網路與混合埠:埠號在新客戶端裡可能恢復為預設值,如果你的路由器或其他裝置依賴固定埠連線,需要重新設定為遷移前的數值。
• 規則集更新來源:部分客戶端會自帶遠端規則集(GeoIP、GeoSite 資料庫),更換客戶端後這些規則集的更新位址需要重新設定,否則規則會停留在客戶端首次內建的版本上,逐漸過時。
• 策略群組的自動測速參數:url-test、fallback 等自動策略群組依賴的測速位址(url 欄位)和檢測間隔(interval)在新客戶端裡如果沿用預設值,可能和你之前針對特定網路環境調校過的數值不一致,影響自動切換的靈敏度。
• 開機自動啟動與系統代理接管:這是最容易被忽略的一項——功能遷移完成後,很多人會忘記重新勾選開機自動啟動,導致電腦重新開機後代理沒有生效卻沒意識到原因。

建議遷移當天保留舊客戶端不卸載,新客戶端跑滿一到兩天確認穩定後再徹底清理舊版本及其設定目錄。這樣即便發現某個覆寫項漏遷移,也能隨時回舊客戶端裡核對原始設定,而不必憑記憶重新摸索。