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 只有在安装来源、完整构建号和实际服务组件均有修复证据时才重新开启；证据不足时继续停用并向维护者反馈错误。