Clash for Windows Discontinued: Best Alternatives and How to Migrate Your Config

The short answer: migrate your config, not the entire client folder

Clash for Windows (CFW) was discontinued in 2023; 0.20.39 is commonly cited as its last public release. Existing installs may still launch, but that doesn't mean the core, dependencies, or OS compatibility are still being updated. If new protocols aren't recognized or services break after an OS upgrade, consider switching clients instead of repeatedly reinstalling the same outdated package.

Windows users can compare Clash Verge Rev and Clash Nyanpasu. If you want a similar workflow on desktop and Android, FlClash is also worth considering. Check the release status of both the GUI client and its bundled core; the word Clash in a project name alone doesn't guarantee compatibility. Check package sources, supported platforms, and architectures on the client downloads page.

Choosing an alternative: check the core, config workflow, and OS integration

A GUI client manages subscriptions, tray menus, the system proxy, and service installation. The core handles proxy protocols, rule matching, DNS, and connection routing. Clash Meta continued under the name mihomo, but that doesn't mean every client called Clash uses the same core—or that scripts for the old GUI will run as-is in a newer core.

Check these three things before downloading

• OS and architecture: In Windows, go to Settings → System → About to check your system type. x64 and ARM64 are different architectures. Choose a package the project actually provides; don't infer compatibility from file size.
• Project releases: Check the official repository's Releases, recent fixes, and OS support notes. Similar names don't guarantee the same maintenance status, so verify each fork individually.
• Required features: For browser use, the system proxy may be enough. Consider TUN, service permissions, and DNS settings only if you need to route apps that ignore the system proxy.

Don't choose a client solely because it has more toggles. If your subscription already works, being able to inspect the effective config, keep local rules, and reliably restore network settings is usually more important than one extra experimental option in the UI.

Back up before migrating: save subscriptions, rules, and UI settings separately

In CFW, note the active config under Profiles and the current mode and proxy group selections under Proxies. Then open Settings and locate the actual config directory. A common default install path is %USERPROFILE%\.config\clash, but portable installs and custom paths may differ. Use the directory opened by the client as your source of truth.

1. Save your subscription details: Record the subscription URL, update interval, and provider notes. Subscription links often contain credentials, so store them in a protected local note—not in a public forum post or screenshot.
2. Back up config files: Quit CFW, then copy the config directory. Also save the current config as YAML so you can compare it section by section. An exported node list is not a substitute for the subscription URL; automatic updates still need the original source.
3. Save customizations separately: Include Parsers, Mixin, custom rules, rule-set URLs, local files, and DNS overrides. Note which items came from the subscription and which you added manually.
4. Record OS integration settings: Save the HTTP, SOCKS, or mixed ports; system proxy, startup, and service-mode settings; and whether TUN is enabled. Don't copy caches, old service executables, or the old core over the new installation.

Your backup may contain node passwords, subscription tokens, and external controller keys. Keep it secure even after migration. If any of these were exposed, rotate the credentials with the relevant provider; deleting a local screenshot isn't enough.

Move your subscription first: get the unmodified config working

First pass: import the subscription without enabling old scripts

Quit CFW and turn off its system proxy, TUN, and startup option. Open the new client and import the original subscription URL from its subscription manager. For example, Clash Verge Rev usually has an import option on the Subscription page; the label and location vary by version. After import, update it manually and confirm the config is selected and active—not just listed.

Next, check that all proxy groups are present, especially automatic selection, failover, and any custom routing groups. Node selections saved in the old client may not carry over, and matching group names don't mean the same node is selected. Manually select a known working node, then test basic access in rule mode.

Troubleshoot import errors by type

• Returns HTML or a login page: Check whether the subscription expired, whether you copied a web page URL, or whether you need to generate a new subscription link. A page loading in your browser doesn't mean the response is YAML.
• Unknown proxy type or field: Check which core is actually running and whether it supports the subscription format. Start with the Clash or mihomo subscription provided by your service; don't remove node fields just to bypass the error.
• Proxy group references a missing item: Check node names, nested group names, and the provider name referenced by use. Names must match exactly.
• Local config works, but online updates fail: Check the system clock, connectivity to the subscription server, and the network route used for update requests. Don't assume rule mode is the cause.

When migrating local YAML, pay close attention to relative paths in rule-providers and proxy-providers. Copying files to a new directory doesn't guarantee those paths will still resolve. External rule-set formats must also match the declared type and behavior.

Migrate rules and overrides against the final generated YAML

CFW Parsers are a client-side config processing feature, not mihomo core fields. Legacy scripts may use different function entry points, injection objects, and execution timing from those supported by a new client. Break the old logic into specific tasks—such as adding rules, changing DNS, or adjusting proxy groups—then rewrite it using the target client's supported config merge or scripting features.

