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

Discontinuation impact and migration scope

After Clash for Windows stopped being maintained, existing installations did not become unusable immediately. Local configuration, downloaded subscriptions, and proxy rules may continue to work, but the client no longer adapts to operating-system changes, tracks new mihomo kernel fields and TUN implementations, or receives security fixes. With an old version, the common problems are not that “all nodes suddenly stop working,” but that updated subscription formats cannot be read completely, the system proxy state is not restored correctly, the TUN service conflicts with a newer operating system, or new rule fields are ignored by the old kernel.

Migration involves three kinds of data. The first is the subscription entry point: the subscription URL, remote configuration update time, and configuration name. The second is user customization: custom rules, override fields, scripts, and policy-group selections. The third is device takeover state: system proxy, launch at startup, LAN access, TUN service, and DNS settings. Copying a single YAML file usually does not cover all three.

If the daily configuration comes entirely from a subscription, focus on importing it again and restoring policy-group selections in the new client. If Mixin, Parsers, Script, or manual configuration edits were used in Clash for Windows, record those changes separately. Graphical clients use different names and formats for overrides, and a JavaScript parser from the old client should not be treated as a universal configuration.

Back up the subscription and local changes before migrating

Record the subscription entry point

Open the Profiles page in Clash for Windows and confirm whether the active profile is a remote subscription or a local configuration. For a remote subscription, save the original subscription URL rather than keeping only the YAML cached by the client. The original URL lets the new client fetch the latest nodes, policy groups, and rules; a cache file reflects only one update and may later fail when remote rule-set paths change.

Subscription URLs often contain account-identifying parameters and should be treated like passwords. Do not include them in public screenshots, support requests, or public code repositories. If the provider supports resetting a subscription link, reset it first if the URL has been exposed, then import the new URL into the new client.

Export the local configuration

For manually maintained YAML, open the client’s configuration directory and copy the active main configuration together with its referenced files into a separate directory. Check proxy providers, rule providers, local rule sets, and certificate files as well. Relative paths in the main configuration depend on the original directory structure; preserve that hierarchy after moving the files, or specify the paths again in the new client.

The following fields are especially worth recording separately:

• mode: whether the current mode is Rule, Global, or Direct.
• proxies and proxy-providers: manually defined nodes and remote node providers.
• proxy-groups: policy-group names, types, references, and health-check URLs.
• rules and rule-providers: custom rule order and external rule sets.
• dns: whether DNS is enabled, its operating mode, upstream servers, and exclusions.
• tun: the virtual network interface, automatic routing, DNS hijacking, and interface selection.

If configuration is imported only from a subscription, avoid making long-term edits directly in the subscription-generated YAML. The next update may overwrite them. After moving to the new client, use its override, extension-script, or configuration-merge feature to preserve custom changes, and confirm that the feature runs again after every subscription update.

Create a migration record

Before closing the old client, record the currently selected policy-group nodes, system proxy port, whether LAN access is allowed, whether TUN is enabled, and which applications depend on the proxy. Policy-group selections are usually stored in the client’s own database or cache and may not be written back to the subscription YAML. Even when group and node names are identical, the new client may select the first item in each group on its initial load, so reselect them manually.

How to choose an alternative client

When choosing an alternative client, do not compare interfaces alone. The kernel, platform support, configuration compatibility, and traffic-takeover method matter more. Most actively maintained clients now use mihomo as their core. mihomo extends the Clash configuration model with capabilities such as rule sets, DNS, traffic sniffing, and TUN. The client handles configuration management and system integration; the kernel parses configuration, establishes connections, and applies rules.

Windows users generally need to confirm that the installer matches the device architecture, such as x64 or ARM64. On macOS, distinguish between Apple silicon and Intel processors. Linux users should also check the desktop environment, package format, and system-service permissions in addition to architecture. Starting the client is only the first step; stable traffic takeover depends on whether the system proxy switch, TUN driver, or service installs correctly.

