How to Migrate from Clash for Windows: Move Subscriptions, Parser Overrides, and Settings

Identify the four types of data to migrate

Now that Clash for Windows (CFW) is no longer maintained, migration is less about copying the entire old application folder and more about handling your subscription source, configuration logic, proxy settings, and Windows integration separately. This guide focuses on moving to Clash Verge Rev. You can follow the same checklist with other mihomo-based clients, but don’t assume their menus, script entry points, or data directories match.

The client and the core are separate software layers. The interface handles subscription downloads, startup, and the system proxy toggle; the mihomo core reads the final configuration, listens on ports, and routes traffic. A configuration file for the old client’s interface is not necessarily a YAML file the new core can read.

Choosing an alternative client

• Want to keep desktop subscription management and an override workflow? Start by evaluating Clash Verge Rev. Check the current release’s documentation for scripts, merged configurations, and Service Mode.
• Prefer a consistent experience across devices? Compare clients such as FlClash, but don’t assume its override scripts are compatible with CFW Parsers.
• Only need standard subscriptions and rule-based routing? Start by importing a subscription, choosing a proxy group, and setting up the system proxy. There’s no need to enable TUN just to migrate.

See client comparisons for download links. Before installing, check your Windows architecture and the release notes. After installation, note the client and core versions on the About page. If something goes wrong, those details are more useful than simply saying you’re on the “latest version.”

Back up the old configuration and keep a way to roll back

Keep CFW working until you’ve made a backup. Data for a typical installation is under .config/clash in your user directory, but portable mode and custom launch arguments can change the location. Use the old client’s configuration-directory shortcut to find the actual folder; don’t rely only on paths posted online.

1. Save the original subscription URL and note its name, last update time, and update interval. These URLs often contain credentials, so store them only in a trusted local location.
2. Back up local YAML files, Parser content, and related scripts. Record the purpose of each transformation—for example, “add development sites to a specific proxy group”—not just the code.
3. Note the current mode, selected proxy group, HTTP/SOCKS ports, whether LAN access is allowed, and any custom TUN or DNS settings.
4. Note startup behavior, Service Mode, and system proxy status. Take screenshots, then exit the old client so you don’t miss settings that haven’t been written to disk yet.
5. Copy the backup to a separate folder. Don’t point the new client at the old client’s data directory, and don’t uninstall the old application before testing the new one.

Before testing the new client, turn off the CFW system proxy and auto-start, and make sure its core process has exited. Even with different ports, two clients can take turns changing the Windows system proxy. Running two TUN instances at once can also make routing and DNS behavior hard to diagnose.

Import the original subscription first, then inspect the generated configuration

In Clash Verge Rev, open the Subscription page, use the import option, paste the original subscription URL, and select the imported profile. Button labels may vary by release—for example, “Import” or “New”—so follow the version you have installed. Don’t add the old scripts yet; first confirm that the new client can download the subscription and that mihomo accepts it.

Don’t confuse these three types of URL

• Subscription URL: Returns nodes or a full configuration, usually includes a token, and can be used as an update source.
• Provider account page: Opens a sign-in page. Pasting it into the subscription field commonly results in an HTML parsing error.
• Locally exported YAML: Useful for offline troubleshooting, but usually won’t restore the original subscription’s update link.

After importing, check that nodes, proxy groups, and rules are present. A different node count doesn’t necessarily mean anything is missing; the response may depend on subscription parameters, the User-Agent, or the provider’s template. Compare the raw response before changing request headers, and never give a subscription URL containing credentials to an unknown online converter.

Verify three layers

1. Download: The subscription updates successfully and returns something other than a login page, expiry notice, or empty response.
2. Configuration: The core starts successfully, with no errors for unknown fields, missing proxy group references, or invalid YAML types.
3. Connectivity: Select a working node and test with a real request. A successful latency test only shows that its test endpoint is reachable; it doesn’t replace testing browser access and routing.

If the original subscription relies on CFW Parsers, first determine whether they perform format conversion or add rules. You can recreate ordinary rule additions in the next step. If the response format itself isn’t suitable for mihomo, ask the provider for a compatible format instead of trying to fix it by copying the old directory.

Migrating Parsers: keep the logic, not the old syntax

CFW Parsers can match subscription URLs and then modify YAML or run JavaScript. Clash Verge Rev’s merged configurations and script configurations have their own calling conventions and scope. Don’t paste outer structures such as parsers, reg, or yaml from old code into the final configuration as if they were standard mihomo fields.

First sort the old logic into three groups: add or remove rules, change top-level fields such as DNS, and rewrite nodes or proxy groups. Migrate one group at a time, then inspect the final or running configuration provided by the client before moving on. For exact field details, see rule syntax and DNS configuration.

Example: Add a GitHub domain to an existing proxy group

This example is for a Clash Verge Rev JavaScript script configuration that uses the function main(config) entry point; it is not a complete replacement for a CFW Parser file. It assumes the subscription already has a proxy group named “Proxy Select.” Check the exact name before using it; capitalization and spaces must match.

function main(config) {
  const groups = Array.isArray(config["proxy-groups"])
    ? config["proxy-groups"]
    : [];

  if (!groups.some(group => group.name === "Proxy Select")) {
    throw new Error("Proxy group not found: Proxy Select");
  }

  if (!Array.isArray(config.rules)) {
    throw new Error("The current configuration is missing the rules list");
  }

  const customRule = "DOMAIN-SUFFIX,github.com,Proxy Select";
  config.rules = [
    customRule,
    ...config.rules.filter(rule => rule !== customRule)
  ];

  return config;
}

