How to Migrate After Clash for Windows Was Discontinued: Client Alternatives and Configuration Transfer

After Clash for Windows was discontinued, keeping the old version does not mean your existing configuration will stop working immediately. Subscription URLs, proxy nodes, proxy groups, and routing rules are usually supplied by the configuration file. The client mainly handles configuration management, core startup, system proxy settings, TUN interception, and UI controls. Migration is therefore not about finding software with an identical appearance. The key is confirming that the new client can run the required core, parse your existing configuration syntax, and correctly take over the operating system's network settings.

The safest approach is to back up the old data first, choose a desktop client that is still actively maintained, re-import the subscription URL or original YAML, and then check the rule mode, proxy groups, DNS, system proxy, and TUN settings one by one. Do not start the new client while the old client is still handling traffic. Two programs may modify the system proxy, virtual adapter, or service state at the same time, making the source of any problem difficult to identify.

First determine whether you need to migrate the subscription, configuration, or runtime environment

The “configuration” visible in Clash for Windows may come from several sources. The most common is a remote subscription: the client stores the subscription URL, downloads a YAML file when it updates, and reads nodes, proxy groups, and rules from it. The second is a manually imported local YAML file, such as a custom routing file. The third consists of client-specific settings, including startup behavior, system proxy ports, UI preferences, configuration overrides, parser scripts, and the TUN service. These three categories are not equally portable.

If you only imported a provider's subscription and never edited the YAML manually, migration is usually straightforward: save the subscription URL and your commonly used proxy-group selections, then import them again in the new client. If you maintain custom rules, proxy providers, or DNS settings, organize the original YAML, external rule files, and referenced paths together instead of copying only the runtime configuration generated by the old client.

How to choose an alternative client: core, platform, and configuration support

When evaluating a desktop alternative, check its maintenance activity first, followed by operating-system support and core capabilities. Clash Verge Rev is a desktop client for Windows, macOS, and Linux that uses the mihomo core. It suits users who need rule-based routing, configuration management, system proxy support, and TUN. mihomo preserves the Clash configuration model while extending rule-set, protocol, DNS, and traffic-interception capabilities, so many standard Clash YAML files remain usable.

Other actively maintained mihomo graphical clients may also be worth considering, but do not compare them by appearance alone. Release cadence, core version, configuration storage, system-proxy recovery, TUN service installation, and access to connections, logs, and rule-match results matter more. Maintenance status can change over time, so check the project's current releases and documentation.

Six checks when choosing an alternative client

1. Platform coverage: Confirm that the client explicitly supports your current Windows, macOS, or Linux version, and choose the correct processor architecture.
2. Core type: Confirm whether it uses mihomo and whether the client lets you view or update the core version.
3. Configuration support: Check support for subscriptions, local YAML, proxy providers, rule providers, and custom DNS.
4. Traffic interception: Confirm whether the system proxy and TUN are controlled separately, and whether system settings are restored when the program exits.
5. Diagnostics: Connection lists, live logs, rule matching, and DNS logs make migration issues easier to locate.
6. Configuration maintenance: Check how subscription updates, overrides, and merges work so local changes are not overwritten on every update.

Some settings from older versions of Clash for Windows may depend on the behavior of Clash Premium or may have been transformed through the client's parser feature. mihomo is highly compatible with common node, proxy-group, and rule syntax, but client-specific scripts, JavaScript parsing logic, and UI settings are not part of the standard YAML model and usually need to be rebuilt. Before choosing a client, review the client comparison, then decide based on your platform and configuration complexity.

How to back up Clash for Windows data before migrating

The goal of a backup is to preserve recoverable information, not to overwrite the new client's directory with the entire old directory. Before starting, open Clash for Windows and record the currently active configuration name, proxy mode, commonly used proxy-group selections, system proxy status, and TUN status. If the subscription URL is visible in the configuration manager, save it separately. If it contains an access token, store the backup securely and do not paste it into public screenshots, logs, or forums.

