How to Migrate After Clash for Windows Was Discontinued: Alternatives Like Verge Rev and FlClash, Plus a Step-by-Step Configuration Migration

Compare replacement clients for discontinued software, including interfaces, cores, and platform support, then follow steps to migrate subscriptions and local configurations safely.

Migration After Discontinuation: Handle the Client, Core, and Configuration Separately

Clash for Windows, commonly known as CFW, was discontinued in November 2023. Older installations may still launch, but the original project will no longer fix issues caused by future operating system changes, dependency problems, or protocol compatibility. The goal of migration isn't to recreate the old interface in a new client. It's to retain your subscription source, nodes, proxy groups, and routing intent, then set up system proxy and traffic routing again.

Start by separating three layers: CFW is a graphical client; Clash, Clash Premium, Clash Meta, and mihomo are core-related projects; YAML is the configuration format for proxies, rules, and runtime options. Clash Meta continued development under the name mihomo. Installing a mihomo-based client doesn't mean every setting from the old CFW interface will be migrated automatically.

Record These Six Things Before You Migrate

  • The name of the active profile, and whether it comes from a subscription URL or a local YAML file.
  • The actual HTTP, SOCKS, or mixed port number, such as 7890; don't assume the default is in use.
  • Whether the mode is Rule, Global, or Direct, and which node is selected in each proxy group.
  • Whether System Proxy, TUN, startup on boot, and background services are enabled.
  • Whether you use Parsers, custom rules, DNS changes, or other configuration processing.
  • Whether any browsers, terminals, or development tools have a proxy address configured separately.

Replacement Client Comparison: Verge Rev, FlClash, and Nyanpasu

Choose based on your operating system and configuration needs first, then consider the interface. The platforms below are those generally offered by each project. Check the release notes for the specific download for minimum OS versions, CPU architectures, and core versions. “Supports Windows” doesn't mean it runs on every legacy Windows release.

Client Platforms Core Migration notes
Clash Verge Rev Windows、macOS、Linux Based on mihomo Well suited to managing desktop subscriptions; recreate overrides, services, and system proxy settings
FlClash Windows、macOS、Linux、Android Based on mihomo Works across desktop platforms and Android; traffic routing works differently on each platform
Clash Nyanpasu Windows、macOS、Linux Manages Clash-family cores; available options vary by version Check which core is actually enabled; the client name alone doesn't tell you which syntax is supported

Choose Based on How You Use It

  • Primarily manage configurations on desktop: Consider Clash Verge Rev first. Check whether its subscription updates, overrides, and log access fit your existing workflow.
  • Use both a computer and Android: Consider FlClash, but don't apply the Windows service-mode steps to Android. Android typically routes traffic through the system VPN permission.
  • Need to inspect or switch cores: Consider Clash Nyanpasu. Before importing, confirm the selected core and its version, then check whether it supports your subscription fields.

Although CFW has “Windows” in its name, historical releases also covered other desktop platforms. You don't have to limit your search to products with similar names. Whether a configuration loads depends on the target core, the subscription output format, and how the client handles overrides—not on whether its interface looks like CFW.

Back Up Your Subscription and Local YAML: Keep Both the Source and a Working Copy

A subscription URL and a snapshot of the current configuration serve different purposes. The URL lets you update later; the YAML snapshot preserves the nodes and custom content currently in use. Saving only the URL won't recover hand-edited rules that were later overwritten. Saving only the YAML may mean losing automatic updates.

  1. In CFW, check the active configuration on the Profiles page. For a remote profile, save the original subscription URL; for a local profile, keep a copy of the original file. Don't guess where it came from based on its display name.
  2. Use the client's configuration-directory shortcut to find the actual data directory. If you used a portable installation, its location may depend on where the app is installed, so don't check only your user folder.
  3. Copy the configuration directory to a separate backup folder. Also save the subscription URLs, configuration names, and which URL belongs to which configuration.
  4. Save your Parsers content, hand-written rules, and local resource files. If the YAML references relative paths, back up the referenced files as well.
  5. Note the ports, mode, and proxy group selections at the time of backup. Screenshots of the relevant settings can help, but they don't replace the YAML or subscription URL.

