What to Do After Clash for Windows Was Discontinued: Migrate Your Config and Choose an Alternative

What to Migrate After CFW Was Discontinued

Clash for Windows, or CFW, is a desktop client for managing configurations, proxies, and system proxy settings. It is not the Clash core itself. CFW is no longer maintained, and 0.20.39 is commonly cited as its final release. An old installation may still launch, but that does not mean it will receive compatibility fixes or that its outdated core can recognize protocols and fields used by newer subscriptions.

You don’t need to rewrite your entire configuration at once. Migrate your subscription and rules first, restore the system proxy next, then handle TUN, DNS, and startup settings. This makes it easier to pinpoint problems. You usually don’t need to buy your subscription again just because you’re switching clients; check whether your provider offers a configuration the new core can read.

Know Which Settings Belong to Which Layer

Subscription content: Proxies, proxy groups, rules, and some DNS settings, usually generated from a remote subscription.
Local changes: Manually added rules, subscription preprocessors, scripts, and overrides that need to be documented separately.
Client settings: System proxy toggles, service installation, startup behavior, and interface preferences. Copying a YAML file won’t restore all of these.

Back Up Subscription URLs, Custom Rules, and Local Config

Record the Configuration You’re Using

In the old CFW client, open Profiles and confirm which configuration is selected. Note its name, subscription source, and whether it updated successfully the last time you tried.
Open General and note the actual proxy port, current mode, and whether System Proxy and TUN Mode are enabled. The common HTTP proxy port is 7890, but use the value shown on your machine.
Find the active configuration directory and copy it to a local backup folder. A common location on Windows is %USERPROFILE%\.config\clash, but portable installations and custom setups may use a different path. Don’t assume the default applies.
Save copies of any YAML files, rule files, subscription preprocessing configs, and scripts you edited. Note which files you changed manually and which are generated by subscription updates.

The configuration directory may contain client settings, subscription caches, and runtime files for the core. A full backup is useful for reference, but don’t copy the entire directory over to the new client: different projects use different config indexes, databases, and file names.

Keep Both the Subscription URL and a Config Snapshot

The subscription URL lets you fetch future updates, while the current YAML helps you verify proxies and rules. If you only keep a config snapshot, you may be able to connect after importing it but won’t receive future changes from your provider. If you only save the subscription URL, you may lose local rules and routing preferences.

Tokens in subscription URLs often appear in the query string or path. When asking for help, share only the error and the fields needed to diagnose it—never post the full URL. If the full URL has been exposed, reset the subscription token in your provider’s dashboard and update the new client.

Choosing a Replacement: Start with Your Platform, Then Check the Core

When evaluating alternatives, check recent project releases, system architecture, and core type. The client version and core version are separate. To verify whether a field is supported, check the version of the core that’s actually running—not just the version shown in the client interface.

Use case	Clients to consider	Migration checklist
Windows desktop	Clash Verge Rev、Clash Nyanpasu	Check maintenance status, mihomo core version, and permissions for service mode.
macOS desktop	Clash Verge Rev、ClashX Meta	Choose the right build for Apple Silicon or Intel, then reauthorize network traffic controls.
Linux desktop	Clash Verge Rev	Choose a DEB or RPM package for your distribution and check desktop proxy settings.
Core only, running in the background	mihomo	Manage config paths, service startup, and controller access yourself.

These names are starting points for your search, not guarantees of future maintenance. Before installing, check the download page for currently available platforms and official project sources. To compare management features, see the client comparison. Don’t mistake an old repackaged CFW build with a similar name for an updated release of the original project.

If you relied on CFW Parsers or scripts to process subscriptions, check whether the new client offers an equivalent override mechanism. Being able to import Clash YAML doesn’t mean it supports CFW interface settings or every preprocessing syntax.

Migrate Subscriptions and Rules: Start with a Basic Working Connection

Import the Subscription First; Leave TUN Off

In the old client, turn off System Proxy and TUN Mode, then quit the client. Also disable its startup option.
Install the new client and import the original subscription URL from its subscription or config management page. Menu labels vary by version; look for options such as “Import” or “Subscriptions.”
Wait for the update to finish. Check that the number of proxies and the proxy groups look as expected, then set this config as the active one.
Switch to Rule mode, manually select a known working proxy, enable system proxy only, and test the connection in a browser.

