本文目录
先确认 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 不接管流量，或必须提前验证便携模式迁移，再安排一次有回退窗口的测试。
发布通道与处理方式
| 看到的版本 | 项目状态 | 建议 |
|---|---|---|
| v2.5.2 | Latest 稳定版 | 日常环境优先保留，等待下一个正式 Release |
| v2.5.4-rc / AutoBuild | Pre-release | 只在完成备份并能回退时测试 |
| 只看到应用内更新提示 | 通道尚未确认 | 先打开官方 Release 核对标签、日期和资产文件名 |
| 第三方打包或解压版 | 不属于官方发布保证 | 不要用来判断 v2.5.4 的迁移结果 |
先判断自己是否需要测试这次变化
发布说明列出的修复很多，但升级前应只选一个自己能复现的目标。比如系统代理切换失败后界面状态错误，就记录开关状态、系统代理实际值和一条真实请求；服务模式操作超时，就记录首条错误和后续操作是否继续异常。
近期 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 自己的持久化目录和升级行为。
稳定版工作正常，只想追新版本
留在 v2.5.2，等待正式版，不为 AutoBuild 承担迁移风险。
正在使用便携版或自定义数据目录
先记录旧数据位置和启动方式，再备份旧目录与系统数据目录。
系统代理开关显示与系统实际状态不一致
保存升级前对照，升级后只验证系统代理，不同时改 TUN 和端口。
Windows TUN 的 system/mixed 堆栈不接管流量
记录当前堆栈、服务状态与同一测试目标，再评估包含相关修复的 RC。
应用、内核或全部订阅都无法启动
先恢复现有稳定环境，不把所有启动故障都归给这次发布。
升级前完整备份系统应用数据目录
先完整退出 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。
官方数据目录
| 平台 | 应用数据目录 | 备份重点 |
|---|---|---|
| Windows | %APPDATA%\io.github.clash-verge-rev.clash-verge-rev | verge.yaml、profiles.yaml、profiles/、config.yaml |
| 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，并另记实际 XDG_DATA_HOME |
备份完成标准
- Clash Verge Rev 已完整退出，复制时没有继续写入配置
- 系统应用数据目录已整体复制到独立位置
- 旧便携或自定义数据目录也已单独保存
- 原版本、系统架构、安装来源和备份时间已经记录
- 原始备份保持私有，公开证据已经删除 token、密码、UUID 和访问域名
便携模式先迁移数据，不要直接覆盖旧目录
v2.5.4 的发布说明只确认“移除便携模式，统一使用系统应用数据目录”，没有承诺自动找到每一种第三方便携打包或自定义目录。因此不要先删除旧文件，也不要把新程序直接解压到旧程序目录后期待它自动读取原配置。
在旧版本仍可打开时，先记录当前 Profile 名称、订阅来源、覆写与脚本、系统代理、TUN、服务模式和端口。然后同时备份旧程序附近的数据目录与官方系统应用数据目录。安装 RC 后，先让它创建并使用新的系统数据目录，再从应用提供的导入或备份恢复入口恢复。
若只能手工恢复，先关闭新版本，保留它刚创建的目录副本，再一次性复制完整的已备份配置集合。不要只挑一份 profiles.yaml、只复制 profiles/，或把新旧 verge.yaml 混在一起；这些文件之间的引用和当前选择可能不同步。
从旧便携环境迁移
记录旧环境
保存版本、启动路径、数据目录、Profile 列表、覆写、端口、系统代理和 TUN 状态。
做两份独立备份
分别复制旧便携或自定义目录，以及当前系统应用数据目录；不要覆盖同名备份。
让新版本建立目录
从官方 v2.5.4-rc 安装并启动一次，确认它使用系统应用数据目录后完整退出。
按完整备份恢复
优先使用应用内恢复；手工恢复时保持文件集合一致，并保留新版本初始目录副本。
先验证 Profile 再开 TUN
确认订阅、策略组和选中节点正确后，先测试系统代理，最后再恢复服务模式与 TUN。
只从官方 GitHub Release 安装对应架构
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-rc Release，并明确标记 Pre-release。
核对系统与架构
Windows、macOS、Linux 的安装包不能混用，x64、arm64、Apple M 与 Intel 也要对应。
保存回退材料
保留 v2.5.2 官方安装包、完整数据备份和旧便携目录。
关闭旧实例再安装
完整退出旧版本，不让两个界面或内核同时修改同一数据目录。
服务模式下不要修改缓存副本
v2.5.4 Release 把一条重要提醒放在最前面：服务模式下，配置目录中的规则集和代理集合文件只是缓存副本，手动修改不会影响正在运行的内核。需要自己维护的文件应在配置中使用 type: file，而不是继续编辑服务生成的缓存。
这次 AutoBuild 还加入服务模式多用户隔离和旧服务升级迁移，并修复操作超时后继续报错或状态异常的问题。升级后先从界面确认服务安装状态和当前用户，再检查应用日志与 service-logs；不要看到旧缓存仍在，就据此判断新内核加载了手工修改。
如果原配置依赖手工修改 provider 缓存，先恢复备份并把真正需要维护的规则集或代理集合改成明确的本地 file provider。一次只迁移一个文件，重新加载后用连接记录或规则命中验证，避免把服务迁移、provider 迁移和订阅更新同时进行。
先验证系统代理，再单独验证 TUN
恢复 Profile 后先关闭 TUN，只开启系统代理，用同一节点完成一次真实 HTTPS 请求，并在 Connections 中确认目标、规则和出口。然后关闭系统代理，确认操作系统代理状态同步恢复；这一步用于验证发布说明中的系统代理状态与恢复修复。
系统代理稳定后再安装或升级服务并开启 TUN。Windows 如果原问题只出现在 system 或 mixed 堆栈，就保持同一节点和测试目标复测；不要同时切换 gVisor、DNS、端口和覆写。macOS、Linux 则重点确认授权流程、绕过规则和服务日志没有继续报旧权限错误。
v2.5.4 新增 TUN 的 Mips 堆栈选项，Release 明确要求 Mihomo v1.19.31 或以上。没有这个内核版本或没有明确测试目的时，不要只因新增选项就切换堆栈。
分层验证
| 层级 | 要验证什么 | 失败时先做什么 |
|---|---|---|
| 应用与 Profile | 订阅、策略组、选中节点和覆写都存在 | 停在应用层，先恢复完整备份 |
| 系统代理 | 开关与系统实际状态一致，真实 HTTPS 请求进入 Connections | 关闭开关并恢复系统代理，再查日志 |
| 服务模式 | 当前用户可以安装、启动和执行操作，service-logs 无持续错误 | 卸载或停用服务，退回系统代理 |
| TUN | 同一目标被接管，DNS 与路由正常，关闭后网络恢复 | 关闭 TUN，不连续切换多个堆栈 |
| Mips | 内核至少 v1.19.31，且有单独的接管验证 | 恢复升级前堆栈 |
用同一组请求完成升级验收
版本号和界面能打开只证明安装完成，不证明迁移成功。重启一次系统和 Clash Verge Rev，再用升级前保存的同一 Profile、同一节点与同一 HTTPS 目标依次验证应用启动、系统代理、服务模式和 TUN。
再检查系统应用数据目录确实保存了新修改，重启后 Profile、选中节点、覆写和端口没有回到旧值。使用本地 type: file 的规则集或代理集合时，还要确认运行配置引用的是源文件，不是服务缓存副本。
测试期间不要删除旧便携目录、v2.5.2 安装包或升级前备份。至少完成一次重启和一次关闭代理后的直连恢复，再决定是否继续使用 RC。
v2.5.4-rc 验收清单
- 运行版本明确显示 v2.5.4-rc，并记录了目标提交和资产文件名
- 数据来自系统应用数据目录，旧便携目录仍保持只读备份
- 订阅、Profile、覆写、脚本、策略组和选中节点完整
- 系统代理的界面状态与操作系统实际状态一致
- 服务模式操作可完成，日志没有超时后的持续错误
- TUN 使用原堆栈完成真实请求，关闭后系统网络恢复
- 手工维护的 provider 使用 type: file，没有继续编辑缓存副本
- 重启系统和应用后配置仍保持，且没有两个实例同时运行
- v2.5.2 安装包、完整数据备份和回退步骤仍可使用
出现异常就完整回退 v2.5.2
如果 RC 无法启动、配置迁移不完整、系统代理或 TUN 出现新回归，先关闭 TUN 和系统代理，完整退出应用，并确认操作系统已经恢复直连。不要在异常状态下继续更新订阅或反复覆盖数据目录。
保存一份 v2.5.4 的故障现场副本后，使用官方 v2.5.2 安装包恢复程序，并把升级前的完整数据备份作为一个整体恢复。不要只换回可执行文件却继续使用已经由新版本改写的部分配置，也不要把新旧资源文件拼在一起。
回退后先确认版本与 Profile，再按系统代理、服务模式、TUN 的顺序验证。若旧便携版本原本稳定，可以临时恢复旧程序与旧数据目录，但保持它与系统数据目录分离，等待后续正式版给出明确迁移说明。
安全回退
恢复直连
关闭 TUN 和系统代理，完整退出 RC，确认普通网络在没有本地代理时可用。
保存故障现场
复制 v2.5.4 当前数据目录和脱敏日志，避免覆盖升级前备份。
恢复稳定程序
从官方 Release 安装与原系统架构一致的 v2.5.2。
恢复完整数据
使用升级前整体备份恢复，不混用新旧单个文件。
逐层验证
确认 Profile 后先测系统代理，再测服务模式和 TUN，并完成关闭后的直连恢复。
后续以正式 Release 判断迁移完成
截至 2026 年 9 月 17 日，v2.5.4-rc 与 AutoBuild 都是预发布，v2.5.2 仍是 Latest 稳定版。后续应以项目正式 Release 页面是否发布新稳定版本、是否保留便携模式移除和数据目录说明为准，不根据预发布版本号猜测正式版发布日期。
正式版到来后仍需保留一次相同的迁移验证：完整备份、确认系统数据目录、恢复 Profile、先测系统代理、再测服务模式与 TUN、最后验证回退。AutoBuild 测试成功不能替代正式版复核。
如果需要提交问题，提供系统、架构、安装渠道、旧版与新版、旧数据目录与新系统目录、首条相关日志和最小复现步骤。公开前删除订阅 token、节点凭据、WebDAV 信息、访问域名和完整本地路径。