On this page
Moving to a new client involves more than copying a folder. Existing subscriptions and custom rules are worth keeping, while caches, service state, and interface habits may not transfer directly. Restore only part of the functionality at a time and check that direct access still works after exiting, so you have a clear recovery path if something goes wrong.
Which Configuration Should You Keep for Migration?
With Clash for Windows no longer maintained, organize the subscription sources, local configurations, custom rules or Mixin, usual policy choices, and port settings you need before moving to Clash Verge Rev. Do not copy window state, caches, old cores, service files, and past logs as a bundle, which could carry existing problems into the new client.
Open the old client and capture or record each item in a local document: the active Profile name and update time, ports under General, whether System Proxy, TUN, and Allow LAN are enabled, and whether the Profiles screen contains a local Mixin. A subscription link contains a personal token; store it only in a password manager or encrypted backup, never in a screenshot.
Migration checklist
- A subscription address that still updates
- Local YAML that cannot be downloaded again
- Rules and override logic you maintain yourself
- mixed-port or local-network sharing port
- Policy-group selections you genuinely need to preserve
- Old client and core versions for troubleshooting comparisons
Exit the Old Client and Confirm Direct Windows Access
The greatest migration risk is having two clients capture the system proxy or TUN at the same time. In Clash for Windows, disable System Proxy, TUN, and startup, then quit completely from the tray. Next, open “Settings → Network & Internet → Proxy” and confirm that “Use a proxy server” no longer points to an old port on 127.0.0.1.
With both clients closed, open an ordinary website and confirm that the corporate intranet or router admin page still works. Only when this state is healthy can you attribute later problems to the new client.
If the network is already broken, clean up stale proxy or TUN state; do not temporarily hide the problem by opening Clash Verge Rev.
Install, Import the Subscription, and Reselect Policy Groups
Typical Windows 11 computers use an x64 installer; only Windows on ARM devices should choose arm64. Before installing, verify the release repository, filename, and release notes. Do not use a third-party “portable enhanced edition” that bundles the client, subscriptions, and nodes.
Do not enable service mode and TUN immediately on first launch. Add the original subscription again from the subscription or configuration screen, update it manually, and confirm that the update time, proxy groups, and nodes appear. Then choose one fixed node and enable the system proxy. This first proves that downloading, parsing, and basic forwarding all work in three steps.
Policy-group definitions usually live in the subscription YAML and appear when it is reimported. However, the currently selected node for each Selector in Clash for Windows is runtime state and should not be migrated by copying caches.
Open the Clash Verge Rev proxy screen, inspect common groups such as “Node Selection,” “Auto Select,” and “Streaming” one by one, and manually restore the required outbound route.
If the same subscription has fewer policy groups in the new client, compare the subscription update time and final configuration first. Provider updates, old Parsers, or a new Merge can all change group names. Do not copy the entire old cache just to restore one prior selection.
First-round tests in the new client
Check the active subscription
Confirm that the newly imported Profile is selected, then check the fixed node and system-proxy requests. Test only this profile for now; do not import other historical configurations at the same time.
Quit normally
Windows should return to direct access on exit, with no stale port left behind.
Reopen Clash Verge Rev and confirm that each group’s selection is retained as expected. If it is not, record the active configuration and any group-name changes instead of trying to fix it by copying the old cache.
Rebuild Mixin and Overrides Around Their Original Purpose
Clash for Windows Mixin, Parsers, or scripts may depend on its own merge process, while Clash Verge Rev provides current Merge, Script, or override entry points. The names are similar, but generation order and fields may differ.
Before migrating each customization block, write one sentence describing its purpose, such as “connect corporate domains directly” or “put GitHub in the development group,” then rebuild it using the current client's supported method.
After adding each block, inspect the final merged configuration or runtime log. If group not found, duplicated key, or unknown field appears, remove the override you just added. Do not keep stacking the next block in hopes of repairing everything at the end.
How to handle old settings
| Old content | Migration method | Verification results |
|---|---|---|
| Custom DOMAIN-SUFFIX rule | Add it through the current rule override and ensure that the target policy group exists | The connections screen matches that rule when you visit the domain |
| Custom DNS | Keep the subscription default first, then migrate it separately | Both internal and public domains produce the expected results |
| Port settings | Configure them again under Clash Verge Rev general settings | The port is actually listening, and the system proxy points to the same value |
| UI, cache, and historical logs | Do not migrate | The new client starts from a clean state |
Restore the system proxy first; migrate TUN only if it is genuinely needed
After subscriptions, policy groups, and custom rules are stable, enable System Proxy in Clash Verge Rev. Confirm that the Windows “Proxy” page points to the current mixed-port and that the browser and common apps create connection records. The system proxy must also clear automatically when the client exits normally.
Consider TUN if games, terminals, or other apps still ignore the system proxy. Before enabling the Windows service, check the installed service component against the official security advisory; the GUI version alone is insufficient. Then test TUN, sleep/wake, and other VPNs separately, checking route recovery when TUN stops. Migrate startup and overrides separately.
Check that your everyday tasks work before uninstalling the old client
Verify continuously for at least one full work cycle
- The subscription updates manually and is used automatically at the next launch
- The browser, Git, and common work apps match the expected rules
- Internal websites, NAS devices, and printers still connect directly
- Programs that require TUN actually appear in connection records
- Windows has no residual proxy after exit and restart
- The old configuration has an offline backup, and its token has not been exposed
Keep the old installation for several days, but disable it at startup. If the new client fails, close it and restore direct Windows networking before rolling back to the backup. Do not have two clients capture traffic for a “comparison.” Once updates, everyday use, exit, and restart are all stable, uninstall Clash for Windows and verify that the old service and startup shortcuts are removed as well.