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

This article covers the prerelease version from 9/17. Official advisory GHSA-99qg-xv7m-jf4v lists Windows service versions <= 2.5.4 as affected and identifies v2.5.4+autobuild.0908.bbab52d as the fixed build. Windows users must not use the v2.5.2 service as a safe rollback option.

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.

When reviewing this RC and rolling AutoBuild, record changes to the system proxy, service mode, subscription editing, node selection, port avoidance, and TUN, as well as the removal of portable mode and migration to the system app-data directory. Test only with a full backup, the ability to verify desktop networking, and immediate recovery available; do not overwrite your only everyday setup.

If you are troubleshooting an incorrect system-proxy state, a service-mode timeout, Windows system/mixed TUN not taking over traffic, or a portable-mode migration, check the current official Release and security advisory before testing with a backup.

As of 9/17/2026, v2.5.4-rc and AutoBuild were prereleases and v2.5.2 was then the Latest stable release. That was a historical release state, not today's installation advice. A stable v2.5.5 was published on 9/22; Windows service risk must still be checked against the GHSA's patched build.

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 later added firewall rules for the core temporarily stored in %ProgramData%, and the v2.5.4-rc release notes include this fix. The Cargo.toml at that tag uses the Service IPC dependency v2.7.1. This is a backend component dependency version, not a client version to install.

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 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.

While the old version still opens, record the current Profile name, subscription source, overrides and scripts, system proxy, TUN, service mode, and ports. Keep both the data directory beside the old program and the official system application data directory.

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.

Most Windows devices use x64; Windows on ARM uses arm64. Consider the larger package with fixed_webview2 in its filename only if WebView2 is missing and cannot be installed, or 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. Avoid third-party portable repacks and installers from search ads, and do not mix stable and RC resource directories. If you have only one production environment, prepare a full data backup and a way to get online without the affected Windows service.

Exit the old version completely so that two interfaces or cores cannot modify the same data directory at once.

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.

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 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.

On Windows, test service mode and TUN only when the complete build, installation source, and actual service component have evidence of the GHSA fix. Otherwise keep the service disabled and verify only the system proxy. If the original problem affected the system or mixed stack, retest that original stack after the safety conditions are met.

Keep the same node and target during testing; do not change gVisor, DNS, ports, and overrides together. On macOS and Linux, follow the original authorization process to confirm bypass rules and service logs, which should no longer show the old permission errors.

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.

Restart the system and Clash Verge Rev, then use the same pre-upgrade Profile, node, and HTTPS target to verify startup and the system proxy. Verify Windows service mode and TUN only when the complete build and actual service both have evidence of the GHSA fix; otherwise keep them disabled. On macOS and Linux, follow the original authorization process.

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.

Do not delete the old portable directory or pre-upgrade backup during testing, and do not re-enable the affected old Windows service. Restart at least once and confirm direct connectivity after switching off the proxy before deciding whether to keep the current build.

After successful AutoBuild testing, recheck migration and network recovery under the same conditions in 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.

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 data directory as it was when the failure occurred, keep a trusted full configuration backup, but do not reinstall or enable the old <= 2.5.4 service on Windows. Restore essential connectivity using a system proxy that does not depend on that service, or another trusted client, then check the fixed builds explicitly listed in the GHSA.

After basic connectivity returns, confirm the Profile and make a real HTTPS request. Re-enable and test service mode and TUN separately only when the installation source, full build string, and actual service component all have patch evidence. If evidence is insufficient, leave them off and report the error to maintainers.