On this page
When migrating from Clash for Windows, take only the subscription and genuinely custom configuration
When migrating from the discontinued Clash for Windows to Clash Verge Rev, the only items usually worth preserving are subscription sources, local configurations, your own rules or Mixin, frequently used policy selections, and a few port preferences. Do not copy window state, cache, the old core, service files, and historical logs as a bundle; they are the items most likely to carry old 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
Before quitting the old client, make sure Windows can reach the internet without it
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 the matching architecture from the current Clash Verge Rev project releases
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.
First-round tests in the new client
Import one subscription
Do not import every historical Profile at once; otherwise, you cannot identify which configuration failed.
Update manually
Record HTTP or parsing errors. After seeing “added successfully,” still confirm that the configuration body loaded.
Pin a node
Prevent url-test from changing the outbound route during testing.
Enable the system proxy
Use a browser and one app that honors the system proxy to confirm connection records.
Quit normally
Windows should return to direct access on exit, with no stale port left behind.
Policy groups import with the configuration, but recheck the currently selected nodes in the new client
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.
Successful policy-group migration
- All frequently used policy groups appear in the new client
- Manual groups have been set back to fixed nodes
- Automatic groups can benchmark normally without frequent switching
- Connection records show the target domain matching the expected group
- Selections remain as expected after restarting Clash Verge Rev
Do not paste the entire old Mixin; first identify what problem it originally solved
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.
Only enable TUN if games, terminals, or other programs that ignore the system proxy still do not appear in connection records. Separately verify service permissions, the virtual adapter, sleep/wake, and other VPN software, and confirm that the default route recovers after disabling TUN. Do not migrate TUN, startup, and multiple overrides on the same day.
Validate with the tasks you actually perform, then remove 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.