How to Migrate After Clash for Windows Was Discontinued: Alternative Clients and Configuration Compatibility Guide

Choose a maintained client first, then migrate subscriptions and rules

After Clash for Windows reached end of maintenance, it should not remain your primary long-term client. The goal is not to find software with an identical interface, but to confirm that the new client’s core, supported configuration fields, system-proxy implementation, and TUN capabilities meet your needs. On Windows, macOS, and Linux desktops, prioritize maintained graphical clients built on the mihomo core. For lightweight deployment or remote management, use the mihomo command-line core with a control panel. On Android and iOS, re-import the subscription into a client supported by the platform; do not copy the desktop app directory.

Most standard subscriptions can simply be added again in the new client; there is no need to move the old client’s entire runtime directory. The items that require separate handling are local YAML configuration, rule sets, proxy-group choices, overrides, scripts, subscription-update URLs, and LAN-sharing settings. Clash for Windows interface settings, JavaScript Parser, version-specific Profiles data structures, and system-proxy state are not equivalent to a portable Clash configuration. Copying them directly may cause load failures, changed rule order, or different DNS behavior.

Choose an alternative client by platform, core, and maintenance status

Alternative clients may have similar names, but they are not successive versions of one project. Evaluate the graphical interface and proxy core separately: the interface handles configuration, subscription updates, system-proxy toggles, and logs; the core handles protocol connections, rule matching, DNS, TUN, and traffic forwarding. Clients using the mihomo core generally recognize more modern configuration fields, but actual support still depends on the client version, core version, and operating-system permissions.

If you only used rule mode, subscription updates, and the system proxy, moving to a mainstream mihomo desktop client is usually straightforward. If the old setup depends on TUN, script overrides, complex DNS, LAN sharing, or multiple proxy providers, read the target client’s configuration documentation and run a small-scope test first. Do not judge compatibility from screenshots alone: a client may change its core or configuration storage between versions.

Windows users: check service mode first

On Windows, the standard system proxy mainly affects apps that honor the system proxy setting. Games, command-line programs, some Store apps, and software with its own network stack may bypass it. To capture more traffic, TUN is usually required. TUN involves a virtual network adapter, administrator privileges, routing tables, and DNS interception, so verify the standard system proxy first and enable TUN separately to avoid troubleshooting multiple variables at once.

macOS and Linux users: check permissions and the desktop environment

On macOS, system extensions, network permissions, and Login Items can affect TUN and startup behavior. On Linux, account for desktop proxy settings, NetworkManager, systemd services, and kernel network permissions. A client’s stated platform support only means that it can run; it does not guarantee that every desktop environment can update the system proxy automatically. On servers or headless systems, the mihomo core with a configuration file is often a better fit than a desktop client.

Importing a subscription does not mean the old configuration can be copied unchanged

Clash configurations typically use YAML, but “all YAML” does not mean complete field compatibility. Standard proxy nodes, proxy groups, and rules are generally portable; parts tied to a specific core, graphical client, or operating system require fresh review. For migration, divide the setup into four layers: subscription data, core configuration, client overrides, and system state.

1. Subscription data: Subscription URLs, nodes, proxy groups, and remote rule providers. The safest approach is to add the subscription URL again in the new client and let it download and parse the data itself.
2. Core configuration: Ports, operating mode, DNS, TUN, rules, proxy groups, external controller, and LAN listening. Check each field against the target core’s documentation.
3. Client overrides: Subscription merging, global extensions, configuration preprocessing, scripts, and extra settings saved by the interface. This layer often cannot be reused directly across clients.
4. System state: System proxy, virtual network adapter, services, startup items, firewall exceptions, and local port usage. Copying configuration files does not migrate this state automatically.

Configuration that can usually be retained

Common proxies, proxy-groups, rules, proxy-providers, and rule-providers entries can serve as the migration foundation. When using rule types such as DOMAIN, DOMAIN-SUFFIX, DOMAIN-KEYWORD, IP-CIDR, GEOIP, and MATCH, preserve top-to-bottom evaluation order. The first matching rule determines where traffic goes. If the new client automatically inserts or overrides rules, the result may differ from the old environment.

