Should You Upgrade to Clash Verge Rev v2.5.4-rc?

Clash Verge Rev v2.5.4-rc was released at 19:36 on 9/17/2026 (Asia/Shanghai), and the GitHub Release is explicitly marked Pre-release. At that time, the project's Latest stable version was still v2.5.2; seeing the v2.5.4 version number does not mean it has replaced the stable release.

This RC and the rolling AutoBuild include changes to the system proxy, service mode, subscription editing, node selection, port-conflict avoidance, and TUN. They also remove portable mode in favor of a single system app data directory. The build is suitable for people who will keep a complete backup, can validate desktop networking, and can roll back immediately, not for anyone planning to overwrite their only daily environment merely because the version number is higher.

If v2.5.2 currently works and you do not need to validate a specific fix from the release notes, staying on the stable version is a complete solution. Schedule a test with a rollback window only if you are troubleshooting an incorrect system proxy state, a service-mode timeout, Windows system/mixed TUN failing to capture traffic, or an urgent portable-mode migration.

The release notes list many fixes, but before upgrading, choose only one target you can reproduce. If the interface shows the wrong state after a system proxy toggle fails, record the toggle state, the actual system proxy value, and one real request. If a service-mode operation times out, record the first error and whether later operations remain abnormal.

The recent issue #7915 has a narrow scope: a specific v2.5.4 AutoBuild in Windows service mode carried no traffic with the system or mixed TUN stack, while gVisor worked and rolling back to v2.5.2 restored traffic.

Service IPC then added a firewall rule for the core staged in %ProgramData%, and the main repository upgraded to 2.7.0 with that fix; the v2.5.4-rc release notes include it.

This does not mean every case of TUN carrying no traffic is caused by the firewall, nor should users disable Windows Firewall manually. Treat it as a reason to test the RC only when the version, Windows service mode, stack-specific behavior, and no-traffic symptom all match.

For portable-mode users, the first goal is not network validation but confirming where the configuration is read from. v2.5.4 explicitly removes portable mode and standardizes on the system app data directory. If the old installation stored data beside the program, in a Scoop directory, or in a custom location, find that old directory and save it separately first.

Scoop is a community-maintained distribution listed in the official documentation, which notes that it can support a changed configuration directory or portable use. The project also explicitly does not support issues caused by downstream channels. That is not the same assurance as v2.5.4 removing portable mode inside the app; Scoop users must also verify Scoop's own persistence directory and upgrade behavior.

Exit Clash Verge Rev completely, confirm that the tray process and service operations have ended, and then copy the app data directory.

The official privacy documentation lists the Windows directory as %APPDATA%\io.github.clash-verge-rev.clash-verge-rev and the macOS directory as ~/Library/Application Support/io.github.clash-verge-rev.clash-verge-rev.

Linux uses $XDG_DATA_HOME/io.github.clash-verge-rev.clash-verge-rev, usually under ~/.local/share.

The verge.yaml, config.yaml, profiles.yaml, and profiles/ entries in the directory are essential for restoring settings, subscriptions, and the Profile. logs/, service-logs/, cache.db, and Geo data can also help with comparison, but do not save only the logs and omit the configuration.

Store the backup outside the app's working directory and label it with the system, architecture, original version, and time. verge.yaml may store a WebDAV address, username, and password in plain text, while the Profile may contain a subscription token, node password, and UUID. Do not upload the raw backup to a public cloud drive or attach it directly to an Issue.

The v2.5.4 release notes confirm only that portable mode is removed and the system app data directory is used consistently. They do not promise to discover every third-party portable package or custom directory automatically. Do not delete the old files first, and do not extract the new program directly into the old program directory expecting it to read the old configuration automatically.

While the old version still opens, record the current Profile name, subscription source, overrides and scripts, system proxy, TUN, service mode, and ports. Then back up both the data directory beside the old program and the official system app data directory. After installing the RC, let it create and use the new system data directory before restoring through the app's import or backup-recovery entry point.

If manual restoration is the only option, close the new version, preserve a copy of the directory it just created, and then copy the complete backed-up configuration set in one operation. Do not select only profiles.yaml, copy only profiles/, or mix old and new verge.yaml files; references and current selections across these files may fall out of sync.

The official Clash Verge Rev documentation says the project currently publishes only through GitHub Release. To test v2.5.4-rc, open the official Release for that RC, confirm that the page is marked Pre-release and targets commit c7ffb212, record the publication time and asset filename, and then choose the asset for your system and architecture.