Migrate predictable rules first; restore complex processing later

The example below shows only two LAN direct-connection rules; it is not a complete subscription and should not replace the existing rules list. If you need these rules, add them to the existing rule chain using the client's rule-prepend feature or config editor, and keep the final catch-all rule:

rules:
  - DOMAIN-SUFFIX,home.arpa,DIRECT
  - IP-CIDR,192.168.50.0/24,DIRECT,no-resolve

192.168.50.0/24 is an example subnet; replace it with your actual LAN range. Rules are usually evaluated from top to bottom, so put local exceptions before broader rules that could match first. The final MATCH rule handles everything else. If a rule targets a custom proxy group, make sure that group exists; reusing an old name doesn't make the config valid.

Migrate DNS and Fake-IP separately

Don't copy the entire old DNS config in one go. First establish a working baseline with the new client's defaults, then migrate custom DNS servers, domain policies, and Fake-IP exclusions as needed. Fake-IP maps domain names to reserved addresses; those addresses aren't real proxy nodes. If something breaks after enabling it, check the client's DNS logs and the app's behavior instead of assuming a virtual address means the config is wrong.

For apps that rely on LAN discovery, private domains, or a fixed DNS server, test name resolution and the connection route separately. After changing DNS mode, restart the affected app and test again. On Windows, you can run ipconfig /flushdns to clear the system DNS cache, but it won't clear every browser's or app's own cache.

Ports, system proxy, and TUN: verify them in three steps

Step 1: Check that the local proxy is listening

Common CFW defaults are HTTP port 7890, SOCKS port 7891, and external controller port 9090; use your old config to confirm the actual values. A new client may use different ports, such as 7897. The controller port is not a browser proxy port—don't enter it as an app's HTTP proxy.

If the new client explicitly shows 7897 as its mixed port, run these commands in PowerShell. The first checks which process is listening; the second tests the URL through an explicit proxy. You don't need to enable the system proxy first.

Get-NetTCPConnection -State Listen -LocalPort 7897
curl.exe -I --proxy http://127.0.0.1:7897 https://example.com/

An HTTP response confirms that this request received a response, not that every routing rule is correct. If the connection is refused, check that the core is running and the port matches. If the port is already in use, check whether the old client or another proxy is still running in the background; don't terminate unknown system processes blindly.

Step 2: Enable the system proxy

Once the local proxy test passes, enable the new client's system proxy. Then go to Windows Settings → Network & internet → Proxy and check the address and port. If the browser works but another app doesn't, that app may ignore the system proxy, have its own proxy settings, or face another network restriction. Check the app's settings first.

Step 3: Enable TUN only if needed

TUN routes traffic through a virtual network interface and usually involves service permissions, routes, and DNS. Once the system proxy works, install or enable service mode as prompted by the client, then turn on TUN. Test after each step so you can pinpoint issues before multiple changes to services, DNS, and routes complicate troubleshooting.

If your corporate VPN, LAN access, or virtual machine network breaks after enabling TUN, turn TUN off first to see whether things recover, then check for route conflicts and exclusions. Don't run TUN in two clients at once, and don't leave all desktop apps running as administrator just to use it.

Migration checks and rollback plan

One successful web request only proves that one route works. Complete these checks before removing the old client to help distinguish subscription, rule, and system-routing problems.

• Subscription updates: Manual update succeeds, the correct config is active, the update time is current, and local overrides survive updates.
• Rule matching: In the connection list or logs, verify at least one direct request and one proxied request, including the matched rule, proxy group, and final node.
• App coverage: Test your browser, developer tools, and any other apps that need a proxy. Don't treat a working browser as proof that the whole system works.
• Local network: Test your router's admin page, LAN services, and internal company domains—especially when using TUN.
• Restart recovery: Restart the client, then reboot the system. Confirm startup behavior, services, proxy group selection, and system proxy state are as expected.
• Exit recovery: Quit the client normally and check that the system proxy is restored. If a dead proxy address remains, turn off the manual proxy in Windows settings and investigate the client's shutdown process.

To roll back, turn off the new client's system proxy and TUN, then stop its core. Restore the old config from your backup and make sure only one client controls network traffic. Rolling back helps isolate a problem; it doesn't bring a discontinued client back into maintenance. Once the new setup is stable, uninstall the old app and remove any unused services using the old client's recommended method. Keep only the offline backups you need.

The key to a reliable migration is making each step verifiable: preserve the original subscription first, then move custom rules; confirm the local proxy port before routing system traffic. For more on rules, DNS, and TUN, see the user guide. For common install and connection issues, troubleshoot by symptom in the FAQ.