If the original configuration contains mihomo-specific fields, choose a client that explicitly uses an actively maintained mihomo kernel. If it contains only basic ports, ordinary nodes, policy groups, and rules, most clients compatible with Clash configuration can read it. A graphical client’s own override database, interface preferences, and shortcut settings are not part of the YAML standard and generally cannot be copied directly between clients.

Move from Clash for Windows to a new client

Step 1: Release traffic control from the old client

1. In Clash for Windows, disable System Proxy.
2. If TUN Mode is enabled, disable TUN first and wait for the network interface to recover.
3. Exit the client and confirm that its background processes have ended.
4. Check the operating system’s proxy settings and make sure no manual proxy still points to the old port.

This prevents port conflicts and duplicate routing. When two clients enable the system proxy at once, the one that last writes the system setting usually becomes the entry point, but the other may still occupy a port. Running two TUN interfaces simultaneously can cause default-route competition, DNS requests to bypass the intended path, or abnormal LAN access.

Step 2: Install and start the new client for the first time

Get an installer matching the operating system and processor architecture from the client project’s official release channel. After the first launch, do not enable the system proxy or TUN immediately. First check that the kernel status and configuration directory are normal. Some clients update the mihomo kernel separately; if the interface shows that the kernel is not ready, follow the client’s instructions to install or switch the core.

Step 3: Reimport the subscription

Paste the original subscription URL into the new client’s subscription or configuration entry point, download it, and set it as the active configuration. After loading, check that the node count, policy-group names, and rule count are broadly consistent with the old client. They do not need to match exactly because the subscription service may update its content during migration, but the configuration should not be empty, contain only a few nodes, or lack all policy groups.

If the subscription returns “Invalid format,” first make sure the copied URL has no extra spaces or line breaks, then try obtaining the link again through a browser or the provider’s console. If the content was generated in an older Clash format and the new client uses mihomo, the basic fields are usually readable. The more common causes of failure are incorrect indentation, inaccessible referenced files, policy groups referring to nonexistent nodes, or a subscription response that actually contains a login page.

Step 4: Migrate custom rules and overrides

Add personal rules from the old configuration to the override location supported by the new client, preserving their original order. Clash evaluates rules from top to bottom, and the first match determines where traffic goes, so order matters more than the number of rules. LAN direct rules, specified-domain proxy rules, application-process rules, and the final catch-all rule must not be rearranged arbitrarily.

rules:
  - DOMAIN-SUFFIX,lan,DIRECT
  - DOMAIN-SUFFIX,example.net,Proxy
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

The example above illustrates ordering only. In actual use, Proxy must exactly match a policy-group name in the configuration. Group names containing spaces or Chinese characters must also match character for character. If the subscription rebuilds policy groups on every update, point custom rules to a stable group name to avoid a “policy group not found” loading error after an update.

Clash for Windows Parsers may use JavaScript to modify subscription results, and that logic cannot be pasted directly into every new client. First understand which fields the script changes, then rewrite it as an override, merged configuration, or extension script supported by the target client. Do not enable multiple override systems without understanding their execution stages; otherwise ports may be modified twice or DNS fields may be overwritten by a later configuration.

Step 5: Restore policy selections and the update interval

Open each policy group and restore the frequently used node or automatic-selection method. For automatic groups such as url-test and fallback, confirm that health checks run successfully; for manual select groups, make sure the current choice is not a dead node. Then set the subscription update interval, run one manual update, and verify that the overrides are still present.

How to restore system proxy and TUN settings

Loading a subscription does not mean that the device’s traffic is already entering Clash. The new client still needs to establish a traffic entry point. The system proxy and TUN are different takeover methods: verify the system proxy first, then decide whether to enable TUN based on application compatibility.

Test the system proxy first

After enabling the new client’s system proxy, the operating system sends HTTP or SOCKS traffic from applications that honor system proxy settings to the local listening port. Browsers and most desktop applications can usually use this method directly. Open the client’s connection log, visit a test site, and confirm that it shows the domain, matched rule, and final policy group.

