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

Migration essentials: switch clients, keep your subscription and rules

Windows users can compare Clash Verge Rev and FlClash; macOS users can consider ClashX Meta; Linux users should choose a package for their distribution; and Android users can start with FlClash. You don’t need to uninstall CFW first. Back up your setup, import it into the new client, verify rules, DNS, and traffic routing, then disable the old client’s startup entry.

Clash for Windows, commonly shortened to CFW, was discontinued in 2023. Version 0.20.39 was a commonly used final release. CFW is a graphical client, not the same thing as the Clash core or a subscription service. Switching clients doesn’t change your provider; if you keep the same subscription, your available proxies still depend on that provider.

Keep three layers in mind during migration

• Client: Manages subscriptions, system proxy settings, service permissions, and configuration overrides. Menus and file layouts vary between clients.
• Core: Parses YAML and handles proxy protocols, rules, and DNS. Clash Meta continued development under the name mihomo. Check the actual core to confirm whether a new client supports a particular field.
• Subscription: Provides proxy nodes or a complete configuration. A node list and a full Clash config are different input formats, so check what you have before importing it.

Clash alternatives: choose by platform and configuration features

Look for projects with recent releases, a clearly identified core version, and support for exporting configurations and viewing logs. Maintenance status can change, so treat the clients below as migration candidates, not as a permanent promise of support. Before installing, check the project’s release page for recent versions, system requirements, and known issues. Find links on the client downloads page.

Need overrides? Check the configuration system first

If you only need to import a subscription and select proxies manually, migration is straightforward. If you rely on custom rules, DNS settings, or scripts, first confirm that the new client can persistently layer local changes on top of the subscription. Clash Verge Rev’s merged configuration and script handling don’t use the same interface as CFW’s Parsers. Don’t infer how FlClash handles configuration from CFW’s file layout, either. Names and options may vary by version.

Having mihomo built in doesn’t mean every CFW feature is fully compatible. The YAML fields a core can parse are one thing; how the client saves, updates, and generates configuration is another. For more differences, see the client comparison.

Backup checklist: subscription URL, final config, and local changes

In CFW, turn off automatic subscription updates before you start, so the configuration doesn’t change while you’re documenting it. Open Profiles and note the active profile, subscription source, and last update time. In Proxies, record the selected option for each group you chose manually. In General and Settings, note the ports, system proxy, TUN, and configuration processing settings.

1. Save the subscription URL: Keep the entire URL, including query parameters. Subscription URLs may contain access tokens, so treat them like passwords and never post them in public forums.
2. Save the original YAML: Make a copy of the active configuration and label it as either the original subscription file or a processed version. The editor in the client may not show the final configuration used at runtime.
3. Save your overrides: Copy the Parsers settings, external scripts, custom rules, rule-provider URLs, and local files separately.
4. Record runtime settings: Note the actual mixed port (for example, 7890), listen address, proxy mode, DNS mode, and TUN setting. Port 7890 is common, but it isn’t fixed across devices.
5. Note special use cases: Check whether browser extensions, terminal environment variables, devices on your local network, or developer tools explicitly use the old proxy port.

Keep the user directory as a backup; don’t copy it over the new client

A common location for CFW user configuration on Windows is %USERPROFILE%\.config\clash, though portable mode and custom directories may use a different path. Use the location shown by your old client. You can copy the entire directory as a rollback backup, but don’t overwrite the new client’s directory with its databases, caches, or client settings.

Move your subscription: verify the original config before adding overrides

When importing for the first time, leave the new client’s system proxy and TUN disabled. Don’t route traffic through it yet. Add the original URL using the client’s subscription or configuration import feature. If the subscription is temporarily unavailable, import your backed-up YAML for an offline check—but it won’t receive future proxy updates automatically.

1. Check the import log to confirm you got a YAML configuration, not a login page, an error page, or text containing only proxy links.
2. Check the number of proxies, policy group names, and rule count. Make sure your manually selected groups are still there.
3. Enable the configuration, run the core’s configuration check, then review the startup log for unsupported fields, missing targets, or file read errors.
4. Inspect the generated configuration. Global client settings may override the subscription’s port, DNS, or TUN fields.
5. Once the original config starts successfully, add overrides one category at a time.

A successful import doesn’t guarantee the same behavior

The old configuration may rely on CFW-specific preprocessing that isn’t present in the raw content returned by your provider. Alternatively, the subscription may include protocols supported by a newer core that the old client couldn’t fully recognize; after moving to mihomo, the proxy list may look different. Compare the generated configuration—don’t treat a successful import as proof that migration is complete.

Keep the compatibility subscription link provided by your original provider. If you need to convert formats, use a method explicitly supported by the provider or client. Giving a token-bearing URL to an unfamiliar online converter increases the risk of exposing your subscription.

Custom rules and scripts: migrate what they do, not how they’re wired

CFW’s Parsers can match subscription URLs, merge fields, or rewrite configurations with JavaScript. A new client may use different script inputs, return values, and runtime environments. Even if both use JavaScript, an old script isn’t guaranteed to run as-is. Break it down into specific tasks first: add rules, adjust policy groups, replace DNS settings, or rename proxies.