Standard Windows devices usually use x64; ARM Windows uses arm64. Consider the larger build with fix_webview2 in its filename only when WebView2 is missing and cannot be installed, or when the normal package cannot open the interface. On macOS, distinguish Apple silicon from Intel. On Linux, match both the distribution package format and CPU architecture.

Before installing, save the asset filename and download time. Do not use a third-party portable build, download a similarly named installer from a search ad, or mix the resource directories of the stable version and RC. If you have only one production environment, prepare the official v2.5.2 installer and a complete data backup before starting the test installation.

The v2.5.4 Release leads with an important warning: in service mode, rule-set and proxy-set files in the configuration directory are only cached copies, so editing them manually does not affect the running core. Files you maintain yourself should use type: file in the configuration instead of editing service-generated caches.

This AutoBuild also adds multi-user isolation in service mode and migration for upgrades from the old service, and fixes continuing errors or abnormal state after an operation times out. After upgrading, confirm the service installation status and current user in the interface, then inspect the app logs and service-logs. The continued presence of an old cache does not prove that the new core loaded a manual edit.

If the original configuration relies on manually edited provider caches, restore the backup first and convert the rule sets or proxy sets you actually maintain into explicit local file providers. Migrate only one file at a time, then reload and verify it through connection records or rule matches. Do not perform the service migration, provider migration, and subscription update simultaneously.

After restoring the Profile, turn off TUN and enable only the system proxy. Complete one real HTTPS request through the same node, then confirm its target, rule, and outbound in Connections. Next, turn off the system proxy and confirm that the operating system's proxy state is restored in sync. This step validates the system-proxy state and restoration fixes from the release notes.

Only after the system proxy is stable should you install or upgrade the service and enable TUN. On Windows, if the original problem occurred only with the system or mixed stack, retest with the same node and target. Do not change gVisor, DNS, ports, and overrides at the same time. On macOS and Linux, focus on confirming that authorization, bypass rules, and service logs no longer show the old permission error.

v2.5.4 adds the Mips stack option for TUN, and the Release explicitly requires Mihomo v1.19.31 or later. If you do not have that core version or a specific test objective, do not switch stacks merely because the option is new.

A version number and a working interface prove only that installation completed, not that migration succeeded. Restart the system and Clash Verge Rev once, then use the same Profile, node, and HTTPS target saved before the upgrade to validate app startup, system proxy, service mode, and TUN in order.

Also verify that the system app data directory actually saved the new changes and that the Profile, selected node, overrides, and ports do not revert after restart. When using a local rule set or proxy set with type: file, confirm that the runtime configuration references the source file rather than a service cache copy.

During testing, do not delete the old portable directory, the v2.5.2 installer, or the pre-upgrade backup. Complete at least one restart and one direct-connectivity recovery after disabling the proxy before deciding whether to keep using the RC.

If the RC will not start, configuration migration is incomplete, or the system proxy or TUN develops a new regression, disable TUN and the system proxy first, exit the app completely, and confirm that the operating system has recovered direct connectivity. Do not keep updating subscriptions or repeatedly overwrite the data directory while the system is in an abnormal state.

After saving a copy of the v2.5.4 failure state, restore the program with the official v2.5.2 installer and restore the complete pre-upgrade data backup as one unit. Do not replace only the executable while continuing to use configuration files partially rewritten by the new version, and do not combine old and new resource files.

After rolling back, confirm the version and Profile first, then validate the system proxy, service mode, and TUN in that order. If the old portable version was stable, you can temporarily restore the old program and data directory, but keep them separate from the system data directory while waiting for clear migration guidance in a later stable release.

As of 9/17/2026, v2.5.4-rc and AutoBuild were both pre-releases, while v2.5.2 remained the Latest stable version. Going forward, rely on the project's official Release page to see whether a new stable version is published and whether it retains the portable-mode removal and data-directory guidance. Do not infer a stable release date from a pre-release version number.

When a stable release arrives, repeat the same migration validation: make a complete backup, confirm the system data directory, restore the Profile, test the system proxy first, test service mode and TUN next, and validate rollback last. A successful AutoBuild test does not replace validation of the stable release.

If you need to report an issue, provide the system, architecture, installation channel, old and new versions, old data directory and new system directory, first relevant log entry, and minimal reproduction steps. Before posting publicly, remove the subscription token, node credentials, WebDAV details, accessed domains, and complete local paths.