Clash Verge Rev v2.5.4-rc 要不要升級？

本文討論的是 9 月 17 日的預先發布版本。官方 GHSA-99qg-xv7m-jf4v 將 Windows 服務的 <= 2.5.4 列為受影響範圍，並明確指出修復建置為 v2.5.4+autobuild.0908.bbab52d。Windows 使用者不可把 v2.5.2 服務當作安全的還原方案。

Clash Verge Rev v2.5.4-rc 於 2026 年 9 月 17 日 19:36（Asia/Shanghai）發布，GitHub Release 明確標記為 Pre-release。截至同一時間，專案的 Latest 穩定版仍是 v2.5.2；看到 v2.5.4 版本號，不等於它已經替代正式版。

核對這次 RC 與持續更新的 AutoBuild 時，分別記錄系統代理、服務模式、訂閱編輯、節點選擇、連接埠避讓和 TUN 的變更，以及移除可攜模式、統一使用系統應用程式資料目錄的遷移。只有已保存完整備份、能做桌面網路驗證並可立即復原時才測試，不直接覆蓋唯一的日常環境。

若正在處理系統代理狀態錯誤、服務模式超時、Windows system/mixed TUN 不接管流量，或必須驗證便攜模式遷移，應先核對目前官方 Release 和安全公告，再安排有備份的測試。

截至 2026 年 9 月 17 日，v2.5.4-rc 與 AutoBuild 都是預發布，v2.5.2 當時仍是 Latest 穩定版。這是歷史發布狀態，不再是目前安裝建議。9 月 22 日已有 v2.5.5 正式版，Windows 服務風險還須對照 GHSA 的修復建置。

發布說明列出的修復很多，但升級前應只選一個自己能復現的目標。比如系統代理切換失敗後介面狀態錯誤，就記錄開關狀態、系統代理實際值和一條實際請求；服務模式操作超時，就記錄首條錯誤和後續操作是否繼續異常。

近期 issue #7915 的範圍很窄：Windows 服務模式中的特定 v2.5.4 AutoBuild 使用 system 或 mixed TUN 堆疊時沒有流量，gVisor 正常，還原 v2.5.2 後恢復。

Service IPC 後續為暫存在 %ProgramData% 的核心補上防火牆規則，v2.5.4-rc 的發布說明已列入這項修正。該標籤的 Cargo.toml 使用 Service IPC 相依元件 v2.7.1；這是背景元件的相依版本，不是用戶端安裝目標。

這不表示所有 TUN 無流量都由防火牆導致，也不應讓使用者手動關閉 Windows 防火牆。只有版本、Windows 服務模式、堆疊差異和無流量現象同時匹配時，才把它作為升級 RC 的一個理由。

可攜模式使用者的目標不是先驗證網路，而是確認設定從哪裡讀取。v2.5.4 明確移除可攜模式並統一使用系統應用資料目錄；如果舊安裝把資料放在程式附近、Scoop 目錄或自訂位置，必須先找出舊目錄並單獨儲存。

Scoop 是官方文件列出的社群維護發行管道，文件提到它可用於修改設定目錄或可攜需求，但專案也明確不為下游管道問題提供支援。這與 v2.5.4 應用內的「移除可攜模式」不是同一項保證；使用 Scoop 時還要核對 Scoop 自己的持久化目錄和升級行為。

先完整退出 Clash Verge Rev，確認系統匣處理程式和服務操作已經結束，再複製應用資料目錄。

目錄中的 verge.yaml、config.yaml、profiles.yaml 和 profiles/ 是恢復設定、訂閱與 Profile 的關鍵。logs/、service-logs/、cache.db 和 Geo 資料也可以幫助對照，但不要只儲存日誌而漏掉設定。

備份應儲存在應用工作目錄之外，並標明系統、架構、原版本和時間。verge.yaml 可能明文儲存 WebDAV 位址、使用者名稱和密碼，Profile 可能包含訂閱 token、節點密碼和 UUID；不要把原始備份上傳到公開雲端硬碟或直接附在 Issue。

舊版還能開啟時，記錄目前 Profile 名稱、訂閱來源、覆寫與指令碼、系統代理、TUN、服務模式和連接埠；同時保留舊程式旁的資料目錄與官方系統應用程式資料目錄。

Clash Verge Rev 官方文件說明，專案目前只透過 GitHub Release 發布。測試 v2.5.4-rc 時應開啟該 RC 的官方 Release，確認頁面標記 Pre-release、目標提交為 c7ffb212，並記錄發布時間和安裝檔名稱，再按系統與架構選擇安裝檔。

一般 Windows 裝置通常選 x64，ARM Windows 選 arm64。只有系統缺少且無法安裝 WebView2，或一般套件無法開啟介面時，才考慮檔名含 fixed_webview2 的大型版本。

macOS 須區分 Apple 晶片與 Intel，Linux 則須同時符合發行版套件格式與 CPU 架構。

