Clash for Windows Alternatives in 2026: How to Migrate After Discontinuation

What happened to CFW

If you only want the short answer, here it is: by 2026, Clash for Windows is no longer a sensible primary client. The lowest-risk replacement for most Windows users is Clash Verge Rev; users who want to move beyond the Clash format should look at V2RayN; Mac users should usually go straight to ClashX.

Clash for Windows effectively ended in November 2023. The last public version was 0.20.39, released on November 3, 2023. After that, developer Fndroid deleted the GitHub repository without a clear public explanation. For regular users, that removed the official release channel, the issue tracker, and any normal path for future updates all at once.

This did not happen in isolation. The same broader wave of pressure around the Clash ecosystem also hit the original Clash Verge project, which is why the community later regrouped around actively maintained branches such as Clash Verge Rev. You can still find archived CFW packages in community forks such as github.com/clashdownload/Clash_for_Windows, but that only answers the question of availability, not long-term trustworthiness.

Is Clash for Windows still safe?

The honest answer is no, not as a long-term daily client. That does not mean every existing install becomes instantly dangerous overnight, but its security margin keeps shrinking. The clearest reason is the front end: CFW depends on Electron, and Electron needs ongoing browser and runtime security updates. Once the shell stops moving, the gap only gets worse.

The second problem is component drift. A proxy client is more than a pretty interface. It relies on a core engine, networking behavior, rule parsing, certificate handling, and system proxy integration. When those pieces stop evolving, you gradually lose compatibility with newer protocols, newer operating systems, and newer security expectations.

The third problem is distribution trust. Because the official repository is gone, many users now depend on third-party mirrors, shared archives, or forum reposts. The most practical risk there is not feature loss. It is supply-chain risk: you cannot easily verify whether the installer was modified, repackaged, or signed by someone else.

So the practical recommendation is simple: keep CFW only for short emergency use, such as exporting a subscription or checking an old rule setup, then migrate as soon as possible. It should not be your main client in 2026.

What to back up before migrating

Most failed migrations are not caused by the new client. They happen because users do not collect the full old config first. Your subscriptions, groups, and custom rules may have grown over months or years, so a clean backup is what makes the switch painless.

1. Export the subscription URL first: open the Profiles tab in CFW and copy the subscription URL you are actually using. This matters most because it is what lets you rebuild your node list quickly in the next client.
2. Back up profiles/list.yml: this file usually stores the subscription list and related metadata. Even if you copied the URL already, keep the file too so you have a second reference point.
3. Back up local YAML files: if you maintain any local configs, save every custom YAML file before you install anything else. That includes files you edited only once for provider compatibility.
4. Record custom rules and proxy groups: pay special attention to rule-providers, rules, and proxy-groups. Many users assume the subscription URL is enough, then discover that the routing logic changed because those pieces never made it over.
5. Take a quick screenshot set: capture your current mode, TUN status, ports, and the names of your most-used groups. Even if the migration is supposed to be direct, those screenshots make validation much faster.

If you are migrating for another person, package all of this before you touch the new install. A complete backup is what gives you a clean rollback path if anything behaves differently.

Alternative 1: Clash Verge Rev (Recommended)

For most former CFW users, Clash Verge Rev is the most natural replacement. Its stable release is v2.4.6 as of February 2026, it has about 102k GitHub stars, it uses mihomo v1.19.19 underneath, and its desktop shell is built on Tauri instead of Electron. In plain language, that means a lighter client with quicker startup and a smaller always-on footprint.

The bigger advantage is migration continuity. Clash Verge Rev does not force you to abandon the Clash workflow that made CFW familiar in the first place. You can usually paste in the same subscription URL, or import the same YAML file directly, and keep moving. For many users, that makes the migration feel less like a rebuild and more like a controlled handoff.

• Pros: familiar Clash-style UI, active development, lower resource usage, and support for Windows, macOS, and Linux.
• Migration path: reuse the same Clash subscription or import your YAML directly.
• Best for: users who want the lowest-risk move away from CFW without changing formats right away.
• Trade-off: it still lives in the Clash config ecosystem, so future format shifts may still require another transition later.

If you ask which client to install first after CFW, Clash Verge Rev is the default answer because it offers the smoothest bridge from an abandoned client to a maintained one.

Alternative 2: V2RayN

If you do not care about staying inside the Clash format, V2RayN is the stronger long-term protocol toolbox. The current mainstream version is v7.18.0, it has about 98.6k GitHub stars, and it supports Xray, sing-box, and mihomo cores. That gives it broad coverage across VMess, VLESS, Trojan, Shadowsocks, and Hysteria2.

