On this page
With work, everyday, and test subscriptions in one client, it is easy to confuse the configuration you just updated with the one actually running. Check its purpose before switching, verify the active nodes and rules after updating, and keep a recoverable backup of your overrides so the growing collection remains manageable.
What Do Remote Subscriptions, Local Profile Files, and Overrides Do?
Check which Profile is selected in the configuration list, then check whether overrides remain enabled. Global overrides may still apply after switching Profile, and a remote subscription loading successfully does not prove that the merged result is correct.
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 |
Name Profiles Clearly and Keep a Working Unmodified Configuration
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.
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 does not depend on temporary scripts or online conversion sites
- On 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
- Edit it manually, keep a version record, and check that the changes work; do not treat it as a subscription fetched from a remote address.
Switch the Active Profile After Checking the Update
“Update successful” only means download and parsing produced no immediate error; verify node availability with a real request.
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.
Why Do Overrides Fail After Switching Profile?
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.
If sources differ greatly in group names and structure, maintain separate overrides rather than using one script for every subscription.
After changing an override, inspect the final generated YAML. Check the actual DNS, rules, and proxy-groups values, and whether group names and rule references match the current Profile. Overrides may replace these values, so the raw subscription alone is not enough.
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.
Backup Contents and Practical Tests After Restoration
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 rely only on copying the entire Clash Verge Rev cache directory. It may contain stale subscriptions, runtime state, and an old core; overwriting a new installation can restore those problems too. For rollback, import a recently verified local snapshot first and confirm it loads without overwriting the primary Profile.
A backup configuration is best obtained from an independent, trusted source. If the main and backup configurations use the same service, go through the same conversion steps, and update automatically at the same time, a source failure can break both, leaving the backup unable to restore service. Local snapshots contain node credentials and must be encrypted and given 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
Start the client and confirm the active Profile. After a manual update, complete a real task, switch to the backup and back, then exit and check system-proxy restoration. After restarting, confirm the active configuration and automatic-update schedule remain correct.