This script puts the rule first and avoids adding an exact duplicate. It applies only to github.com and its subdomains; other domains used by GitHub aren’t included automatically. Preserve the intended match scope when migrating rather than expanding an example into an unverified set of rules for the entire site.

Rule order and merge behavior matter

• Rules are usually evaluated in order: A custom rule placed after the final fallback MATCH rule usually won’t run.
• Arrays aren’t always appended automatically: Some merge mechanisms replace the entire rules array. After making changes, check that the original subscription rules are still there.
• Subscription-level and global overrides have different scopes: Bind proxy group rules that apply to only one subscription to that subscription, so switching profiles won’t leave references to groups that don’t exist.
• Every update regenerates the configuration: Direct edits to cached or generated files can disappear after an update. Put changes in an override mechanism the client supports for persistent configuration.

Set up the system proxy and ports again, and make sure only one core is listening

Don’t assume the new port is 7890 just because it was used in the old interface. The examples below use 127.0.0.1:7890 as a mixed proxy port; use the value shown in your new client. mihomo’s mixed-port accepts both HTTP and SOCKS proxy requests on the same port. Separate HTTP and SOCKS listeners may use different ports.

Check the listener before enabling the system proxy

Run the following command in PowerShell to check which process is listening on the example port. If the new client reports that the port is in use, identify the application by its process ID; don’t terminate an unfamiliar system process.

Get-NetTCPConnection -State Listen -LocalPort 7890 |
  Select-Object LocalAddress, LocalPort, OwningProcess

Get-Process -Name "*clash*", "*mihomo*" -ErrorAction SilentlyContinue |
  Select-Object Id, ProcessName, Path

Once the listener is working, enable System Proxy in the new client. In Windows 11, check the manual proxy address under Settings → Network & internet → Proxy. In Windows 10, go to Settings → Network & Internet → Proxy. The port should match the new client’s HTTP or mixed port.

If you’re only using the proxy on this PC, you usually don’t need to allow LAN connections. Don’t change the listening address to all network interfaces just to clear a connection error, and don’t expose the controller API to your LAN. The controller API address and secret are separate settings, not the system proxy port.

Isolate issues with an explicit proxy request

curl.exe --proxy http://127.0.0.1:7890 --head --max-time 15 https://example.com/
curl.exe --proxy socks5h://127.0.0.1:7890 --head --max-time 15 https://example.com/

The examples use a 15-second timeout and explicitly specify the proxy, so they don’t depend on whether the browser reads system settings. In the second command, socks5h lets the proxy resolve the destination hostname. An HTTP response means this test path is working, but you should still check the Connections panel to confirm the matched rule, proxy group, and outbound node.

If the browser works but the terminal doesn’t, check the terminal’s environment variables and the application’s own settings. HTTP_PROXY, HTTPS_PROXY, and ALL_PROXY may still point to the old port. WinHTTP proxy settings are also managed separately from the Windows user-level system proxy. Don’t assume that toggling the system proxy migrates every application.

Set up TUN and DNS after basic connectivity works

Once the system proxy test passes, decide whether you need TUN. TUN uses a virtual network adapter and routing to capture traffic, including traffic from some apps that don’t follow the system proxy. It doesn’t guarantee that all traffic will go through a remote proxy; the final route still depends on rules, route exclusions, and direct-connection policies.

1. Turn off TUN in the old client first and make sure its old core and service won’t restart automatically.
2. Install or enable Service Mode by following the documentation for your new client’s current version. The old CFW service can’t be reused as the new client’s service.
3. Keep the new client’s generated TUN defaults at first. Don’t also bring over old virtual adapter settings, DNS hijacking rules, or custom routes.
4. After enabling TUN, test regular websites, LAN devices, and waking the PC from sleep. Test your corporate VPN and other virtual adapters separately so you can pinpoint any conflicts.

Check DNS settings separately, including enhanced-mode, fake-ip-filter, upstream resolvers, and client-generated overrides. The old configuration’s use of fake-ip doesn’t mean you should copy every old DNS field unchanged; check support against your current mihomo version. If you use rule-based DNS, also check how domain rules relate to the DNS request path.

If only corporate intranet domains fail after enabling TUN, check corporate DNS and routing requirements first. If only LAN addresses fail, check routes and direct-connection rules. Don’t start by sending the entire private network range through a remote node. Turning off TUN and retesting with the system proxy is an effective way to distinguish subscription issues from virtual adapter issues.

Verify updates, troubleshoot issues, and remove the old client

Don’t consider migration complete just because a webpage opens. At a minimum, manually update the subscription, restart the client, and verify that it starts automatically after you sign in to Windows. Custom rules that survive an update are a good sign that the override is using a persistent mechanism.

Migration checklist

• The subscription updates manually, and nodes and proxy groups look as expected.
• Custom rules match correctly, and every referenced proxy group exists.
• After a normal exit and restart, the old application no longer changes the system proxy port.
• Test each browser, terminal, or other app that needs the proxy.
• If TUN is enabled, test LAN access, DNS, waking from sleep, and other VPNs separately.
• Save the original subscription URL, override scripts, and settings notes in a separate backup.

Once these checks pass, uninstall the old client and use its own management tools to remove any services you no longer need. To roll back temporarily, turn off the new client’s system proxy and TUN, exit its core, and then start the old client. Don’t let both applications manage network traffic at the same time. For everyday setup after migration, see the connectivity testing guide; for subscription maintenance, see how to import a subscription.