Check Provider References and Relative Paths

proxy-providers and rule-providers in a configuration may depend on remote URLs or local path values. Copying the main YAML doesn't copy all its dependencies. If the new client uses a different data directory, the same relative path may point somewhere else. Check paths against the target client's working directory.

Import and Switch Over: Start with Rule Mode, Then Enable System Proxy

For your first migration, route regular app traffic only and leave TUN off for now. This lets you verify the configuration separately from system routing. Throughout the process, let only one client manage the system proxy so two background processes don't keep changing the same settings.

  1. Stop the old client from routing traffic. In CFW, turn off the system proxy under General → System Proxy. If TUN is enabled, turn that off too. Then quit CFW and make sure it doesn't relaunch at startup.
  2. Install the replacement client. Choose your operating system and architecture from the client downloads page. On first launch, confirm the core works before setting up extras such as service mode.
  3. Import one configuration. For a remote profile, use the original subscription URL; for a local profile, use the saved YAML. Depending on the client, the import option may be called “Configuration” or “Subscription.” Use the interface in your installed version as a guide.
  4. Activate the imported configuration. Seeing it in the list doesn't mean the core is using it. Check which configuration is active and review the load log for YAML parsing errors or unsupported fields.
  5. Select Rule mode. Open the relevant proxy group and manually select an available node first. A matching proxy group name doesn't mean the previous selection has been retained.
  6. Check the listening port. Confirm the port the new client actually uses, then enable the system proxy. If your browser has a proxy extension, disable its routing or set it to follow the system proxy.

Port Change Example: 7890 to 17890

If the old client used 127.0.0.1:7890 and the new one uses 127.0.0.1:17890, update any terminal variables and tool settings that still point to the old address. This is a partial mihomo settings example, not a complete subscription with nodes and rules. Apply it through a settings or override method supported by your client.

mixed-port: 17890
allow-lan: false
mode: rule
log-level: info
tun:
  enable: false

mixed-port accepts both HTTP and SOCKS proxy connections. It's not the same as the core's controller port, which is for management and shouldn't be entered as an HTTP proxy in your browser. If an app explicitly uses a separate SOCKS listening port, check that against the new configuration too.

Rules, Overrides, and TUN: Settings You Can't Simply Copy Over

Recreate CFW Parsers in the New Client

Parsers are CFW's configuration-processing mechanism, not a generic top-level field in mihomo YAML. Pasting the original Parsers content into a subscription file won't reproduce its behavior. First list what it actually does—for example, adding direct rules for the local network, changing DNS, or adding proxy groups. Then recreate each change using the target client's supported configuration merge or script override features.

Save the original subscription before applying custom changes. Editing a downloaded remote YAML directly means your changes may be overwritten at the next update. To verify your setup, note one custom rule, update the subscription, then check whether the rule is still present in the running configuration and in the right position.

Check Rule Order and Group Names Together

  • Rules are generally evaluated in order, and the first matching rule determines the policy. Put exceptions that should take priority before catch-all rules.
  • MATCH is a common catch-all rule. Check which policy group it actually points to; the mere presence of nodes in the file isn't enough.
  • Proxy group names referenced by rules must exactly match their definitions, including capitalization, spaces, and symbols. If you rename a proxy group, update its references too.
  • If your subscription offers both Clash and Clash Meta output, check which compatible format the provider recommends for mihomo. Don't import another format just by changing its filename to .yaml.

Enable TUN and DNS Separately, as the Final Step

TUN creates a virtual network interface and may change how routing and DNS are handled. It's not a “stronger global mode”: rules can still apply after TUN takes over traffic. First confirm that the regular system proxy works, then enable the required service or grant permissions as specified by the client, and only then turn on TUN.

