Migrate from Clash for Windows to Clash Verge Rev: Move Subscriptions, Rules, and Shortcuts

What to migrate: handle client settings and core config separately

Clash for Windows (CFW) is no longer maintained. Moving to Clash Verge Rev involves more than switching windows: the interface, config management, and background services all change, and you’ll need to review the core that parses subscriptions, matches rules, and establishes connections. Clash Verge Rev uses mihomo, so don’t copy the entire CFW user directory over and expect every setting to work as before.

Before migrating, note the version, ports, and operating mode shown under CFW’s “General,” along with the selected config name under “Profiles.” If your old setup uses CFW 0.20.39, that identifies the client version; it doesn’t tell you which protocols your subscription uses or whether every field is compatible with the current mihomo version. Check the installed client and core versions separately in the new app and its startup logs.

Step 1: Back up your subscription, rules, and local settings

Save the source files, not just the current list of nodes

In CFW, open “Profiles” and note the remote subscription URL in use. If the menu offers a copy URL or edit option, retrieve it there; for a local profile, copy the YAML file. Subscription URLs often contain access tokens, so keep them in a restricted folder on your device. Don’t upload them to a public repository or share screenshots that expose the token in public forums.

The user directory is often %USERPROFILE%\.config\clash, but portable mode and custom settings can use a different location. Use the “Home Directory” option under CFW’s “General” to find the actual path. Quit the client, then copy the whole directory and preserve the original filenames. During migration, extract what you need from this copy; don’t use it as the new client’s data directory.

• Subscription source: Save the remote URL, update interval, profile name, and whether the setup depends on local files.
• Rule changes: Find manually added rules, rule-providers, and custom policy groups.
• Preprocessing logic: Back up Parsers and scripts with their match conditions, and note exactly what each one changes.
• Local settings: Record the HTTP, SOCKS, or mixed port; LAN access setting; proxy bypass list; and TUN status.
• Interface settings: Note the rule mode, current policy group selections, shortcuts, and launch-at-startup option.

Keep the original subscription separate from the final runtime config

The original subscription may contain only nodes and policy groups, while the final runtime config can also include ports, DNS, TUN settings, and script output injected by the client. Saving only the original subscription can lose custom rules; saving only the final config can carry old machine paths and ports into the new setup. Keep both, labeled by purpose in their filenames—it’s more reliable than keeping a screenshot of the interface.

The final config may also contain proxy passwords and controller secrets. Restrict access to backups, and share only the relevant fields when troubleshooting. Don’t hand your subscription URL to an unknown converter website just to inspect a remote profile.

Step 2: Import your subscription and check mihomo config compatibility

1. Choose a Clash Verge Rev installer for your system and architecture on the client download page. After installation, leave the system proxy and TUN disabled.
2. In the new client’s “Subscriptions” page, import the original subscription URL or use the local file option to add a YAML file. Button labels can vary between versions; follow what the interface shows.
3. Select the new profile and check config validation and the core logs. Fix parsing errors before troubleshooting connectivity.
4. On the “Proxies” page, confirm that the policy groups and nodes appear. Select a known working node, then enable Rule mode.

mihomo can read many Clash-style configs, but “parses successfully” doesn’t mean “behaves exactly the same.” Check protocol parameters, rule-set formats, and client-specific extensions in the old subscription. In particular, script: routing in an old config is not CFW Parser JavaScript, and you shouldn’t assume it will run unchanged on mihomo. Rewrite it using rules or logical rules supported by the current core, as documented.

Fix the reported issue instead of deleting unknown fields in bulk

• Policy not found: Check that the policy group referenced by the last rule exists, and verify its name, spacing, and capitalization.
• Rule set failed to load: Check the rule-providers URL or local path, format, and behavior. Don’t import a rule-set file as if it were a complete subscription.
• Node parameter error: Check the protocol type and required fields. Some providers offer separate Clash and mihomo subscriptions; choose the output that matches your core.
• Invalid file path: Relative paths in the old config are resolved from the new runtime environment. Don’t assume they still point to the old directory.

To test YAML directly, run config validation with the same mihomo version as the client. The Windows PowerShell example below assumes the core file and test config are in the current directory. Passing validation only means the config can load; it doesn’t prove that remote nodes are reachable.

.\mihomo.exe -t -f .\migration-test.yaml

Step 3: Rebuild rule overrides so subscription updates don’t erase them

Don’t put long-term custom rules directly into the remote subscription cache; the next update may overwrite them. Keep “remote nodes and policy groups” separate from “local settings you maintain.” Let subscription updates manage the former, and use Clash Verge Rev’s merge config or scripting features for the latter. Make sure the override is linked to the active profile.

Move static rules first, then scripts

CFW Parsers describe a client-side preprocessing workflow, not a general-purpose core config. Pasting a Parser file with its match conditions and processing steps into the new client’s merge editor usually won’t produce the same result. First list what each piece of logic is meant to do—for example, “route a domain directly,” “remove expired nodes,” or “add a filter to a policy group”—then recreate each behavior with static rules, a merge, or a script.

These two snippets are for local overrides, not complete subscriptions. example.com is a documentation example domain; replace it with the domain you actually need. They use the built-in DIRECT policy, so they don’t depend on policy group names in your subscription.

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve

For dynamic behavior, check the script entry point

If the script editor in your version uses the main(config) entry point, you can prepend a rule as shown below. If the editor provides a different template, follow that template instead. The script must return a config object. Use this code only in the script editor; don’t import it as YAML.

