After Clash for Windows Was Discontinued: Best mihomo Clients and a Step-by-Step Migration Guide

1. Understand the Difference Between the Client, Core, and Subscription

The original Clash for Windows (CFW) project is no longer maintained. Older installers may still launch, and existing proxies may still connect, but that does not mean the interface, dependencies, or proxy core will continue to receive fixes. The goal is not simply to replace the old app with one under a different name. It is to move your subscription source, local rules, and system-level proxy setup to a maintained client.

Clash Meta is a fork of the Clash core, later renamed mihomo. The GUI client handles subscription management, tray menus, system proxy settings, and service installation. The mihomo core parses configuration, establishes connections, and handles DNS and rule matching. Choosing a mihomo-compatible client does not mean it can import the entire CFW user directory as is.

• Subscription: Usually a URL with access credentials that returns a list of proxies or a complete YAML configuration. Your subscription provider still manages account access, data limits, and expiration.
• Core configuration: Common keys include proxies, proxy-groups, rules, dns, and tun.
• Client data: Includes subscription indexes, UI preferences, update schedules, and links to overrides. Its format depends on the client.
• System integration: System proxy settings, the TUN virtual network adapter, and background services are separate layers of state. Copying the YAML alone is not enough to migrate them.

2. Choose a mihomo Client for Your Platform

Check your system architecture first, then review the client's configuration editing and override features. The x64 and ARM64 labels on installers refer to different processor architectures; macOS builds for Apple silicon and Intel also differ. Client release numbers and core versions use separate numbering schemes, so note each one in the About or Core screen after installation. The app's name alone does not tell you which core is running.

On Desktop, Check These Three Features First

1. On the Subscription or Profiles screen, confirm that you can import a URL and update the subscription independently.
2. In Settings, locate the ports, system proxy, TUN, and core logs. Note the current values; don't enable everything at once.
3. Find the configuration override, merge, or script options, and check whether they apply to one subscription or the global configuration.

Menu names vary by client and version. In Clash Verge Rev, for example, you can start by importing a link under Subscriptions, then look in Settings for system proxy, virtual adapter, and service options. If the menus differ, check the documentation for your version rather than following CFW's menu path. Installation links for each platform are on the client download page.

3. Back Up Your CFW Configuration and Make a Migration Checklist

On Windows, CFW's user directory is often %USERPROFILE%\.config\clash, but portable setups, launch arguments, or custom directories may place it elsewhere. In the old client, open the actual directory via General → Home Directory. If the interface shows a path field or an Open Directory button, use the location shown there.

Exit the old client, then copy the entire configuration directory to a backup location only you can access. Sort out the following items separately. Saving only the currently selected YAML often misses the subscription URL and configuration enhancements.

• Subscription source: Save the original URL, subscription name, update interval, and whether it points to a local file. Don't record only the proxy names.
• Local configuration: Save the YAML files used in profiles and any related resources. Note which files are hand-edited and which are refreshed by a subscription.
• Configuration enhancements: Export or copy CFW Parsers, merge rules, scripts, and their matching conditions.
• Runtime settings: Note the HTTP, SOCKS, or mixed port; whether LAN access is allowed; and the DNS, TUN, and bypass address settings.
• Proxy selection: Record the currently selected proxies in your frequently used groups. Selection history may not carry over to another client.

4. Migrate the Subscription First, Then Check Proxy Groups and Rules

First, verify basic connectivity

1. Turn off the old client's system proxy, TUN, and auto-start, then exit the app. If you installed a background service, make sure it is no longer running.
2. Open the new client and add a subscription using the original URL. Don't overwrite its data directory with the old client's entire data folder.
3. Update the subscription and select the configuration. Check the logs for YAML parsing errors, unknown protocols, or references to missing proxy groups.
4. Select rule mode and choose a proxy manually. First test your browser with the system proxy, leaving TUN off for now.

A subscription may contain only proxies, or it may include a complete proxy-groups and rules configuration. A proxy-only subscription needs a client template or your own main configuration. If the import shows proxies but no usable groups, check the subscription type before assuming mihomo is incompatible.

Preserve Rule Order and References When Migrating

rules are matched from top to bottom, with MATCH usually at the end. Add custom domain rules before the catch-all rule. Proxy group names referenced by rules must match those in proxy-groups exactly, including spaces and capitalization. The snippet below illustrates rule order; it is not a complete subscription configuration:

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - MATCH,Proxy Selection

