How to Migrate After Clash for Windows Was Discontinued: Replacement Clients and a Configuration Migration Checklist

Understand the Difference Between Clients, Cores, and Subscriptions

Clash for Windows, commonly called CFW, was available for Linux and macOS as well as Windows. It handled subscription management, proxy group selection, and desktop controls; the proxy core bundled with the client handled the actual connections. CFW is no longer maintained. An old installation may still launch, but that doesn’t mean it will keep up with new operating systems, protocols, or security fixes.

Migrating doesn’t mean buying a new subscription, and it doesn’t mean copying your entire old directory over the new one. Handle three separate layers: client preferences, YAML configs read by the core, and the subscription URL provided by your service. They overlap, but none is a substitute for the others.

• Client settings: Startup behavior, system proxy, keyboard shortcuts, interface preferences, and background services usually need to be configured again in the new app.
• Core config: Check that the new core supports your proxies, proxy groups, rules, DNS settings, and TUN options.
• Subscription URL: Use it to fetch remote content again. Keeping a downloaded YAML file alone won’t preserve automatic updates.

Choose a Replacement Based on Your Operating System

If you mainly used Clash YAML, choose a client that can read that config format to keep migration simpler. mihomo is the name used by the continuation of the original Clash Meta project and supports more protocols and rule features. However, available controls and the bundled core version depend on the specific client build. Before choosing, review the client comparison, then check the project’s recent release notes and installer for your operating system.

Linux Users: Check the Package Format First

Ubuntu, Debian, and related distributions typically use DEB packages; Fedora and similar systems typically use RPM. Matching the package format doesn’t guarantee that all dependencies are available. Run uname -m in a terminal: x86_64 usually indicates x64, while aarch64 usually indicates ARM64. Don’t assume a download is right for your device just because it’s available.

Don’t Copy Desktop Traffic-Capture Settings to Mobile

Android’s VpnService is a system-provided interface for routing traffic; it isn’t the same as running a service on Linux. iOS clients may also use different config formats. Support for the same proxy protocol doesn’t guarantee that a client can import Clash proxy groups and rules in full. Test the import with one config before migrating everything.

The old Clash for Android is also an archived option whose maintenance status warrants caution. Don’t choose it as a long-term replacement just because the name is familiar. The table above is a starting point, not a guarantee of future maintenance.

Back Up Your Subscription and Local Changes

Keep the old client available as a fallback for now; don’t uninstall it yet. In CFW’s Profiles page, check each config and note its name, source, selected profile, and update interval. Save subscription URLs using the original service’s account page or the client’s copy option. If you only have a local file, record it as “imported locally”—don’t assume it can update automatically.

1. Export the original configs: Save the YAML currently in use, along with the raw subscription content before the client processes it. Include the backup date in each filename.
2. Save transformation logic separately: Check CFW’s Parsers, Mixin, and any rules you added manually. These client-side settings may not be included in the subscription file.
3. Record runtime settings: Note the HTTP, SOCKS, or mixed port; whether LAN access is enabled; and your current mode and DNS settings.
4. Save external dependencies: Include local rule sets, certificate files, and any other files referenced by the config. Don’t copy only the main YAML and leave these behind.
5. Record proxy group selections: Note the groups and proxies you use most. The new client may not be able to read the old cache, so keep a text list as a backup.

On Linux, start by creating a backup directory accessible only to your user, then put the exported files inside it. The command below only creates the directory and restricts its permissions; it won’t find or export your old configs:

mkdir -p "$HOME/cfw-migration"
chmod 700 "$HOME/cfw-migration"
# After placing the exported configs and migration notes in this directory, tighten file permissions:
find "$HOME/cfw-migration" -type f -exec chmod 600 {} \;

Import Configs—Don’t Replace the Entire Old Directory

After launching the new client for the first time, leave TUN and the system proxy disabled. Import one config and review the parse results. If you have a subscription URL, import it again from the URL; if you only have a local YAML file, import it as a local config. If the client offers different import types, distinguish between remote configs and local files. Otherwise, an update button may appear without any source it can actually update.

Check Field Compatibility Before Revising Rules

Most common proxies, proxy-groups, and rules structures can still be used, but check the parse logs. Don’t assume that features specific to the original core, CFW-only transformation syntax, or legacy experimental fields will work unchanged in mihomo. If an error occurs, locate the field it refers to rather than deleting every unknown entry just to make the file load.

