Clash Verge Rev Config Location and Backup Guide

Distinguish an active configuration from the application data directory

A single universal answer to “Where is the Clash Verge Rev config?” is unreliable. The installed and portable modes resolve storage differently, and the operating system supplies a different base data directory. The official directory implementation places a normal installation under the platform data directory plus the application identifier. Portable mode uses a .config directory beside the executable. The safest locator is therefore the running client itself.

The data directory is not one subscription YAML. The current implementation names config.yaml, verge.yaml, and profiles.yaml, and creates separate locations for profiles, icons, logs, and backups. These elements have different roles: a composed runtime configuration, application preferences, a profile index, and the profile contents cannot replace one another. Copying only the active YAML may preserve nodes while losing profile bookkeeping or overrides; copying only an index can leave references to files that were never moved.

Also separate the application installation directory from its user-data directory. The first contains program files that can normally be reinstalled; the second contains your state. Reinstalling does not necessarily remove data, and copying the executable directory does not necessarily include that data. Label both before making a migration plan.

Open the real directory from the client and record the environment

Look in Settings, Profiles, or Help for an “Open configuration directory,” “App data directory,” or folder action. Labels move between releases, but the useful action is the one that asks the client to open its own location in the system file manager. If your build has no such action, identify its mode first: for portable mode, inspect the executable’s folder for the portable marker and .config; for installed mode, locate the application identifier under the platform data area. Do not overwrite the first similarly named folder returned by system search.

1. Record the full Clash Verge Rev and core versions.
2. Identify installed or portable mode and record the executable location.
3. Use the in-app action to open the data directory and keep the path in a private local note.
4. Check for the main configs, profiles index, profiles directory, and logs.
5. Change one non-sensitive interface preference, observe which directory’s modification time changes, and then restore the preference.

The modification-time check is a way to rule out abandoned data from a prior build. A machine may contain stable, development, portable, and manually copied directories with similar names. Do not use a subscription update as the test: it changes remote data and introduces an unrelated network variable.

Before editing or copying, record the selected profile, proxy mode, and the names of important overrides. A sanitized screenshot can help. These become recovery checks; “the program opened” by itself does not prove that all state was restored.

Create a readable backup with both built-in export and a quiet snapshot

The current official backup settings strings describe local and WebDAV backups, export, import, restore, history, scheduled backups, and backups on critical changes. If those controls exist in your installed version, create a local backup and export it outside the application-data directory. A backup stored only inside the source directory is lost with that directory.

For the filesystem snapshot, exit the application and make sure it is no longer writing files. Copy the entire active data directory into a new folder named with the version, operating system, and date. Do not move the source. After copying, compare top-level contents, open a non-sensitive YAML to confirm it is readable, and make sure cloud storage did not create placeholder-only files.

Rehearse recovery before replacing the only working data set

Install a compatible Clash Verge Rev version on the target and start it once so it creates its own directories, then exit. Never overwrite live data while the client is running. For a built-in backup, import it first and confirm that it appears in backup history before selecting Restore. The official strings state that the app restarts after a successful restore, so that restart is expected. For a raw snapshot, preserve a copy of the new empty directory before copying old data into place.

1. Verify the target clock, application version, and available storage.
2. Back up the target’s fresh state to create a rollback point.
3. Exit completely, then import one backup or copy one snapshot.
4. Check profile names, overrides, and policy groups before refreshing subscriptions.
5. Test one fixed node in rule mode and use logs to confirm the active configuration path.

If profiles are empty, inspect the backup version, file completeness, and the directory the target is actually reading. Do not repeatedly click Restore or merge folders from several dates. One identified snapshot per attempt keeps the outcome understandable.

If the application fails to start, restore the fresh target directory to prove that the installation itself works. Then import profiles and overrides in smaller steps. Keep a failed snapshot locally for diagnosis, but remove subscription URLs, server addresses, usernames, and local account paths before sharing a log excerpt.

Treat backups as credentials, especially when using WebDAV

A configuration backup is a concentrated set of sensitive data. Subscription URLs often carry unique tokens; node records may include passwords, UUIDs, and server addresses; logs may reveal domains and local paths. Sending a whole archive to an unknown helper can expose every one of those values. Share a version, exact error, and sanitized directory outline instead.

For WebDAV, choose a service you control that uses HTTPS. Create a dedicated account or application password and restrict it to one backup directory. The presence of WebDAV address, username, schedule, and history controls in the client does not make every public endpoint suitable. Upload a test backup manually and retrieve it from another location before enabling a schedule. Review server-side retention and deletion behavior too.

• At rest: protect local copies with an encrypted volume or encrypted archive.
• Retention: preserve at least one known-good older generation instead of overwriting all history.
• Cleanup: remove desktop copies, extracted temporary folders, and trash after migration is verified.
• Exposure: if a backup was made public, rotate the subscription link and any affected credentials.

Official sources and version scope

• github.com/clash-verge-rev/clash-verge-rev/blob/dev/src-tauri/src/utils/dirs.rs
• github.com/clash-verge-rev/clash-verge-rev/blob/dev/src/locales/en/settings.json