安裝前儲存資產檔案名和下載時間，不使用第三方“綠色版”、不從搜尋廣告下載同名安裝套件，也不把穩定版與 RC 的資源目錄混合。正式環境只有一個時，應先準備完整資料備份和不依賴受影響 Windows 服務的聯網還原路徑。

完整退出舊版本，不讓兩個介面或核心同時修改同一資料目錄。

v2.5.4 的發布說明只確認「移除可攜模式，統一使用系統應用資料目錄」，沒有承諾自動找到每一種第三方可攜打包或自訂目錄。因此不要先刪除舊檔案，也不要把新程式直接解壓縮到舊程式目錄後期待它自動讀取原設定。

若只能手動恢復，先關閉新版本，保留它剛建立的目錄副本，再一次性複製完整的已備份設定集合。不要只挑一份 profiles.yaml、只複製 profiles/，或把新舊 verge.yaml 混在一起；這些檔案之間的引用和目前選擇可能不同步。

v2.5.4 Release 把一條重要提醒放在最前面：服務模式下，設定目錄中的規則集和代理集合檔案只是快取副本，手動修改不會影響正在執行的核心。需要自己維護的檔案應在設定中使用 type: file，而不是繼續編輯服務產生的快取。

這次 AutoBuild 還加入服務模式多使用者隔離和舊服務升級遷移，並修復操作超時後繼續發生錯誤或狀態異常的問題。升級後先從介面確認服務安裝狀態和目前使用者，再檢查應用日誌與 service-logs；不要看到舊快取仍在，就據此判斷新核心載入了手動修改。

如果原設定依賴手動修改 provider 快取，先恢復備份並把真正需要維護的規則集或代理集合改成明確的本機 file provider。一次只遷移一個檔案，重新載入後用連線記錄或規則命中驗證，避免把服務遷移、provider 遷移和訂閱更新同時進行。

恢復 Profile 後先關閉 TUN，只開啟系統代理，用同一節點完成一次實際 HTTPS 請求，並在 Connections 中確認目標、規則和出口。然後關閉系統代理，確認作業系統代理狀態同步恢復；這一步用於驗證發布說明中的系統代理狀態與恢復修復。

Windows 只有完整建置、安裝來源與實際服務元件均有 GHSA 修復證據時才測試服務模式和 TUN；證據不足就保持服務停用，只驗證系統代理。原問題發生在 system 或 mixed 堆疊時，在符合安全條件後按原堆疊重新測試。

測試時保持同一節點與目標，不同時切換 gVisor、DNS、連接埠和覆寫。macOS、Linux 按原授權流程確認繞過規則與服務日誌，不應繼續出現舊權限錯誤。

v2.5.4 新增 TUN 的 Mips 堆疊選項，Release 明確要求 Mihomo v1.19.31 或以上。沒有這個核心版本或沒有明確測試目的時，不要只因新增選項就切換堆疊。

重啟系統和 Clash Verge Rev，用升級前同一 Profile、節點和 HTTPS 目標驗證啟動與系統代理。Windows 服務模式及 TUN 僅在完整建置與實際服務均有 GHSA 修復證據時驗收；否則保持停用。macOS、Linux 按原授權流程驗證。

再檢查系統應用資料目錄確實儲存了新修改，重啟後 Profile、選中節點、覆寫和連接埠沒有回到舊值。使用本機 type: file 的規則集或代理集合時，還要確認執行設定引用的是源檔案，不是服務快取副本。

測試期間不要刪除舊便攜目錄或升級前備份，也不要重新啟用受影響的 Windows 舊服務。至少完成一次重啟和一次關閉代理後的直連恢復，再決定是否繼續使用目前建置。

AutoBuild 測試成功後，正式版仍須按相同條件復核遷移與網路恢復。

如果需要提交問題，提供系統、架構、安裝管道、舊版與新版、舊資料目錄與新系統目錄、首條相關日誌和最小復現步驟。公開前刪除訂閱 token、節點認證資訊、WebDAV 資訊、存取網域和完整本機路徑。

如果 RC 無法啟動、設定遷移不完整、系統代理或 TUN 出現新的異常，先關閉 TUN 和系統代理，完整退出應用，並確認作業系統已經恢復直連。不要在異常狀態下繼續更新訂閱或反覆覆蓋資料目錄。

保存故障時的資料目錄副本後，保留可信的完整設定備份，但不要在 Windows 上重新安裝或啟用 <= 2.5.4 的舊服務。先用不依賴該服務的系統代理或其他可信用戶端恢復必要連線，再核對 GHSA 明確標出的修正後建置版本。

恢復後先確認 Profile 和實際 HTTPS 請求。服務模式與 TUN 只有在安裝來源、完整建置號和實際服務元件均有修復證據時才重新開啟；證據不足時繼續停用並向維護者意見回饋錯誤。