Rule order matters more than copying every rule

Rules are generally evaluated from top to bottom, and the first matching rule determines the outcome. Put specific domain rules before broader ones, and leave the catch-all MATCH rule last. The snippet below can be added to a full configuration to send local names and private IPv4 addresses directly. It contains no proxy nodes and is not a complete subscription.

rules:
  - DOMAIN-SUFFIX,lan,DIRECT
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve

During migration, insert these entries in the right place in your existing rules. Don’t replace the entire rules list with this snippet. Whether an array is appended, prepended, or replaced depends on the new client’s override mechanism—check the generated configuration.

• Policy group references: Every group referenced by an existing rule must be present in proxy-groups in the full configuration. Keep group names and capitalization exactly the same.
• Rule providers: When migrating rule-providers, check behavior, format, URL, and local path as well. Don’t copy only the RULE-SET entries.
• Local files: Absolute paths from the old directory usually won’t work in the new client. For relative paths, check which configuration directory they’re resolved from.
• Duplicate rules: Don’t add another copy of private-network direct rules already present in the subscription. What matters is that the rule appears in the right place and has the right target.

Rewrite scripts in functional stages

Migrate changes that can be expressed in plain YAML first, then handle anything that genuinely requires a script. After each step, compare policy groups, rules, and DNS settings. Check whether a script renamed proxies that policy groups still reference by their old names. Don’t assume the new environment supports file access, network requests, or third-party dependencies used by an old script.

Check again after updating the subscription. If your custom rules disappear, they were saved only to a temporary generated file, not to a persistent override layer. See the YAML configuration guide for related fields.

Ports, DNS, and TUN: avoid running two clients at once

Once the configuration starts successfully, switch over network handling. Turn off the system proxy and TUN in CFW, then quit it normally. Make sure its background service or leftover processes aren’t still listening on a port before enabling the new client’s system proxy. Two programs competing for system proxy settings or routes can cause intermittent connections.

If the mixed port changes, update app-level proxy settings too

Suppose the old client listens on 127.0.0.1:7890 and the new one listens on 127.0.0.1:7897. Update the manual proxy settings in browser extensions, terminals, and developer tools too. You can keep the old port number as long as the old process has released it. The example below shows listener settings; use the new client’s actual runtime configuration.

mixed-port: 7897
allow-lan: false
bind-address: 127.0.0.1
mode: rule
log-level: info

mixed-port provides both HTTP and SOCKS proxy endpoints; it isn’t the external controller API port. Don’t expose the external controller to every network interface just to complete the migration. If you previously shared the proxy on your local network, separately check the listen address, firewall, and access restrictions.

Don’t carry over the old DNS cache

Note whether the old config used fake-ip or redir-host, along with its upstream resolvers, domain policies, and filter lists. Then check whether the new client overrides any of them. If nodes connect but websites don’t load after migration, inspect DNS requests and rule matches instead of immediately switching proxies again. Clear the cache or change modes only when there’s a clear reason; neither is a substitute for checking the configuration.

Enable TUN last

First test the browser with the system proxy, then enable TUN to test apps that ignore system proxy settings. Windows may require a client service and administrator approval; macOS needs the relevant permission component; Linux requires sufficient network privileges; and Android uses system VPN authorization. If you also use a corporate VPN, another proxy app, or a virtual machine, check for routing and DNS conflicts.

Verify and roll back if needed: update the subscription before uninstalling CFW

Migration is complete when your existing use cases work as expected—not when a latency test shows a number. Work through the checklist below and record the results. Don’t invent speed test figures as proof of success: latency to the same node at different times can’t verify that rules and DNS are working correctly.

1. Web access: Visit sites that should go direct and sites that should use a proxy. Check the matched rule and policy group in the log or connection list.
2. Local resources: Confirm you can still access your router’s admin page, local network services, and company intranet as expected.
3. App connections: Test developer tools or other apps beyond your browser, and determine whether each uses the system proxy, a manual proxy, or TUN.
4. Subscription updates: Run an update and check that your custom rules, policy group changes, and DNS overrides are still in place.
5. Restart recovery: Restart the new client and check the active configuration, selected proxies, service permissions, and startup settings.
6. Clean up permissions: Disable CFW startup and its old service. Keep an offline backup, and verify that system proxy settings are restored when the new client exits.

If something breaks, roll back one layer at a time

If the new client won’t start, remove overrides first and test the original subscription. If it starts but can’t connect, disable TUN and test only the system proxy. If the browser works but another app doesn’t, check that app’s proxy address and routing. Read logs in the order actions occurred and look for the first configuration or connection error; repeated timeouts later on can be misleading.

If you need to use the old client temporarily, disable traffic handling in the new client and quit it before launching the backed-up old setup. Don’t run two system proxies or TUN clients at once. Backups may contain subscription tokens, controller API secrets, and proxy credentials; store them somewhere protected. Remove the old installation only after the new configuration has passed update and restart checks and is working reliably.

The four essentials are preserving the subscription source, keeping overrides traceable, matching the port to the traffic-handling settings, and confirming rules still work after updates. Follow that order and replacing a client won’t turn into rebuilding your entire configuration.