How to Migrate After a Clash Client Is Discontinued: Preserve Your Configuration and Choose an Alternative

Separate the client, core, and configuration first

When a Clash client is no longer maintained, that does not mean your existing subscription and YAML configuration stop working at the same time. Before migrating, the most important step is to understand the graphical interface, proxy core, configuration files, and subscription service as separate components. The graphical client downloads configurations, switches proxy groups, controls the system proxy, and displays connection logs. The core parses rules, establishes proxy connections, and handles network functions such as DNS and TUN. The configuration file stores the relationships among ports, proxies, proxy groups, and rules.

Some legacy desktop clients use an early Clash core, while others have moved to Clash Meta, now commonly known as the Mihomo core. Mihomo retains the Clash configuration model while adding support for more protocols, rule providers, DNS features, and traffic interception capabilities. When moving to a Mihomo client, standard sections such as proxies, proxy-groups, rules, and proxy-providers can usually continue to be used. However, interface settings, scripts, databases, and service installation state specific to the old client are not portable configuration and should not be copied as-is.

The goal of migration is therefore not to move the old program directory wholesale. Instead, keep the data that can be reused across clients and let the new client recreate its runtime environment. This avoids problems caused by stale caches, obsolete databases, locked ports, and leftover drivers.

What to back up before migrating

Do not wait until after uninstalling the old client to look for its configuration. Some applications store configuration in the user data directory, and uninstalling them may also remove application data. Keep the old client working long enough to complete the backups below before switching between the old and new programs.

Subscription URLs and configuration files

If the configuration comes from a subscription, record the original subscription URL first and confirm that it still updates successfully. The configuration name shown in the client is only a local label and cannot replace the subscription URL. If the service provides a dedicated conversion link, also record how the original subscription relates to the conversion rules so the migration does not produce a configuration in an unexpected format.

For manually maintained configurations, export the complete YAML file instead of copying only the proxy section. Proxy groups reference proxy names or provider names, and rules reference proxy groups; keeping only the proxies section breaks this chain of references. If the configuration refers to local rule providers, scripts, or override files, copy those files as well.

Local overrides and custom rules

Many clients provide override features in addition to subscription configuration, such as forcing DNS settings, appending rules, changing listening ports, or enabling LAN access. These settings may be stored in the client database and are not written back to the subscription YAML. Before migrating, review pages labeled “Overrides,” “Global Extensions,” “Merge Configuration,” or similar, and record the settings that are actually in effect.

Preserve rule order. Clash rules are normally evaluated from top to bottom, and processing stops when a connection matches the first rule. If a custom direct-connection rule is appended after MATCH, it will never take effect. Even when the rule text is identical, changing its position during migration can produce different routing results.

Ports, LAN access, and the control interface

Record the old client’s mixed-port, HTTP port, SOCKS port, LAN access setting, and external controller address. Browser extensions, shell environment variables, download tools, and other applications may still point to the old ports. If the new client assigns ports randomly while external programs continue connecting to the old ports, you may see the client working normally while some applications cannot connect to the internet.

external-controller and the control secret are mainly used by the graphical interface or external panels. Do not copy them directly into a parallel instance that already occupies the same port. When running old and new clients at the same time, make sure they do not listen on the same proxy port.

How to store sensitive information

Subscription URLs often contain access parameters that identify an account, and complete YAML files may include server addresses, authentication details, and control secrets. Store backups in a controlled directory; do not paste their full contents into public support threads, screenshots, or public code repositories. When sharing an error, keep the field structure but remove authentication values.

Recommended Clash configuration migration steps

1. Update and export the old configuration.Run a subscription update in the old client, confirm that the proxy groups and proxy list load correctly, then save the subscription URL, YAML file, and custom rules.
2. Record the current network settings.Save the proxy ports, system-proxy status, TUN status, DNS mode, and LAN switch state. If the terminal has separate proxy environment variables, record the ports used by those variables as well.
3. Disable traffic interception in the old client.Turn off the system proxy and TUN first, then exit the old client completely. Closing the window may not stop the background core, so confirm in Task Manager or Activity Monitor that the process has ended.
4. Install and launch the new client.Use the default settings on first launch; do not immediately copy the old client’s entire data directory. Confirm that the new client’s core runs normally before importing the configuration.
5. Re-add the subscription first.If the subscription is still valid, add its URL again in the new client. This is usually more reliable than copying cached files. For a manual configuration, import the local file and preserve the relative paths of associated files.
6. Reapply overrides.Configure DNS, ports, custom rules, and providers using the format supported by the new client. Override syntax is not necessarily compatible between clients, and a file extension alone is not enough to determine compatibility.
7. Test the regular proxy before enabling TUN.Use the system proxy to test websites and connection logs first, confirming that proxies, proxy groups, and rules work as expected. Then enable TUN separately. Staged testing makes it easier to determine whether a problem comes from the configuration or traffic interception.
8. Remove the old client only after the new setup is stable.Keep a backup of the old configuration for a while, but do not let two clients modify the system proxy or control the default route at the same time.

