What to Use After Clash for Windows Was Discontinued: Config Migration Steps and Client Comparison

What discontinuation means, and what it doesn't

Clash for Windows (often shortened to CFW by the community) stopped receiving new releases, bug fixes, or new-core-feature support once its developer announced the project's archival. That much is a plain fact — but it's often over-interpreted as "unusable right now" or "all your config files are now worthless." Neither of those is accurate.

Let's define the actual boundary of the risk first. Discontinuation has three concrete effects: first, the core version bundled in the client is frozen at whatever it was when the project was archived, so any newer protocol type added by the upstream core later (say, an updated transport obfuscation method) or rule-syntax extension will never be supported by CFW; second, any unresolved UI glitches or connection-stability issues in the client itself will never be patched; third, after an OS upgrade (especially Windows networking-stack changes), any compatibility issue between the old client and system components has to be worked around by the user, with no official support channel to fall back on.

The parts you don't need to panic about are equally worth spelling out. First, your subscription links, rule sets, and DNS settings all live in your own config files — they don't depend on the client itself, so switching clients isn't the same as starting from scratch. Second, the mihomo (Clash Meta) core is still actively maintained, so as long as your new client bundles a reasonably recent mihomo core, protocol-support gaps or rule-matching issues you ran into before might actually get fixed as a side effect. Third, config syntax (YAML structure, proxy-group definitions, rule-matching logic) is highly compatible across mainstream clients — the real migration work isn't rewriting your config, it's correctly importing your existing file into the new client and checking a handful of field differences.

Before you migrate: back up and take inventory

Before switching clients, fully back up your existing assets. This one step avoids the vast majority of "I finished migrating and now my rules are gone" problems.

1. Locate your config file directory

   CFW config files usually live under .config\clash in your user folder, or in a profiles folder inside the client's install directory, with filenames typically being a string generated from the subscription plus a .yaml or .yml extension. Find the config files for all your subscriptions and copy them into a new temporary folder.

2. Record the original subscription links

   A config file is the result generated after a subscription is fetched — the more reliable migration approach is to regenerate the config from the subscription link rather than directly carrying over the old file. Open CFW's subscription management screen, copy the full original URL for each subscription, and save them into a separate text file.

3. Check whether you're using override scripts

   If you've added override rules or JavaScript override scripts to a subscription in CFW (to force a port change, append rules, block ad groups, etc.), this content doesn't automatically travel with the subscription link — you'll need to copy the script body separately and paste it back into the new client's config.

4. Confirm your system proxy and TUN settings

   Note down whether you're currently using system proxy mode or TUN mode, and the values of fields like mixed-port and allow-lan. These are the switches most often overlooked after migration, yet they directly affect whether you can get online at all.

Step-by-step config migration

Once your backup and inventory are done, the actual migration falls into three approaches — pick whichever matches how you actually use the client.

Approach 1: Re-import the subscription link (recommended)

Paste the original subscription URL into the new client's subscription management screen and let it fetch and generate the config on its own. The upside is that the config content stays maintained by the subscription provider — if they later update the node list or rule set, you don't need to sync anything manually. The downside is that any manual edits you made in the old client (like adjusting a proxy group's strategy) won't carry over and will need to be redone.

Approach 2: Directly import the local config file

Load the backed-up .yaml file through the new client's "import from file" feature. This preserves everything you've manually edited, but when the subscription provider pushes an update later, you'll need to decide yourself whether to overwrite your current file with the new version.

# Typical top-level structure of a Clash / mihomo config file — check whether these fields are recognized by the new client after migration
mixed-port: 7890
allow-lan: true
mode: rule
log-level: info
dns:
  enable: true
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
proxies:
  - name: "Sample Node"
    type: vmess
    server: example.com
    port: 443
proxy-groups:
  - name: "Auto Select"
    type: url-test
    proxies: ["Sample Node"]
rules:
  - DOMAIN-SUFFIX,example.com,Auto Select
  - MATCH,DIRECT

After importing, check three things in particular: first, whether the node names referenced under proxy-groups exactly match the proxies list (case and spacing differences will break matching); second, whether the policy group names referenced under rules actually exist — if the new client throws an error for an undefined group, this is usually the cause; third, the DNS block syntax, since newer cores may parse fields like nameserver-policy and fake-ip-filter more strictly than older ones.

Approach 3: Hybrid migration

Generate the base config from the subscription link first, then paste the override script body from your old config separately into the new client's override feature. This is what most long-term users actually do in practice — it lets you keep benefiting from the subscription provider's ongoing maintenance while not losing your own customizations.

Comparing the three succeeding clients

After CFW's discontinuation, a few widely recognized successor options have emerged in the community, each with a different focus. Compare them against your actual needs using the dimensions below.

All three share the same mihomo core underneath, meaning their protocol support range and core rule-syntax capabilities are identical — the real differences show up in UI interaction depth, subscription management convenience, and whether extra graphical config tools are provided. If you were used to the basic subscription-plus-rules workflow in CFW, switching to any of these three won't leave you feeling like something is missing. If you relied on some specific CFW feature (like a particular traffic-stats display style), test the new client on a small scale first to confirm it offers an equivalent capability before switching fully.

A few practical decision points

• Do you frequently edit rules by hand: if you often add or remove rules manually, prioritize a client with a graphical rule editor to reduce the risk of mistakes when hand-editing YAML.
• Do you use multiple devices: if the same config needs to move between a computer and a phone, prioritize an option with stronger config-sync capability to cut down on duplicate subscription maintenance.
• Do you care about how fast the core gets updated: all three track upstream mihomo updates, but their release cadences differ — users with an urgent need for new protocol features should watch each project's changelog frequency.

Avoiding a "second round of trouble" after migration

Switching clients isn't the end of the story. The following details are the ones most often overlooked during migration and the most likely to require rework later.

Re-confirm your subscription update interval. Different clients place the auto-update interval setting in different places. After migrating, reopen the subscription details and confirm the auto-update interval (usually measured in hours) matches your expectations, to avoid node information going stale for a long time and causing connection failures with no obvious cause.

Re-enable launch-at-startup and silent mode. This is the setting most commonly forgotten — startup settings from the old client don't carry over to the new one, so after reinstalling, you'll find the proxy doesn't start automatically on reboot and will need to re-enable it in the new client's system settings.

Test local override scripts one rule at a time. If an override script relies on CFW-specific APIs or field names, the new client may silently ignore them without raising an error. It's worth commenting out parts of the rules and restoring them incrementally to pin down exactly which section works and which doesn't.

Confirm the core version number. After migrating, check the mihomo core version currently in use in the new client. Comparing it against issues you ran into before can tell you whether a core upgrade happened to fix an old problem, or whether extra configuration is still needed.

Overall, migrating from CFW to a successor client is a one-time, manageable amount of work. The core steps are: back up your subscription links and override scripts, pick a new client built on the mihomo core, review rule and DNS fields item by item, and run through the verification checklist afterward. Follow that order and your existing habits and config logic should carry over essentially intact.