If the import fails, check the logs first. A 401 or 403 usually means you need to check authorization or provider restrictions. If you get a web page instead of YAML, make sure you copied the subscription URL, not another link. If the client reports an unsupported field or protocol, check the core version and subscription format rather than deleting all your rules and hoping for the best.

Put Local Rules in a Stable Override Layer

Rules are usually matched from top to bottom, so earlier matches take priority. These three lines show the order only: match specific domains first, then private network addresses, and use a fallback rule last. DIRECT is the built-in direct-connection policy. If you use a proxy group name instead, it must already exist in your config.

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

Don’t import this example as a complete replacement for your subscription, and don’t add a second top-level field with the same name under the existing rules section. During migration, use the new client’s rule merging or override feature to insert your rules in the right place while keeping the subscription’s original fallback policy.

Check Your Old Config for mihomo Compatibility

Clash.Meta continued development under the name mihomo. Many basic Clash YAML fields are still supported, but don’t assume that CFW-specific features map directly to settings with the same name. Keep core structures such as proxies, proxy-groups, and rules, then check support for extensions one by one.

Legacy scripts and preprocessing: Don’t assume CFW Parsers, JavaScript processing workflows, or script modes from old cores will work unchanged in the new client. Check which component provides each feature, then adapt it to the new implementation.
Rule file paths: Relative paths in rule-providers depend on the new config directory. After copying local rule files, verify their paths and read permissions.
Proxy group references: Group names referenced by rules must match exactly, including spaces and capitalization. A missing group can prevent the config from loading or keep rules from working as intended.
Controller access: Unless you need remote management, bind external-controller to a loopback address. Don’t reuse old settings that listen on every network interface without an access key.
DNS settings: Record the original behavior before changing fake-ip, upstream resolvers, or domain policies. Changing both the core and DNS setup at once makes troubleshooting harder.

If you run the standalone mihomo core, use mihomo -t -f config.yaml to validate a specific config. When running it, use the actual file path. For a graphical client, check its config validation results and core logs first. Passing validation only means the config can be loaded; it doesn’t prove that the subscription URL, rule sources, or every proxy can connect successfully.

Troubleshooting System Proxy, TUN, and Port Conflicts

Browser Works, but Other Apps Don’t

System proxy settings affect apps that honor them; they don’t guarantee that every program will use the proxy. First check whether the app has its own proxy setting. If you need to route traffic from apps that ignore system proxy settings, enable TUN as described by the new client and configure its service or administrator permissions.

The service installed by the old CFW client won’t automatically carry over to the new one. If the new client reports insufficient permissions, use its own service installation option. Don’t copy the old service files, and don’t let two proxy clients create virtual network adapters and routes at the same time.

Port Already in Use or No Connection After Quitting

If the new client logs address already in use, first check whether the old process is still running in the background. On Windows, run the command below in a terminal to find the process ID listening on 7890, then check the application name in Task Manager.

netstat -ano | findstr :7890

Don’t end a process until you know what it’s for. You can also choose an unused port for the new client, but remember to update browser extensions, terminal environment variables, and other manual proxy settings too. In particular, check whether HTTP_PROXY, HTTPS_PROXY, and ALL_PROXY still point to the old port.

If your browser keeps trying to connect to a local proxy after you quit the client, open Settings → Network & internet → Proxy in Windows 11 and check “Use a proxy server.” Turn it off only if you’re sure no organization policy or other software needs it. If you still have connection issues after disabling TUN, check for other VPNs, virtual network adapters, and DNS settings.

Verify the Migration and Keep a Rollback Option

A latency result alone doesn’t prove the migration is complete. Latency tests cover specific requests and can’t confirm that all traffic is routed through the right policy. Use this checklist to test the setup before deciding whether to uninstall the old client.

Subscription updates: Manual updates succeed, and proxies and custom rules are still present.
Rule matching: Visit one destination that should connect directly and another that should use a proxy. Check the matching rule and actual policy in the connection log.
Everyday apps: Test a browser, a terminal, and a desktop app you use regularly—not just the browser.
Local network access: Confirm that you can still reach your router’s admin page, printer, or NAS as before.
Restart and resume: Restart your computer and test waking it from sleep. Confirm that startup, service permissions, and proxy status are all correct.

For subscription update or proxy connection issues, see subscription update troubleshooting and the latency test guide. The key to migration is to handle subscriptions, rules, and network traffic controls separately, then verify each layer as you go. Don’t overwrite the entire old directory.