Configuration that requires a fresh review

• The network stack, auto-route, interface detection, and DNS hijacking options under tun.
• enhanced-mode, the Fake IP range, fallback resolvers, and domain-filter lists under dns.
• external-controller, the controller listening address, and the access key.
• allow-lan, bind-address, and local firewall rules.
• Parser, JavaScript scripts, shortcut commands, and interface overrides interpreted only by the old client.
• Protocol parameters, rule types, and sniffing settings available only in a specific core.

The simplified structure below is intended for migration checks. Its focus is confirming that the new core can load the ports, mode, DNS, and rules. It contains no real nodes; in practice, import nodes and proxy groups from your subscription instead of placing sensitive connection details in a public document.

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

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
    - 1.1.1.1

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

The PROXY in this configuration must refer to an actual proxy group, or the core will report that the policy target does not exist. The DNS addresses are structural examples only; choose them according to your network, privacy requirements, and subscription documentation. If the old setup used redir-host, switching to fake-ip may change how LAN domains, special apps, and connection-testing tools behave, so do not change the DNS mode during the initial import.

Back up configuration sources, not the entire runtime state

Before migrating, record a working baseline in the old client. The purpose of the backup is to document how the connection worked, not to make both clients share one data directory. Different clients may write configuration indexes, caches, and proxy selections at the same time, and a shared directory can cause file-format conflicts.

Content worth preserving

• Active subscription URLs and their purposes, distinguishing primary, test, and local configurations.
• Manually maintained YAML files, rule files, proxy-provider URLs, and rule-provider URLs.
• The current proxy mode, such as rule, global, or direct mode.
• Selections for commonly used proxy groups, such as automatic selection, fallback, or a specific node.
• Mixed, HTTP, SOCKS, and external-controller ports.
• DNS enhanced mode, TUN status, LAN access status, and listening addresses.
• Any Parser or override logic that must be retained, along with a written description of the fields it changes.

Subscription URLs and local configuration may contain access credentials. Do not paste them into public logs, screenshots, or online formatting tools. Store backup files somewhere controlled by the current account. If you plan to reinstall the system, also record the client version, core version, and system architecture, because the same configuration may behave differently across core versions.

Record port usage before quitting the old client

Clash-based clients often use local ports such as 7890, but the actual ports may have been changed. If the new client cannot bind a port after migration, common causes include an old process that is still running, another proxy program using the port, or a system service continuing in the background. Closing the window does not always terminate the process. Quit normally from the client menu, then check Task Manager or the system process list.

Build a connection with the minimum configuration, then restore advanced features one at a time

Importing every old setting at once makes the source of failures difficult to identify. A more reliable order is to verify that the client and core start, then verify subscription parsing, node connectivity, and rule matching, and only afterward configure TUN, DNS overrides, and LAN sharing.

1. Confirm the operating system and processor architecture.

   On Windows, distinguish architectures such as x64 and ARM64. On macOS, identify whether the machine uses Apple silicon or Intel. On Linux, also confirm the distribution, package format, and desktop environment. A mismatched installer architecture may prevent the program from starting or installing system services.

2. Install the target client and check its core.

   After the first launch, check the core name and version shown by the client. If you plan to use mihomo configuration extensions, confirm that mihomo is actually running instead of inferring it from the client’s name.

3. Quit the old client completely.

   Disable the old client’s system proxy and TUN, then exit its background processes. Do not let two clients modify the system proxy, routes, or DNS at the same time.

4. Add the subscription again.

   Use the original subscription URL to create a configuration in the new client whenever possible. After the update completes, check that nodes and proxy groups were generated and that the configuration page shows no parse errors. If the subscription provider offers a format intended only for a particular client, first confirm that Clash or mihomo format is available.

