Clash Verge Rev Profiles Disappeared After Restart: Backup and Recovery

This guide addresses one specific symptom: Clash Verge Rev v2.5.2 already had subscriptions, local Profiles, or global Merge/Script settings, but after a normal exit, shutdown, or restart, reopening the app leaves only a few items in the configuration list and may reset existing overrides to blank templates.

Official issue #7577 records 30 of 32 Profile files being deleted during startup on macOS. Issue #7804 records 18 of 20 files being deleted on the next Fedora startup after a normal shutdown, with later comments also reporting Windows and macOS cases. These reports point to orphan-file cleanup during startup, not a subscription provider simultaneously removing every node.

Open the app log first and look for Removed file, Profile file cleanup complete, and an unusually high deletion count during a single startup. If the Profile still exists on disk and only the Proxies page is blank, troubleshoot core communication first. If the file exists but reports Invalid YAML, fix its formatting or fields first. If only one subscription update failed while other Profiles remain, do not immediately restore the entire app backup.

Restoring a backup rewrites the app data directory with config.yaml, verge.yaml, profiles.yaml, and the profiles directory from the archive. First copy the entire current directory and its clash-verge-rev-backup subdirectory to another location.

Keep that copy even if the current directory already looks incomplete. It lets you return to the original evidence if you choose the wrong backup or an old configuration overwrites newer changes.

A standard installation usually stores data in the io.github.clash-verge-rev.clash-verge-rev folder under the system data directory. A portable installation uses the .config directory next to the program instead. If you are unsure, use the app-directory shortcut in the client settings. Do not delete data based only on a similar folder name.

Clash Verge Rev v2.5.2 stores local backups in clash-verge-rev-backup inside the app data directory. Automatic backup filenames may include -auto-scheduled, -auto-merge, or -auto-script.

The reporter in issue #7804 recovered the global script from an auto-script ZIP created three days earlier.

The official v2.5.2 backup implementation places the profiles directory, config.yaml, verge.yaml, optional DNS configuration, and profiles.yaml in the same ZIP.

Do not restore a ZIP merely because it opens. Copy it first, confirm that the archive contains both profiles.yaml and profiles/, then choose the newest one created before the failure.

Keep the system proxy and TUN off. Open "Backup Settings" in Settings, then choose "View History" under "Local Backup." Find a backup from before the failure, use Export to save another copy first, and then select Restore and confirm. The official interface restarts the app after recovery finishes.

If the ZIP was moved elsewhere, use "Import Backup" to add the copy to the local backup list, then restore it from the history. Do not extract the ZIP directly into the directory of a running app. Built-in recovery reloads config, profiles, and interface settings after writing them; manual replacement can leave the files on disk out of sync with in-memory state.

When no usable ZIP exists, do not invent profiles.yaml references or arbitrarily rename randomly named files. Reimport each remote Profile from its saved subscription URL. For a hand-written local configuration, identify the copied profiles files from before the failure one at a time, create a new local Profile, paste in the content, and let the client regenerate the index relationship.

If an older copy of the global Merge.yaml or Script.js still exists, compare it in an offline copy first, then restore it through the client's global extension editor. Rewrite it only when no older content exists in any backup. Do not reconstruct complete rules that may contain secrets or internal domains from public screenshots.

If the subscription URL is also lost, retrieve or reset it through the original provider instead of piecing together a token from browser history, public logs, or someone else's configuration. Save the state after restoring each source so that a problem is traceable, rather than importing everything at once.

After the app restarts, do not enable TUN immediately. Check the number, names, and types of Profiles and which one is selected. Then open Merge and Script separately and confirm that critical rules are not blank templates. Remote subscriptions should update manually, and local Profiles should pass configuration validation.

Next, select one known-good node, enable only the system proxy, and complete a real HTTPS request. Confirm the domain, rule, and outbound in Connections. Finally, fully quit and reopen the app once more, then check the Profile count and logs again. Recovery is stable only if the second startup also shows no abnormal deletions.

If the app will not start after recovery, fewer Profiles remain, or the restored configuration fails validation, close the app first. Do not try several ZIP files in succession. Save a separate copy of the app data directory from this recovery attempt, then use the original preserved state to return to the pre-recovery condition.

Keep TUN and the system proxy off first. If the client still does not work after rollback, leave it closed for now. Preserve the log, backup ZIP, and directory copy, then submit the redacted version, operating system, deletion count, and first error to the official issue. Do not uninstall virtual adapters, reset the entire system network, or delete all app data to repair a configuration.

On 9/2/2026, the maintainer confirmed in issue #7804 that commit 44f6f6e removed the unreliable cleanup logic and closed the issue. The commit is titled “preserve files until explicit deletion”; its code directly removes the startup call to cleanup_orphaned_files and the entire automatic-deletion implementation.

As of 9/3/2026, the latest stable version in the official Releases is still v2.5.2, published on 7/19/2026, and its release notes do not include this later fix. Therefore, “issue closed” does not mean “fixed in v2.5.2,” and you should not move an everyday device to a development build solely to avoid this risk.

The safer approach is to complete the backup and recovery first, avoid unnecessary repeated launches, and wait for an official stable release that explicitly includes 44f6f6e. When a new stable version arrives, keep the current backup, verify the Release, and run one regression check with a full exit, restart, and real connection.

After recovery, enable scheduled local backups in Backup Settings and keep “Back up automatically on critical changes” enabled. The v2.5.2 implementation creates archives on schedule and after global Merge/Script changes, retaining up to 20 automatic archives. This limit means the local directory is not a permanent history.

Export at least one verified ZIP outside the app data directory, or configure a WebDAV service you control. Before a major subscription-override change, client migration, or upgrade, manually create and export a backup. Run recovery drills only when a rollback copy is available.