function main(config) {
  const localRule = "DOMAIN-SUFFIX,example.com,DIRECT";
  const existingRules = Array.isArray(config.rules) ? config.rules : [];
  config.rules = [
    localRule,
    ...existingRules.filter((rule) => rule !== localRule)
  ];
  return config;
}

The script preserves the relative order of existing rules and prevents the example rule from being duplicated. In a real setup, also check for broader rules placed before it, dependencies on rule providers, and whether a later merge step will overwrite the result. During migration, enable one override at a time and inspect the final config before moving on. That makes troubleshooting much easier.

Step 4: Switch the system proxy and reset ports and shortcuts

Stop the old core before handing over to the new client

1. In CFW’s “General” settings, turn off “System Proxy.” If TUN is enabled, turn that off too, then quit CFW from the system tray.
2. Check Task Manager to confirm the old core process has exited. If a port is still in use, identify the process first; don’t terminate an unfamiliar system process.
3. In Clash Verge Rev’s “Settings,” check the ports and system proxy options. Depending on the version, these may be under port, system, or advanced settings.
4. Enable the new client’s system proxy, reopen a test app, and check the “Connections” page to see whether its requests reach the core.

For example, an older app may be manually configured to connect to 127.0.0.1:7890, while the new client listens on 7897. Switching the system proxy won’t automatically change that app’s port. You can keep the old port in the new client or update the manual proxy settings in browser extensions, terminal environment variables, and developer tools. 7890 and 7897 are troubleshooting examples, not guaranteed default values for any version.

netstat -ano | findstr ":7890"
netstat -ano | findstr ":7897"

In the output, lines marked LISTENING identify listening processes; the last column is the PID. Look up that PID under “Details” in Task Manager. A controller port serves a different purpose from a proxy port: for example, don’t use external-controller from the config as a browser HTTP proxy.

Recreate shortcuts and startup settings manually

• Launch at startup: Once the new setup works, turn off auto-start in the old client to prevent it from taking over the system proxy again after login.
• Shortcuts: Reassign actions such as showing the window or toggling the system proxy, and check for conflicts with your input method or other apps.
• Proxy bypass: Review LAN hostnames, loopback addresses, and company network requirements. Don’t copy the entire old list without checking it.
• LAN sharing: Enable it only if other devices need to connect, and check the firewall scope. LAN access isn’t needed for a migration on the same device.

Step 5: Move TUN and DNS last, then test connectivity layer by layer

Test the system proxy before enabling TUN. The system proxy works with apps that follow proxy settings; TUN uses a virtual network adapter and routes to capture traffic, so it covers a different set of traffic. If you change the core, rules, DNS, and TUN all at once, it’s hard to tell which layer caused a problem.

In the new client’s “Settings,” install or enable the required service and grant administrator access when prompted. Then turn on “TUN Mode.” Don’t copy service directories or virtual adapter files from the old client. During migration, avoid letting another VPN or old TUN service take over the default route at the same time.

DNS Setup: Check what actually takes effect

If the old setup used fake-ip, first check dns.enable, dns.enhanced-mode, and the filtering lists in the new runtime config. Seeing these fields in the subscription alone doesn’t guarantee that the client will use them unchanged. Interface settings, global overrides, and the subscription can all contribute to the generated runtime config.

For mihomo TUN, dns-hijack can capture matching conventional DNS traffic, but it doesn’t automatically capture encrypted DNS built into a browser. Check browser “Secure DNS,” encrypted DNS in the operating system, and DNS behavior from other VPNs separately. If you still see stale DNS results after making changes, close the affected apps and try again. On Windows, ipconfig /flushdns clears only the system DNS cache—not every app or core cache.

Common migration issues and how to roll back

Subscription imports, but websites won’t load in the browser

First check whether the core is running, then verify the address and port used by the system proxy. If the “Connections” page shows no requests at all, check whether the app follows the system proxy or still has a manual proxy set to the old port before switching nodes. If connections do appear, use the matched rule, policy group selection, and error logs to investigate the exit.

Node tests show latency, but browsing still fails

A latency test only shows that a specific test target responded at that moment; it doesn’t prove that every site, UDP, or DNS is working. Test one destination that should go direct and another that should use the proxy, then compare their matched rules and exits. Don’t treat a single latency reading as a complete migration test.

Rules disappear after a subscription update

Check whether your changes were written into the remote config cache or whether the override is linked to a different subscription. Review the merge order and make sure later arrays aren’t replacing your custom rules, and that the rules aren’t placed after MATCH. Rules are matched from top to bottom, so their position directly affects the result.

How to temporarily roll back to CFW

1. Turn off the system proxy and TUN in the new client, then quit it.
2. Confirm the new core has stopped and its ports are no longer in use. Don’t keep switching the system proxy back and forth between the two clients.
3. Start the preserved old setup, restore its original config and traffic handling, and save the specific logs from the failed new setup.
4. Use those logs to fix the new config, then repeat the switch in the same order.

Rollback is a short-term troubleshooting measure; it doesn’t change the fact that the old client is no longer maintained. After testing subscription updates, rule matches, DNS, intranet access, and recovery after a restart, remove the old startup entries and background services. For the basics of system proxy and TUN settings, see the Getting Started guide. For mihomo field definitions, consult the protocol reference rather than inferring core behavior from interface labels.