This snippet expects an existing proxy group named “Proxy Selection.” The example domains are for syntax illustration only; replace them with domains you actually want to access directly. If the client has a Prepend Rules feature, you usually need to enter only the list items, without wrapping them in rules:. Follow the instructions for that specific input field.

When using rule-providers, also migrate each provider's type, behavior, format, url, path, and update interval. Relative path values depend on the new core's working directory. If you haven't migrated the old cache directory, allow the rules to download again; a missing rule file does not mean the proxies are broken.

5. Adapt Parsers and Override Scripts for the New Client

CFW Parsers are not a universal configuration standard for mihomo. Even when both clients allow JavaScript, they may differ in the arguments passed to scripts, return values, execution order, and available APIs. Pasting an old script into a new client as is may prevent it from running, break subscription updates, or overwrite other settings even if it runs successfully.

Prefer Declarative Overrides for Fixed Settings

For fixed values such as ports, mode, and LAN access, use the new client's settings UI or configuration merge features where possible. The example below shows keys to check during migration; it is not a recommendation to replace the entire subscription configuration:

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

mixed-port: 7890 lets the same port accept HTTP and SOCKS requests, but the client may rewrite it when generating the final configuration. After changing it, check the configuration actually in use rather than just the override file. Be especially careful when merging lists: some options replace the entire rules array, while others prepend or append entries. The results are very different.

If You Need Scripts, Rebuild the Transformation Logic Step by Step

1. First, describe what the old script does—for example, removing certain proxies, adding a proxy group, or changing DNS. Avoid carrying over every bit of legacy logic.
2. Write the script using the entry point documented by the new client. Confirm the function signature, how to return the complete configuration, and how errors are reported.
3. Migrate one change at a time. After each change, check the proxy count, group members, and rule order before moving on.
4. Manually update the subscription once and check that your local changes are still there. The override is attached correctly only if it remains effective after an update.

Don't confuse legacy Clash core script settings with client-side JavaScript preprocessing. For historical fields such as script, check what the current mihomo version supports and, where possible, replace them with explicit rules, rule sets, or client-side preprocessing.

6. Test Ports, DNS, and TUN Separately

A working browser connection proves only that one path works. Command-line tools, games, LAN devices, and UDP traffic may take different routes. Test the migration layer by layer, changing only one variable at a time.

In Windows PowerShell, use the commands below to check the port and an explicit HTTP proxy. curl.exe is specified to avoid parameter differences caused by the curl alias in older versions of PowerShell. Replace the test URL with the service you need to verify.

Get-NetTCPConnection -LocalPort 7890 -State Listen
curl.exe --proxy http://127.0.0.1:7890 --head --max-time 15 https://example.com

A successful explicit HTTP proxy request does not prove that UDP traffic is being routed through the proxy. After enabling TUN, test apps that use UDP separately and check the connection log. For DNS, if the old configuration uses enhanced-mode: fake-ip, also review fake-ip-filter and your local domain resolution requirements. Corporate intranet domains often rely on internal DNS and should not simply be sent to a public resolver.

Check the Configuration with the Core if Needed

If you have a standalone mihomo executable, you can run a syntax check from the configuration directory. The example below assumes Windows and that the core and configuration are in the current directory. For configurations generated inside a client, use its built-in checker whenever possible.

.\mihomo.exe -t -d . -f .\config.yaml

-t tests the configuration, -d specifies the working directory, and -f specifies the configuration file. Passing the check does not mean proxies are reachable, and it does not verify subscription access, remote rule downloads, or actual DNS behavior. Check the runtime logs as well.

7. Test Updates Before Removing the Old Client

We recommend completing at least one manual subscription update, one system restart, and one routine network switch. After restarting, confirm that only the new client starts automatically. Then switch from Ethernet to Wi-Fi and check TUN routing and LAN access. These tests better reflect real-world use than a single latency test.

• Update check: Custom rules, proxy groups, and DNS overrides remain in effect after the subscription refreshes.
• App check: Test your browser, terminal, developer tools, and LAN services separately; don't stop at a single website.
• Service check: Confirm the old client's background service, startup tasks, and system proxy settings no longer handle your traffic.
• Rollback plan: Keep the original backup in a secure location and record the new client version, core version, and migration date.

Remove the old app and clean up its files only after the new configuration is stable. Use the old client's service management options to uninstall any background service. If you need to roll back, first turn off TUN and the system proxy in the new client and exit the core, then restore the old setup. Don't run both apps at once to compare them.