If internal network names, a corporate VPN, or access to local devices stop working after you enable it, check route exclusions, DNS policies, and whether another VPN is interfering. fake-ip is a DNS mode; don't migrate that toggle alone and overlook its related filters and rules. Don't enable TUN in two clients at once to compare speeds—it makes the source of any problem much harder to identify.

Verify the Migration: Test Configuration Loading, Proxy Connections, and Updates Separately

A node latency reading only shows that a test target responded under specific conditions. It doesn't prove that your browser, terminal, and rules are all working. These commands use Windows PowerShell and assume the new client's mixed port is 17890; change the commands if you're using a different port.

1. Check the Local Port and Explicit Proxy

Get-NetTCPConnection -State Listen -LocalPort 17890
curl.exe --proxy http://127.0.0.1:17890 --connect-timeout 10 --max-time 20 -I https://example.com/

The first command checks whether a process is listening on the port. Use OwningProcess in the output to identify the process. The second command explicitly uses an HTTP proxy, with a 10-second connection timeout and a 20-second overall limit. Using curl.exe avoids differences caused by command aliases in some PowerShell environments.

An HTTP response means the request completed, but doesn't prove it went through a proxy node: in Rule mode, it may have matched DIRECT. Also check the client's connection log to verify the matched rule, policy group, and final route. If the explicit proxy works but your browser doesn't, check the system proxy, browser extensions, and proxy bypass list first.

2. Check Environment Variables and System Settings

Get-ChildItem Env:*proxy*
netsh winhttp show proxy

The first command can reveal proxy environment variables still pointing to the old port. The second shows only WinHTTP proxy settings; it doesn't show the full status of the Windows user-level system proxy. On Windows 11, also go to Settings → Network & internet → Proxy and check the current manual proxy address and port. Whether a terminal tool uses the system proxy depends on the tool itself—you can't infer it just from the client's proxy switch.

3. Verify Updates and Restart Behavior

  • Manually update the subscription once and confirm the node list still loads and custom rules are intact.
  • Visit one destination that should connect directly and another that should use the proxy, then verify the policies in the connection log.
  • Quit and relaunch the new client. Confirm the active configuration, mode, and proxy group selections are as expected.
  • If you need TUN, enable it separately, then test your local network, DNS, and everyday apps.
  • Restart the system and confirm only the new client launches automatically, while the old client no longer changes the port or system proxy.

Common Migration Problems and How to Roll Back

The subscription imports, but the node list is empty. What should I check first?

Start with the subscription request and configuration load logs. The URL may return a login page, an error message, or an incompatible format instead of valid YAML. You may also be using a proxy-provider whose download failed or which isn't referenced by a proxy group's use field. First check that the original subscription still works, then verify that the target core supports its format. Don't keep toggling the system proxy to mask a configuration problem.

The new client says the port is in use. Can I change it?

Yes, but first identify the process using it. If it's old CFW or a leftover background service, quit the client normally or stop the relevant service. If you do need to switch to another port, such as 17890, update the browser's manual proxy, terminal variables, and development tool settings too. Don't terminate system processes unless you know what they're for.

How do I restore the old configuration if migration fails?

First turn off the new client's system proxy and TUN, then quit the new client. Next, start the old client and restore its configuration from your backup. Rolling back is a short-term recovery measure; it doesn't change the fact that the old project is discontinued. If you're no longer using a proxy for now, also clear manual proxy settings and environment variables that point to a closed port, or apps may keep failing to connect.

Migration is complete when the original subscription can update, local changes are preserved, rule matches are explainable, and traffic is routed as expected after a system restart. Once you've verified all of this, remove the old client's startup entry and services, and keep a secure backup. For configuration fields, see the protocol reference. For system proxy issues, troubleshoot by symptom in the Help Center.

Download Clients