If the network becomes completely unavailable, check whether the new client’s listening port is occupied, whether the system proxy points to the correct local address, and whether the configuration is in Rule mode. If the system remains offline after closing the client, open the operating system’s network settings and clear any leftover manual proxy.

Configure TUN next

Games, command-line tools, some store applications, and software that does not read system proxy settings may require TUN. TUN creates a virtual network interface and passes IP traffic that meets the routing conditions to mihomo. First-time activation usually requires administrator privileges and may install a system service or virtual network-interface component.

When migrating TUN, do not copy the old client’s toggle state directly. Start with the new client’s recommended defaults, confirm that the virtual interface is created successfully, then check auto-route, strict-route, DNS hijacking, and automatic interface detection. These fields are implemented differently across operating systems, and the new client may generate the corresponding configuration through its interface.

If LAN printers, NAS devices, or router administration pages become inaccessible after enabling TUN, first check that private subnets remain direct and whether strict routing changed the local access path. If only domain access fails while direct IP access works, focus on the DNS mode, Fake-IP exclusions, and upstream DNS reachability rather than repeatedly switching nodes.

Post-migration checklist

After importing the subscription and enabling traffic takeover, run through the checks below in order. Move to the next item only after completing the previous one to quickly determine whether the issue is in the configuration, rules, or system entry point.

1. Kernel status: the client shows mihomo running normally, with no repeated restarts or configuration parsing errors.
2. Subscription updates: a manual update completes, the update time changes, and nodes and policy groups appear normally.
3. Configuration mode: confirm that the current mode is the required Rule, Global, or Direct mode; do not automatically keep the interface’s initial value after migration.
4. Policy groups: manual selections are restored, automatic groups can complete latency tests, and every group referenced by the rules exists.
5. System proxy: browsing produces connection records, and disabling the system proxy correctly restores the network settings.
6. DNS: domain resolution is stable with no repeated timeouts; LAN domains and special domains are handled as expected.
7. TUN: enable it only when needed, and verify that applications ignoring system proxy settings appear in the connection records.
8. LAN: routers, NAS devices, printers, and shared services remain accessible, and private addresses are not incorrectly sent through the proxy.
9. Launch at startup: confirm that only the new client remains in startup items, and check that the system proxy or TUN will be restored as expected.
10. Old client cleanup: uninstall the old client only after stable use for a while, and confirm before uninstalling that the backup directory is outside the application-data cleanup scope.

Common migration troubleshooting

Subscription imported successfully but no nodes appear

First check whether the subscription response is a valid configuration. Some URLs must be regenerated in the provider’s console, and an expired link may return a message instead of YAML. Also confirm that the client is not using an incorrect subscription-conversion template and that the node-provider URL in the configuration is reachable.

Configuration loads but all rules use the catch-all

Check whether custom rules were placed after MATCH. MATCH is the final rule, so later entries are not executed. If remote rule providers are used, also confirm that rule-providers downloaded successfully and that the RULE-SET name in the rules matches the provider name.

Some applications ignore the system proxy

This usually means the application does not read the operating system proxy, not that subscription import failed. First confirm in the client log that browser traffic works, then configure the target application’s own proxy or use TUN after verifying permissions and routing. Do not modify the entire DNS configuration immediately because a single application has no connection record.

Network goes offline after enabling TUN

Disable TUN first and confirm that system proxy mode still works. Then check virtual-interface service permissions, default-interface detection, route conflicts, and upstream DNS. Other network filters, virtual-machine networks, and corporate VPNs on the device may also rewrite routes. During troubleshooting, enable only one takeover tool at a time to avoid changing multiple variables simultaneously.

Custom rules disappear after a subscription update

This means the rules were written directly into the subscription cache and were overwritten by remote content during the update. Move them to the persistent override location provided by the new client and confirm that the override runs after subscription parsing. After migration, perform at least two manual updates to verify that rule, DNS, and policy-group changes persist.