Clash for Windows Discontinued: Alternatives and Migration Steps

Why you should stop using Clash for Windows

Clash for Windows (CFW) was once the most common GUI client on Windows, built on the original Clash core. That core stopped being maintained in 2023, and CFW's updates stalled along with it — most downloadable builds today are stuck on an old core branch, without protocol compatibility fixes or support for newer rule syntax.

Sticking with an old CFW build causes real problems: some newer subscription protocols (with custom transport-layer parameters) can't be parsed correctly; newer rule syntax such as RULE-SET remote rule groups or process-name matching may be ignored or throw errors on the old core; and TUN mode driver compatibility on newer OS builds has gone unpatched. These issues might not surface right away, but as subscription providers update their config formats, an outdated client falls further and further behind.

The actively maintained alternatives on Windows today are all built around the mihomo core — a community-maintained fork that continued development on top of the original Clash core, adding protocol support and fixing a long list of legacy issues. It's the shared engine behind all three clients recommended below.

Three alternative clients compared

Migrating isn't just "install whatever works" — clients differ meaningfully in interface logic, rule-editing style, and resource usage. Here's a quick rundown based on hands-on testing; check the download page for current version numbers and core parameters.

Clash Plus

Clean interface with a low learning curve — subscription management and node switching are both simplified, which suits users who don't want to fuss with config files. Rule editing happens through a visual panel, so most day-to-day adjustments don't require hand-writing YAML, though deep customization is more limited. Good fit for CFW users moving over who don't plan on digging into config syntax.

Clash Verge Rev

One of the most actively developed options, built on the mihomo core with a stable rule engine. It supports both a visual editor and direct config-file editing, so you get a GUI without losing hands-on control of your config. The Windows/macOS/Linux experience is consistent across all three, making it one of the smoothest migration paths from CFW.

FlClash

Broader cross-platform coverage, with a consistent desktop and mobile experience and a lighter-weight interface style — good for users who want the same workflow across multiple devices. Rule editing is also visual, and core updates keep pace steadily.

All three are open source, free, and run on the mihomo core, so protocol compatibility risk is low from a migration standpoint — the real differences come down to workflow and how configs are managed. Pick based on whether you need to hand-write rules or not.

Migration steps: moving subscriptions, rules, and settings

The real work in migrating isn't installing new software — it's carrying over the subscription URLs, custom rules, and habits you've built up in the old client. Follow the order below and you should get it done in one pass.

Step 1: Save your subscription links as-is

Open CFW's subscription manager and copy the full URL for each subscription somewhere safe (a text file works fine). Subscription URLs are client-agnostic — the new client just needs to re-import these links. Don't try to migrate CFW's local cache files directly; it's not necessary and not recommended.

Step 2: Record custom rules and policy groups

If you've added extra rules manually in CFW (say, pointing a specific domain to a particular proxy policy, or blocking certain ad domains), these usually live in an override layer or a local rules file. Screenshot or copy that text before migrating, then re-enter it manually in the new client rather than expecting the config file to load directly across clients — different clients extend config fields in slightly different ways, so reusing the raw file risks field conflicts.

Step 3: Install the new client and import subscriptions

1. Download the installer for your platform from the download page and follow the setup wizard.
2. Open the subscription manager, paste in the saved subscription URLs, and fetch them.
3. Once the node list loads, run a connectivity test to confirm latency data comes back normally.
4. Re-enter the custom rules you recorded earlier into the new client's rule editor.
5. Check the proxy mode (Rule / Global / Direct) and the TUN mode toggle against your previous setup.

Step 4: Verify the system proxy and startup settings

After installing the new client, you'll need to re-set the system proxy toggle and launch-at-startup option — these are system-level settings that don't carry over automatically. Keep CFW installed alongside the new client for a day or two while you confirm everything is stable before uninstalling the old version, to avoid a gap in coverage.

Common migration pitfalls and how to troubleshoot them

The issues that come up most often in real migrations fall into a handful of categories — knowing them ahead of time saves a lot of troubleshooting time.

• Node list is empty after importing a subscription: Likely the subscription URL carries a parameter tag specific to the old client. Try stripping any extra trailing parameters and re-importing, or check with your subscription provider about whether the link format has changed.
• Custom rules don't take effect after migration: Check whether the rule-matching syntax lines up with the new client's rule engine — things like domain-matching order or case sensitivity in process-name matching can vary slightly between clients.
• No internet after enabling TUN mode: The first time a new client enables TUN mode, it usually needs extra system permission (admin rights or a virtual network adapter driver). Follow the client's prompts and grant each permission — don't skip that step.
• Two clients fighting over the system proxy port: Turn off CFW's system proxy toggle before uninstalling it. Otherwise the old and new clients will compete for the same port, causing intermittent connection drops that look like a network problem but are really a port conflict.
• Latency data disappears after a rule-set refresh: Some clients briefly clear latency test results while refreshing rule sets. Just wait for the automatic re-test to finish — no need to restart the client.

Overall, migrating from CFW to a mihomo-based client boils down to three tasks: moving subscriptions, re-entering rules, and re-authorizing system-level settings. Protocol compatibility itself isn't a real obstacle. Spend half an hour working through the steps and the switch should go smoothly, with ongoing access to core and rule-syntax updates going forward.