A portable base configuration usually has clear reference relationships. The example below omits specific proxies, uses a provider to supply them, and lets proxy groups and rules reference that provider:

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

proxy-providers:
  provider-main:
    type: http
    url: "https://example.com/profile.yaml"
    path: ./providers/main.yaml
    interval: 86400
    health-check:
      enable: true
      url: "https://www.gstatic.com/generate_204"
      interval: 600

proxy-groups:
  - name: PROXY
    type: select
    use:
      - provider-main

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

If the imported configuration reports “Provider not found” or shows empty proxy groups, check the provider name, download status, and the use reference in the proxy group in that order. When file paths are resolved relative to the configuration file, moving the YAML without moving its rule providers or provider cache can also cause loading to fail. For remote providers, the new client can download the cache again; there is no need to force-copy it from the old database.

How to choose an alternative client for each platform

Do not choose an alternative based only on interface similarity. More useful criteria include whether it is actively maintained, which core it uses, whether it can import your existing configuration, whether it supports the system proxy and TUN, whether its logs support troubleshooting, and whether its installer matches your operating system and processor architecture. Clients using the Mihomo core can usually continue to use mainstream Clash rule structures, but the interface workflows will differ.

Windows

Windows users should prioritize actively maintained desktop clients that clearly identify the Mihomo core and support service mode or TUN management. The system proxy is enough for ordinary websites and most desktop software. Games, command-line programs, and applications that ignore the system proxy may require TUN. Enabling TUN often involves administrator permissions, network adapters, and system services, so complete regular proxy testing first.

Also verify the installer architecture. Most modern computers use x64, while Windows on ARM devices may require an arm64 build. If the system proxy switch cannot be restored during migration, exit all proxy clients first, then check Windows proxy settings to see whether the manual proxy still points to an old port.

macOS

Choose a macOS alternative that matches your Apple silicon or Intel processor. Apple silicon generally uses an arm64 or universal build, while Intel devices use an x64 build. On first launch, macOS may ask you to approve a network extension, helper service, or VPN configuration. These permissions belong to the TUN interception workflow, not to the YAML configuration.

After migrating from an old client, the menu bar may show that the proxy is enabled while applications still connect directly. Check whether the system proxy was written to the active network service correctly. macOS may have Wi-Fi, Ethernet, and other network services at the same time. If the client modified a different service from the one currently in use, the proxy can appear enabled while traffic bypasses the core.

Android

Clash-style clients on Android usually intercept traffic through the system VPN interface rather than the desktop system proxy. Migration focuses on importing the subscription again, allowing the VPN connection to be created, and checking per-app proxying, bypass settings, and background battery restrictions. An app-routing list exported by the old client may not be recognized by the new one, so choose again which apps should use the proxy.

If the device already has another VPN, ad blocker, or work-profile network active, the system generally cannot run multiple ordinary VPN interfaces at once. Stop other VPN services before testing the new client. Android packages must also match processor architectures such as arm64-v8a. When unsure, choose the official universal build, though it is usually larger.

Linux

Linux users can choose a graphical client or run the Mihomo core directly with systemd management. A desktop environment’s system proxy affects only programs that honor that setting; terminal tools may still require the http_proxy, https_proxy, and all_proxy environment variables. With TUN enabled, also check core permissions, the routing table, and how DNS is managed.

When moving from a graphical client to a command-line core, preserve the relative directories referenced by the configuration and define the working directory explicitly. The same YAML file can resolve external rule files and provider paths differently when launched from different directories. Put the configuration, providers, and rule sets in fixed directories, then specify the configuration path explicitly in the service parameters.

iPhone and iPad

iOS and iPadOS cannot directly install desktop or Android Clash clients. Choose a network tool that is permitted on the platform and supports the required protocols and rule format, then convert the configuration according to its import capabilities. Not every iOS client can read Clash YAML unchanged; proxy groups, scripts, rule providers, and DNS fields may need adjustment based on the target app’s documentation. Before migrating, confirm that the subscription service offers the required format. This is more reliable than copying proxies manually.

Checking subscription, rule, and DNS compatibility