The real reason to choose V2RayN is not that it looks like CFW. It does not. The reason is flexibility. More providers now prioritize VLESS, Reality, Hysteria2, or other stacks where a pure Clash-only workflow becomes limiting. If that is already true for your setup, it can be smarter to change both client and protocol expectations in one move.

The trade-off is that the migration feels less like a direct handoff. You will be learning a broader tool, not simply replacing a shell. If your goal is "move today with minimal friction," Clash Verge Rev is easier. If your goal is "future-proof my protocol options," V2RayN may be the better investment. For more detail, see our V2RayN guide.

• Pros: broad protocol coverage and more flexibility across provider setups.
• Cons: the workflow is less familiar to CFW users, so the learning curve is higher.
• Best for: users who want VMess, VLESS, Trojan, Hysteria2, and multi-core flexibility.

Alternative 3: ClashX for Mac users

If you used CFW in the past but your real daily machine is now a Mac, the cleanest replacement is often not another Windows-first community client. It is ClashX. ClashX is the native macOS Clash client, and it keeps the same general subscription model that many CFW users already know.

That native design matters. Instead of carrying a cross-platform shell onto macOS, ClashX fits the platform more naturally with menu bar integration, system proxy behavior, and a lighter feel in daily use. For Mac users who mainly want a stable, long-term home for existing Clash subscriptions, that usually matters more than chasing every possible experimental feature.

If your provider still offers Clash-format subscriptions, you can usually move over with the same URL or local YAML and keep working. If that sounds like your situation, start from our download page and treat ClashX as the natural continuation of your setup on macOS.

• Pros: native macOS experience, continued Clash-format support, and a clean migration path for Mac users.
• Cons: it is not the main path for Windows users.
• Best for: Mac users who want to leave CFW behind without leaving the Clash format behind.

Alternative 4: Clash Nyanpasu

Clash Nyanpasu is another community-driven option worth watching. The project lives at github.com/LibNyanpasu/clash-nyanpasu, supports Windows, macOS, and Linux, and has an active development pace.

Its positioning is slightly different from Clash Verge Rev. Verge Rev feels like the safer migration lane for users who want continuity. Nyanpasu feels more experimental, more community-driven, and a bit more open to rapid change. That can be a strength if you like new features early, but it is not always the first recommendation for conservative migrations.

• Pros: active community energy, fast iteration, and broad platform support.
• Cons: more experimental personality, so cautious users may prefer Verge Rev first.
• Best for: people who enjoy following fast-moving community development.

Comparison table

If you want a fast filter before reading every section, use this table. The most important variable is not which project is the most popular. It is which one best matches your current format, your operating system, and the workflow you already understand.

For the standard CFW user with a Clash-format subscription, the fastest safe answer from this table is still Clash Verge Rev first, then V2RayN later only if you outgrow the Clash format.

Step-by-step migration to Clash Verge Rev

This is the path most former CFW users should take first. The goal is not to install a shiny new client as fast as possible. The goal is to lock down the old working state, then move with the fewest new variables.

Step 1: Freeze the current CFW setup

Before you install anything, confirm that your current CFW setup still works, then write down the active mode, the subscription name, and the proxy groups you use most. That gives you a working baseline for comparison later.

Step 2: Export the subscription and back up local YAML

Copy the subscription URL from the Profiles tab, then archive profiles/list.yml and every local YAML file you have touched. If you ever edited rules by hand, double-check that the backup includes your group names and provider sections too.

Step 3: Install Clash Verge Rev and import the same config

After installation, import the same subscription URL first. If you are a local-config user, import the YAML directly instead. At this stage, focus on the basics: node list, proxy groups, and mode switching should all appear correctly before you do anything else.

Step 4: Compare rules, DNS, TUN, and system proxy behavior

This is where most hidden differences appear. Match your groups, rule providers, DNS settings, TUN state, ports, and system proxy toggles against the old CFW setup. If those pieces line up, most routing differences disappear before they become support headaches.

Step 5: Test real sites, then remove CFW

Test the sites and apps you use most: direct mainland routes, streaming, dashboards, and any apps that depend on TUN. Once the new client stays stable for a couple of days, remove CFW. Keeping it briefly as a rollback reference is fine, but it should not continue as a parallel daily client.

FAQ

Learn more about CFW

If you want the background and basics of CFW, read our Clash for Windows overview page. If you are already committed to migrating, it also helps to review our proxy client comparison and tutorial section so you can tell the difference between client behavior and provider-side config issues.

One final reminder: keeping CFW as your main tool is not a neutral choice anymore. The earlier you move to an actively maintained client, the less time you will spend debugging a dead stack.