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

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 等多項修改，並移除可攜模式，統一使用系統應用資料目錄。它適合願意保留完整備份、能夠做桌面網路驗證並可立即還原的人，不適合僅因版本號更大就直接覆蓋日常唯一環境。

如果目前 v2.5.2 使用正常，又不需要驗證發布說明中的某項修復，繼續留在穩定版是完整方案。若正在處理系統代理狀態錯誤、服務模式超時、Windows system/mixed TUN 不接管流量，或必須提前驗證可攜模式遷移，再安排一次可隨時還原的測試時段。

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

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

Service IPC 隨後為暫存在 %ProgramData% 的核心補充防火牆規則，主倉升級到包含該修復的 2.7.0；v2.5.4-rc 的發布說明已經列入這項修復。

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

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

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

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

官方隱私文件把 Windows 目錄列為 %APPDATA%\io.github.clash-verge-rev.clash-verge-rev，macOS 為 ~/Library/Application Support/io.github.clash-verge-rev.clash-verge-rev。

Linux 使用 $XDG_DATA_HOME/io.github.clash-verge-rev.clash-verge-rev，通常位於 ~/.local/share。

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

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

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

在舊版本仍可開啟時，先記錄目前 Profile 名稱、訂閱來源、覆寫與指令碼、系統代理、TUN、服務模式和連接埠。然後同時備份舊程式附近的資料目錄與官方系統應用資料目錄。安裝 RC 後，先讓它建立並使用新的系統資料目錄，再從應用提供的匯入或備份恢復入口恢復。

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

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

Windows 普通裝置通常選擇 x64；ARM Windows 選擇 arm64。只有系統缺少且無法安裝 WebView2，或普通包無法開啟介面時，才考慮檔案名帶 fix_webview2 的大體積版本。macOS 要區分 Apple 晶片與 Intel，Linux 要同時匹配發行版包格式和 CPU 架構。

安裝前儲存安裝檔名稱和下載時間，不使用第三方「綠色版」、不從搜尋廣告下載同名安裝套件，也不把穩定版與 RC 的資源目錄混合。正式環境只有一個時，應先準備 v2.5.2 官方安裝套件和完整資料備份，再啟動測試安裝。

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

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

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

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

系統代理穩定後再安裝或升級服務並開啟 TUN。Windows 如果原問題只出現在 system 或 mixed 堆疊，就保持同一節點和測試目標重新測試；不要同時切換 gVisor、DNS、連接埠和覆寫。macOS、Linux 則重點確認授權流程、繞過規則和服務日誌沒有繼續報舊權限錯誤。

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

版本號和介面能開啟只證明安裝完成，不證明遷移成功。重啟一次系統和 Clash Verge Rev，再用升級前儲存的同一 Profile、同一節點與同一 HTTPS 目標依序驗證應用啟動、系統代理、服務模式和 TUN。

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

測試期間不要刪除舊可攜目錄、v2.5.2 安裝套件或升級前備份。至少完成一次重啟和一次關閉代理後的直連恢復，再決定是否繼續使用 RC。

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

儲存一份 v2.5.4 的故障現場副本後，使用官方 v2.5.2 安裝套件恢復程式，並把升級前的完整資料備份作為一個整體恢復。不要只換回可執行檔案卻繼續使用已經由新版本改寫的部分設定，也不要把新舊資源檔案拼在一起。

還原後先確認版本與 Profile，再按系統代理、服務模式、TUN 的順序驗證。若舊可攜版本原本穩定，可以暫時恢復舊程式與舊資料目錄，但保持它與系統資料目錄分離，等待後續正式版提供明確的遷移說明。

截至 2026 年 9 月 17 日，v2.5.4-rc 與 AutoBuild 都是預發布，v2.5.2 仍是 Latest 穩定版。後續應以專案正式 Release 頁面是否發布新穩定版本、是否保留可攜模式移除和資料目錄說明為準，不根據預發布版本號猜測正式版發布日期。

正式版到來後仍需保留一次相同的遷移驗證：完整備份、確認系統資料目錄、恢復 Profile、先測系統代理、再測服務模式與 TUN、最後驗證還原。AutoBuild 測試成功不能替代正式版復核。

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