On this page
Before managing multiple Clash Verge Rev configurations, distinguish remote subscriptions, local files, and overrides
If work, everyday, test, and backup subscriptions are all named Profile 1 or Profile 2, after a week it becomes difficult to know which one can be deleted. A name should include at least its source or purpose plus a recognizable environment, such as “Work | Corporate Rules,” “Daily | Primary Subscription,” or “Test | Local Override.” Never put the full subscription domain, account, or token in the name.
First distinguish three things: a remote Profile updates from a URL; a local Profile reads only a disk file; Merge, Script, or an override modifies the final configuration while loading. A working remote subscription does not prove the override works, and switching Profile does not necessarily disable a global override.
Three configuration types serve different purposes
| Type | What belongs here | Update method | Most common misconception |
|---|---|---|---|
| Remote Profile | Nodes, policy groups, and rules supplied by the provider | Fetch manually or on a schedule from the URL | Assuming a successful update means it is already active |
| Local Profile | Fixed tests, offline rollback, or a complete configuration you wrote | Manual editing and backup | Assuming it refreshes automatically like a subscription |
| Merge / Script / override | A small set of long-term custom rules and fields | Applied as the client loads | Assuming it affects only one Profile |
Keep one known-good configuration with no overrides
Before enabling automatic updates, choose the most stable remote subscription, update it manually, and load it directly without extra Merge or Script. Pin a working node and confirm that the browser, common apps, internal domains, and DNS all work.
Keep this unmodified Profile instead of creating many similarly named copies. If an override later reports group not found, switch back to it to determine whether the raw subscription still works. If it also fails, inspect download, parsing, or provider-side changes.
This raw configuration should meet these conditions
- It just updated successfully and has a clear update time
- Policy groups and nodes are not empty
- It does not depend on temporary scripts or online conversion sites
- At least one fixed node has passed a real access test
- Windows networking recovers after the client exits
- The subscription URL is backed up securely
Set update intervals according to actual change frequency; shorter is not automatically more reliable
A subscription normally needs fetching only when nodes, quota information, or rules change. An overly short interval increases server requests, battery use, and failure notifications, and may replace the current configuration with a temporarily invalid response in the middle of your work. Start everyday subscriptions on a conservative schedule, and shorten only rapidly changing test sources separately.
When adjusting automatic updates in Clash Verge Rev Profile details or subscription settings, verify the unit and next run time first. Options may vary by version or import method, so do not copy numbers from someone else's screenshot. The most important things are retaining a manual update action and seeing the last success time and failure reason.
- Primary everyday subscription
- Prioritize stability and follow the provider's update frequency; there is no need to fetch every few minutes.
- Work configuration
- Consider meetings, remote connections, and fixed outbound routes before updating; avoid switching during work.
- Test subscription
- It can update more often, but should not be the startup default or overwrite the verified primary configuration.
- Local Profile
- Disable remote automatic updates; control edits through version history and manual validation.
Update first and inspect the result before deciding whether to switch
“Update successful” in the Profile list means only that the remote request and parsing did not fail immediately; it does not prove the nodes work. After manually refreshing one entry, inspect its update time, node count, policy-group names, and quota message for unexpected changes before making it current.
If an update changes dozens of nodes to zero, policy groups suddenly disappear, or the body is actually a sign-in page, do not switch to it. Keep the previously running configuration and inspect the HTTP status and parsing log. Automatic updates should follow the same rule: on failure, keep the last usable cache instead of treating the error response as a new configuration.
One controlled update
Record the pre-update state
Record the Profile name, current update time, and critical policy groups.
Update only this entry
Do not click “Update All” yet; avoid changing several sources at once.
Read the result
Check download status, parsing errors, and whether nodes and policy groups are complete.
Switch and pin a node
Use the connections screen to verify rules and outbound routes for frequently used domains.
Keep a rollback
Do not delete the previous working configuration until the real task is complete.
Use overrides only for small, stable requirements; do not make them repair every subscription
If a global Merge references fixed group names such as “PROXY” or “Node Selection,” that group may not exist after switching to another provider, producing proxy group not found. Keep overrides small and reference only fields and group names present in every Profile.
When sources have very different group names and structures, maintain separate overrides for them; do not force one script to handle everything.
Inspect the final generated YAML after changing an override. The raw Profile may have no duplicate keys while the merged result does; DNS, rules, and proxy-groups may also be replaced as entire blocks.
Disable every override and confirm that the raw subscription loads, then enable them one by one. This identifies the failing item more easily than reading several errors at once.
Update succeeds, but switching reports group not found
Common cause:The override references a group name absent from this Profile
Resolution:Disable the override and compare it with the actual group names in the final configuration.
DNS remains identical after switching between Profiles
Common cause:A global Merge overrides each subscription's dns
Resolution:Confirm that this is intentional; otherwise, narrow the override scope.
Manual edits disappear after every update
Common cause:The remote subscription cache was edited directly
Resolution:Move persistent changes into a durable override or a separate local Profile.
Back up subscriptions, overrides, and local configurations—not just a Profile name
A backup that can restore a multi-configuration workflow has at least four parts: remote subscription addresses, local YAML you maintain, Merge or Script files, and a small set of settings such as client version, ports, and current Profile. Put subscription addresses in a password manager; store local configurations and overrides in an encrypted archive; record versions and settings on a separate reference page.
Do not copy the entire Clash Verge Rev cache directory. It may contain stale subscriptions, runtime state, and an old core; overwriting a new installation restores those problems too. For rollback, import a recently verified local snapshot first and confirm it loads without overwriting the primary Profile.
A true backup configuration should come from an independent, trusted source. If primary and backup both depend on the same service and conversion chain and update at the same time, they fail together and provide no rollback. Local snapshots contain node credentials, so backups must be encrypted and have a retention period.
One recoverable backup
- Store remote subscription URL values in a password manager
- Encrypt local YAML and Merge/Script files
- Record Clash Verge Rev and Mihomo versions
- Record mixed-port, the current Profile, and required toggles
- Perform one recovery test in a test Profile
The final check covers a full cycle, not one successful open
Stable multi-Profile management
- Each name reveals the source or purpose without a sensitive token
- The primary configuration has an identifiable last successful update time
- The last usable content remains when an automatic update fails
- Rules, DNS, and the current node actually change after switching Profile
- A failed override can return to the unprocessed raw configuration in one action
- The backup configuration does not depend on the same online converter or update source
- The current Profile and automatic update schedule remain correct after restarting the client
You can validate the workflow during one ordinary work session: start the client, confirm the current Profile, manually update the primary configuration, complete a real task, switch to the backup and back, then exit and verify system-proxy recovery. Multiple Profiles become useful only when every step is understandable and reversible; otherwise, they merely copy the same uncertainty several times.