5. Enable rule mode and the system proxy first.

   Choose an available node or proxy group, keep TUN disabled, and test basic connectivity in a browser. At this stage, review the core logs to confirm that DNS resolution, rule matching, and the proxy handshake all work normally.

6. Restore custom rules and overrides.

   Add only one category of change at a time: restore rule providers first, then proxy-group adjustments, and DNS last. Reload the configuration immediately after each change and watch where errors occur.

7. Enable TUN only if needed.

   After confirming that the standard system proxy works, grant the required permissions and enable TUN. When testing is complete, check that routes, DNS, and the virtual network adapter are restored correctly when the client exits.

8. Configure startup and LAN sharing last.

   Set automatic startup only after daily connectivity is stable. LAN sharing also requires an appropriate bind address and firewall rules, and should be limited to trusted networks.

Check each layer, from core startup and rule matching to system recovery

“The browser can open a webpage” proves only that part of the chain works. A complete migration also requires verifying subscription updates, expected rule results, proxy access for other applications, and network recovery after the client exits.

Layer 1: Is the configuration accepted by the core?

Start by reviewing the startup log. YAML indentation errors, duplicate fields, missing proxy-group references, failed rule-provider downloads, and port conflicts usually appear at this layer. When parsing fails, do not keep switching nodes; first locate the field name and line number in the log. If a local configuration loads but a subscription configuration does not, the problem is more likely in the subscription format or override process.

Layer 2: Are the nodes and DNS working?

Connection tests should examine both latency checks and real requests. A successful latency test does not mean every destination is reachable, because the test address, DNS result, rule path, and protocol handshake may differ. If domains fail while IP connections work, check DNS first. If every node times out, check the local network, firewall, subscription validity, and system time.

Layer 3: Are rules matching as expected?

Open the client’s connection log to see which rule matched the destination domain and which proxy group was ultimately used. If traffic goes direct unexpectedly, check whether a high-priority direct rule overrides later proxy rules. If all traffic uses the proxy, check whether global mode was selected by mistake or whether required direct rules are missing before MATCH. When using rule providers, also confirm that the remote files downloaded successfully and are referenced by the configuration.

Layer 4: Are the system proxy and TUN conflicting?

After TUN is enabled, some clients still retain the system proxy, which can cause duplicate interception or make troubleshooting confusing in certain environments. Follow the target client’s recommended combination. If only the browser works while other apps do not, the standard system proxy may be active but the target apps may ignore it. If enabling TUN cuts off all network access, check virtual-adapter permissions, auto-routing, DNS hijacking, and other VPN software.

Layer 5: Does the network recover after exit?

After quitting the new client, confirm that the system proxy is off, the browser can connect directly to permitted sites, and DNS is no longer pointed at an inactive local listening port. On Windows, check the system proxy page; on macOS, check proxy settings for the active network service; on Linux, check environment variables, desktop proxy settings, and systemd services according to the desktop environment and startup method. If connectivity remains unavailable, clear residual proxy settings first, then inspect the virtual adapter and routes.

Long-term maintenance after migration

Once the new client is stable, establish reliable maintenance sources. The client, proxy core, subscription, and rule database are four independent update channels; not every problem should be attributed to the client. Interface updates may change configuration management, core updates may add or alter fields, subscription updates change nodes and proxy groups, and rule-database updates affect domain and address classifications.

For everyday use, keep a simple emergency configuration and record the current stable version. Read the changelog before updating, then check core startup, subscription refresh, commonly used rules, and TUN in sequence. If continuity is important, postpone major-version changes and test them in a separate configuration first. The ultimate purpose of replacing the client is to build a verifiable, reversible configuration path—not to keep chasing interface changes or feature counts.

If you have not chosen a target client yet, start with this site’s client comparison and quick reference. Then choose based on your operating system, whether you need TUN, whether you maintain local rules, and whether you need LAN sharing. After installation, follow the usage tutorial to build a minimum working configuration; this is easier to troubleshoot than importing all old data at once.