• Proxy protocols: Support for VLESS, Hysteria2, and other protocols depends on the target core. A config loading successfully doesn’t mean every proxy can connect.
• Rule providers: The download URL, behavior type, and format for rule-providers must be compatible. Check the logs for download or parse failures.
• Local paths: Windows drive-letter paths won’t work as-is on Linux. Resolve relative paths based on the new client’s config directory and core behavior.
• Rule order: Rules are generally evaluated from top to bottom. A custom rule placed after the final MATCH usually won’t have the intended effect.

Make Custom Changes Persistent with Overrides

Don’t edit only the downloaded subscription file; a later update may overwrite your changes. Use an override, merge, or scripting feature supported by the new client, then verify the merged result. Some methods replace the entire rules array, while others prepend rules, so don’t rely on a feature’s name alone. Start with an easy-to-check rule, update the subscription once, and confirm the rule is still there.

Rewrite each CFW Parser or Mixin for a method supported by the target client instead of copying the original wrapper structure. For details on what each field does, see the core and config reference.

Test the System Proxy and TUN Separately

The most common migration problems aren’t caused by broken proxies. They’re usually caused by two clients competing for the same port or the system proxy still pointing to a closed app. Before switching, open CFW’s General page and turn off System Proxy. If TUN was enabled, turn it off and exit the old client cleanly before starting the new one.

First, Test the Local Proxy Port

The steps below assume the new client is explicitly configured with mixed-port: 7890 and listens on the loopback address. Port 7890 is an example for this check, not a universal default. Use the port shown in the client or active config, and a test URL you’re authorized to access:

# Check whether port 7890 is listening on Linux
ss -lntp 'sport = :7890'

# Send a request explicitly through the HTTP proxy without relying on the desktop system proxy
curl --proxy http://127.0.0.1:7890 \
  --connect-timeout 10 --max-time 20 \
  --output /dev/null --write-out 'HTTP %{http_code}\n' \
  https://clash86.com/

A connection refusal usually means nothing is listening, the port is wrong, or the process failed to start. A timeout calls for further checks of the core logs, proxy connection, and DNS. Even an HTTP response only confirms that this request received a response; check the client’s connection log to make sure it used the expected rule and proxy group.

Next, Turn On the System Proxy

Once the local port works, enable the system proxy in the new client and test it in a browser. The system proxy mainly covers apps that respect the relevant settings. Whether terminal programs use a proxy also depends on environment variables and the programs’ own options. On GNOME, run gsettings get org.gnome.system.proxy mode to check the desktop proxy mode. That result doesn’t prove that every app is using the proxy.

Enable TUN Only If You Need It

TUN routes more connections that don’t follow the system proxy and requires the appropriate permissions or client service. Confirm the new client’s service permissions before enabling TUN. Don’t let old and new virtual interfaces both take over the default route. On Linux, use ip rule and ip route show table all to help inspect routing; don’t blindly copy bulk route-deletion commands from online posts. See the TUN mode guide for detailed steps.

Use a Checklist to Verify the Migration

A successful latency test doesn’t mean the migration is complete. It usually checks only whether the test destination is reachable; it can’t replace testing real-world traffic, rule matching, and DNS. Use the same network and follow the steps below, changing one setting at a time to make problems easier to pinpoint.

If you use fake-IP and local sites stop resolving correctly, check the DNS config and fake-ip-filter. Don’t assume every DNS problem means the proxy is at fault. Check IPv6 separately too: being able to reach IPv4 sites doesn’t mean IPv6 traffic is taking the expected route.

On phones, test with the screen locked as well. If an Android device disconnects while locked, check battery optimization, auto-start, and background restrictions. These issues are separate from whether the desktop YAML imported successfully.

Keep a Rollback Window Before Removing the Old Client

After the first round of tests, verify at least one reboot, one network switch, and one subscription update before considering CFW removal. Keeping a backup doesn’t mean leaving the old client running at startup: disable its auto-start and make sure its background service won’t claim the port. Removing the app files may not undo system services or network settings, so follow the cleanup steps for the original installation method.

1. Test a normal exit in the new client and confirm that regular network access is restored.
2. Keep the subscription source, local overrides, and migration notes; verify that the backup can actually be read.
3. Disable the old app’s startup entry and remove its background components using the service management or uninstall method for the original installation.
4. To roll back, first turn off the new client’s system proxy and TUN, then start the old setup to avoid routing traffic through both.

A successful migration isn’t about making the interface look familiar. It means subscriptions update, rules behave as expected, and the system recovers when the client exits. Follow this order: back up → import → test the local port → enable the system proxy → enable TUN → verify after a reboot. If something goes wrong, you’ll know which layer to check without reinstalling everything.