Next, exit Clash for Windows and confirm that its tray process has ended. On Windows, old data is often stored in a configuration directory under the user profile, but the exact location varies by installation method and version. Rather than assuming a fixed path, open the data directory from the client's settings or configuration manager, then copy the entire directory as a read-only backup.

Content worth preserving

• The subscription URL, subscription name, and the last successful update time;
• YAML files you wrote yourself and the local rule files they reference;
• The current runtime configuration, for section-by-section comparison after migration;
• Frequently used proxy-group selections, such as automatic selection, failover, or a specific node;
• Custom ports, LAN access, DNS listeners, and controller settings;
• The source files and processing notes for overrides, merges, or parser scripts.

After creating the backup, disable the system proxy and TUN in the old client, then exit normally. Open the operating system's proxy settings and confirm that the manual proxy no longer points to the old local port. If the old TUN service is still present, stop or uninstall it through the service-management entry provided by the old client before installing the corresponding service for the new client.

Subscription and YAML configuration migration steps

Option 1: Re-import the subscription URL

For most users, adding the subscription again is the preferred approach. After installing the new client, keep the system proxy and TUN disabled, open the configuration or subscription page, paste the original subscription URL, and wait for the client to download and parse the configuration. After import, check that the node count, proxy-group names, and rule count are as expected, then select your usual proxies manually.

A successful subscription import only means that the YAML was readable; it does not mean traffic is working correctly. Check that the configuration includes a final catch-all rule such as MATCH and that the main proxy groups reference valid nodes. Some subscriptions return different formats based on the client's request headers. If the new client receives an empty configuration or a format error, obtain a subscription URL intended for Clash or mihomo from the provider's management page.

Option 2: Import a local YAML file

Add a local configuration through the new client's file-import feature. Before importing, use a text editor to inspect key sections, including proxies, proxy-providers, proxy-groups, rule-providers, rules, and dns. Nodes or provider names referenced by proxy groups must actually exist, and proxy-group names referenced in rules must match their definitions exactly.

mode: rule
mixed-port: 7890

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - AUTO
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

The structure above shows the basic reference relationship: rules send traffic to PROXY, and the PROXY proxy group must already be defined. During an actual migration, do not blindly copy example ports or rules. Preserve the requirements of the original configuration and adjust them for ports used by the new client. If the configuration references files with relative paths, check the new client's working directory. After changing applications, the same relative path may point somewhere else.

Option 3: Rebuild override and merge logic

Some Clash for Windows users used parser scripts to append rules to subscriptions, remove proxy groups, or rename nodes. This logic usually cannot be imported as ordinary YAML. During migration, first obtain the base configuration generated by the subscription, then use the override, merge, or scripting mechanism supported by the new client to recreate the same result.

Break the work into small steps: add one proxy group first, then add its rules and confirm that the configuration loads before continuing. Migrating a large script all at once mixes syntax errors, name-reference errors, and rule-order problems. Rules are evaluated from top to bottom and stop at the first match, so new rules must be placed appropriately; merely confirming that the rule text exists is not enough.

TUN, DNS, and the system proxy cannot be copied directly

The system proxy affects only applications that follow the operating system's proxy settings. Common browsers and some desktop applications connect through a local HTTP or SOCKS port. TUN uses a virtual network interface and routing to intercept more traffic, including programs that ignore the system proxy. Both are runtime-environment settings rather than subscription node data, so they must be configured again after changing clients.

Start with the system proxy for basic verification. Choose a working node, enable rule mode and the system proxy, and confirm that web access, rule matching, and DNS resolution work correctly. Once the basic path is stable, enable TUN and follow the new client's instructions to install its service or grant administrator privileges. This makes it easier to distinguish configuration errors from issues involving the virtual adapter, permissions, or routes.

DNS settings require particular care. Common mihomo enhanced modes include fake-ip and redir-host; available options depend on the core version and configuration. If websites open after migration but some LAN domains, games, or enterprise applications fail, check the DNS listener address, enhanced mode, bypass list, upstream servers, and rule mode before switching nodes.