A configuration importing successfully only means that the YAML syntax passed; it does not mean every connection will route as expected. After migration, check five areas: subscription updates, proxy connectivity, proxy-group references, rule matches, and DNS resolution.

Subscription update failures

First determine whether the error occurs during downloading or parsing. Download timeouts are usually related to the network, subscription URL, or proxy loop. Parsing failures may mean the response is not YAML, the subscription conversion format is invalid, or the configuration contains fields that the current core does not recognize. If the client supports updating subscriptions through a proxy, use that option carefully on first launch: without a working proxy, it can create a dependency loop.

Rule provider loading failures

The old configuration may reference remote rule providers through rule-providers. After migration, check the behavior type, format, URL, storage path, and the reference names used in the rules. Rule-provider names and proxy-group names are separate concepts and cannot be interchanged. When using GEOIP or GEOSITE rules, also confirm that the client can download and load the required geographic databases.

Changed DNS behavior

The old and new clients may use different default DNS settings. With fake-ip enabled, the core returns reserved addresses to applications and uses an internal mapping to handle the real connections; redir-host follows a different resolution path. Do not copy the entire DNS section blindly before understanding the old settings. In particular, check the listen address, upstream servers, fallback rules, and Fake IP filter list.

If websites intermittently fail to open, LAN device hostnames stop resolving, or some applications have trouble signing in, temporarily disable custom DNS overrides and test again with the new client’s defaults. If the default configuration works, restore the old settings one at a time. Changing multiple DNS fields at once removes the comparison needed for troubleshooting.

TUN migration and common failures

TUN mode creates a virtual network interface and uses routes or a system network extension to send more traffic through the core. It can cover applications that ignore the system proxy, but it relies more heavily on operating-system permissions than a regular system proxy. Do not copy the old client’s TUN driver, service registration, or route state into the new client.

The correct order is to disable TUN in the old client, exit it completely, and confirm that the virtual interface is no longer active. Then let the new client install its service or request permissions through its own workflow. Enabling TUN in both clients at once can cause default-route conflicts, repeated DNS changes, network loops, or a complete loss of connectivity.

The internet stops working completely after enabling TUN

• Check whether the current proxy group has selected a working proxy and whether the final rule points to an existing proxy group.
• Check whether another VPN, proxy tool, or network-filtering program is still occupying or modifying the route.
• Confirm that the client service has the required permissions and that no error occurred while creating the virtual interface.
• Temporarily disable custom DNS and complex routing settings, then test with the client’s default TUN configuration.
• After disabling TUN, confirm that the regular system proxy still works to distinguish a proxy-node problem from a traffic-interception problem.

The browser works but the terminal does not

This usually means the browser uses the system proxy while the terminal program does not. Configure the terminal tool to connect explicitly to the new client’s HTTP or SOCKS port, or enable a correctly configured TUN. After migration, update the old ports in your environment variables as well; changing the listening port in the graphical client does not automatically update your shell configuration.

The proxy still appears enabled after closing the client

If the client exits unexpectedly, the system proxy may not be restored. First disable the manual proxy in the operating system’s network settings, then restart the new client. Do not repeatedly launch multiple old clients to compete for control of the system proxy; this makes the active configuration harder to identify. If a TUN service is still running in the background, stop it through the new client’s service-management controls. Restart the system if necessary to clear temporary routes.

Post-migration verification checklist

Do not judge a migration complete merely because a webpage opens. A complete verification should include at least the following checks:

• The subscription can be updated manually, and custom rules remain after the update.
• The expected proxies appear in the proxy group, and latency tests or health checks run successfully.
• When visiting different types of sites, connection logs match the expected rules and proxy policies.
• With the system proxy disabled, traffic returns to a direct connection; when it is enabled again, the port matches the client.
• Enabling and disabling TUN leaves no abnormal routes, and LAN access follows the configuration.
• The terminal, browser, and standalone applications that require a proxy all use the correct port.
• After restarting the operating system, the client starts as expected and its configuration and permissions remain valid.
• The old client has exited and no longer starts automatically or modifies the system proxy.

Once the setup is stable, uninstall the old client and keep one organized configuration backup. The backup should state its creation date, compatible core, and dependent files so you can identify its source months later. Subscription configurations should continue to update through the client, while local custom rules should be saved separately to reduce the risk of losing them when a subscription is overwritten.

The key to client migration is not copying more files, but distinguishing reusable Clash configuration data from state owned by the old program. Back up subscriptions and rules first, then verify the system proxy, DNS, and TUN in stages to keep the risks of switching from a discontinued client within a diagnosable range.