If the original configuration enabled LAN access, review allow-lan, the bind address, and the operating system firewall again. A loopback address is available only to the local machine, while listening on all interfaces may allow devices on the same network to connect. Configure this according to your actual sharing needs rather than copying the old setting blindly.

How to confirm traffic routing after migration

Verify the migration in layers, from configuration loading and node connections to rule matching and system restoration. Testing only one website can hide problems because browser caches, connection reuse, and application-specific DNS may affect the result. Use this order as a checklist:

1. Start the new client and confirm that the logs show no YAML parsing, proxy-group reference, or port-conflict errors.
2. Update the subscription and confirm that the update time, node count, and proxy-group structure are reasonable.
3. In rule mode, choose a clearly defined proxy-group exit and test a regular web connection.
4. Open the connections or logs page to see which rule matched the destination domain and which final policy was used.
5. Test domains that should connect directly and through the proxy separately, confirming that DIRECT and the proxy policy behave as expected.
6. After enabling TUN, test applications that do not read the system proxy and observe whether their connections enter the core.
7. Exit the client and confirm that the system proxy is restored and traffic is no longer directed to a stopped local port.

If rule-match results differ from the old client, first compare the final configurations actually loaded by both clients rather than comparing subscription names alone. Subscription updates, client overrides, failed rule-set downloads, and core-feature differences can all change the final content. mihomo connection details typically show the rule type, policy chain, and exit node, making them more useful than speed alone for determining whether routing is correct.

Common post-migration issues and troubleshooting order

The subscription imports, but there are no nodes

First confirm that the subscription is still valid and that its response is a Clash or mihomo configuration. Some URLs require format conversion in the service management page. If opening the URL in a browser returns a login page, error text, or a format intended for another client, the new client cannot generate a node list.

The configuration says a proxy group does not exist

Check whether the policy names used in rules exactly match those in proxy-groups, including capitalization, spaces, and symbols. If a proxy group uses use, also confirm that the relevant proxy-providers are defined and downloaded successfully. After manually removing a proxy group, update every rule that references it.

Startup reports that a port is already in use

The old client or core process may still be listening in the background. Fully exit both clients, use Task Manager or a system-monitoring tool to confirm that the relevant processes have ended, and then start the new client again. You can also temporarily change the new client's mixed port, but the system proxy must be updated to point to the new port.

The internet stops working after enabling TUN

Disable TUN first and confirm whether system-proxy mode works normally. If the system proxy works, focus on the TUN service, permissions, virtual adapter, routes, and DNS. If multiple clients have been installed, also confirm that no old service is still running. After resolving service conflicts, restart the system to prevent leftover routes from affecting the diagnosis.

Custom rules disappear after a subscription update

This usually means the changes were written directly into the subscription cache. A remote update downloads the configuration again and overwrites the cached content. Use the new client's override or merge mechanism to maintain local rules, or create a separate YAML file and update remote nodes through a proxy provider. For specific fields and procedures, see the technical reference.

Should the old client be removed immediately?

After backing up your data, you can keep the installer and data directory for a while, but do not let the old client start with the system or take over the system proxy or TUN at the same time as the new client. After several days of use, once subscription updates, rule routing, sleep and wake recovery, and exit restoration all work normally, cleaning up the old program and its services is safer.

Migration summary: preserve configuration sources and rebuild the runtime environment

The core of migrating after Clash for Windows was discontinued can be summarized in two parts. Reusable items include subscriptions, nodes, proxy groups, and standard rules. Items that need to be rebuilt include client settings, override logic, the system proxy, the TUN service, and some DNS behavior. For ordinary subscription users, re-importing the subscription and reviewing the proxy groups is usually enough. Users who maintain custom YAML should pay particular attention to name references, rule order, external file paths, and core syntax.

When choosing an alternative client, active maintenance, mihomo core support, diagnostic tools, and stable system integration matter more than visual similarity. Keep a backup of the original configuration after migration and record the key settings in the new client. When changing devices or clients later, you can restore from clearly identified data sources instead of relying on temporary cache files generated by a particular program.