Clash Client Discontinued? Alternatives in the mihomo client ecosystem

First, identify whether the client or the core was discontinued

Open the old client’s About screen and note the app name, app version, and core version before choosing what to replace. The client handles subscription imports, displays nodes, and starts the service. The core reads the config, matches rules, and establishes proxy connections. They are separate projects and may have different update statuses.

After the original Clash projects ceased public maintenance in 2023, existing installers did not automatically stop working. Your existing nodes may still connect, but that does not guarantee support for newer protocols, compatibility fixes, or future issue resolution. Clash for Windows, the original Clash for Android, and mihomo are not part of the same update track just because their names are similar.

mihomo is a proxy core continued from the Clash.Meta project. In older guides, “Meta core” usually refers to this development line, not a separate subscription service. The key to migrating is choosing a maintained client that runs mihomo, then moving your subscription and local settings separately.

Choose a migration path for Android or desktop

Choose by operating system, then check the project’s official release history, supported architectures, and core documentation. The options below are migration candidates in the mihomo ecosystem, not a guarantee that any particular legacy installer is still maintained. Project status can change, so check for recent releases and issue activity before installing. File modification dates alone are not a reliable indicator.

Android: migrate the config before routing traffic

If you’re used to the config, proxy, and log screens in the original Clash for Android, consider Clash Meta for Android. For a similar interface on your phone and computer, consider FlClash. Their menus, backup formats, and built-in settings differ, so don’t swap entire app data directories between them.

Most newer Android phones use ARM64, but a phone’s release year alone isn’t enough to tell. Check the device’s supported ABI (application binary interface) in the download documentation, and choose an ARM64 package only if arm64-v8a is supported. Check the Android version requirements in the release notes as well.

Desktop: test with the system proxy before trying TUN

On Windows or macOS, start by importing your subscription, choosing a node, and enabling only the system proxy to test in a browser. Clients such as Clash Nyanpasu that offer multiple core options also require you to confirm that mihomo is selected in core management. Don’t confuse the client version with the core version.

TUN is a virtual network interface that captures device traffic. It usually covers more traffic than changing the system proxy alone, but also involves routing, DNS, and system permissions. If the old client worked with the system proxy, use the same setup for your first migration test to avoid introducing multiple variables at once.

Back up these four items from the old client

1. Subscription source: Save the original subscription URL, update interval, and provider details. Subscription URLs often contain account tokens, so don’t put them in public notes, screenshots, or online conversion tools.
2. Config copy: Export the currently working YAML file. YAML uses indentation to represent structure, so preserve spaces when editing and don’t use tabs.
3. Local changes: Note any custom rules, overrides, scripts, and DNS settings. A client may merge these into the active config only when it starts, so copying the subscription file alone can leave them out.
4. System settings: Record the proxy port, LAN sharing toggle, per-app routing, and auto-start settings. Android app exclusion lists and desktop system proxy toggles are generally not part of a shared subscription.

If the old interface offers a “View runtime config” option, save a copy for reference, but don’t overwrite the new client’s entire working directory. Runtime configs may contain temporary paths, controller secrets, and expanded node passwords. They’re neither convenient to reuse across devices nor safe to share publicly when asking for help.

Config migration: check fields and name references one by one

On the new client’s subscription or config screen, add the config using the original URL if possible, then trigger an update manually. If you only have a local file, use an option such as “Import from file.” Labels vary by client; the important distinction is between a subscription source file and an app settings backup. They aren’t interchangeable.

Check proxy entries, groups, and rules together

• proxies contains nodes defined directly in the config; proxy-providers contains external node providers. If you use the latter, also confirm that the download URL is reachable and the local cache path is writable.
• proxy-groups defines policy groups, such as a manual selection group. Every referenced node, group, and provider name must exist, with matching capitalization and spaces.
• rules match connections in order. Earlier rules take precedence, so don’t put a broad MATCH rule before rules that still need to be checked.
• rule-providers references external rule sets. Check that type, behavior, and format match the actual file. A domain list is not automatically a complete classical rule set.

If you see “proxy group not found,” check the exact name in the error before changing nodes. A client override might rename “Proxy” to “Node Selection” while your custom rules still reference the old name, causing the config to fail to load.

Don’t copy ports and controller settings wholesale

mixed-port is the local port that accepts both HTTP and SOCKS proxy connections. external-controller is an API for the interface or management tools, not a proxy port. The snippet below is for local settings only; it is not a complete subscription config you can run as-is:

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

This example uses 7890, but that isn’t the default for every client. If a terminal previously connected to 127.0.0.1:7890 and the new client listens on 7897, update the terminal settings or change the port through a setting supported by the client.

Don’t copy external-controller, secret, external-ui, or absolute paths from an old file straight onto your phone. The new client may manage its own controller and resource directories. Changing the listen address to 0.0.0.0 can also expose the controller more widely. Unless you have a specific reason, keep the local settings managed by the app.

Handle DNS, TUN, and old scripts separately

DNS: start with the new client’s defaults

DNS translates domain names into IP addresses. If a node shows normal latency after migration but webpages won’t load, the issue may be a change in DNS resolution rather than an incompatible node protocol. Start with the new client’s recommended DNS settings. Once they work, migrate custom DNS servers one at a time.

fake-ip is a mode that assigns synthetic IPs to help route traffic. If the old config uses a range such as 198.18.0.1/16, don’t mistake those addresses for real node IPs. After changing DNS modes, establish a fresh test connection. If needed, restart the app or clear the system DNS cache so old results don’t affect your diagnosis.

TUN: don’t copy routing parameters between phone and desktop

Android clients typically capture traffic through Android’s VpnService API, which prompts for VPN permission the first time you connect. Desktop clients may require a helper service or administrator privileges. Both can route traffic, but their permission flows, routing implementations, and available options differ.

Check tun.stack, auto-route, and dns-hijack against the target client and operating system. Don’t copy a virtual network adapter name from an old desktop config into a phone config. On Android, also check Settings → Network & internet → VPN for settings left by the old app; some manufacturers put this under “Connection & sharing.”

Scripts: identify which layer runs them

script: in an old config, JavaScript overrides in an old interface, and third-party subscription conversion templates are different mechanisms. Don’t assume mihomo can run legacy Clash Premium scripts, or that desktop client override scripts can be imported directly into Android. Disable scripts first and establish a working baseline with standard rules. Then adapt only the necessary logic to rules or overrides explicitly supported by the target client.

Verify the migration in five steps

1. Check config loading: Open the logs and look for YAML indentation errors, unknown proxy types, or missing policy groups. If loading fails, fix the first error; later errors may be knock-on effects.
2. Check subscription updates: Trigger an update and verify the node count and account expiration. For HTTP 401 or 403 responses, check the token and access permissions first; these errors don’t indicate a proxy port conflict.
3. Test one node: Manually select a node in a policy group and run a connectivity test. A latency test reports only the result of its specific test request; it doesn’t prove that every site or protocol will work.
4. Check routing: Keep Rule mode enabled. Visit a destination expected to connect directly and one expected to use the proxy, then check the connections list for the matched rule, policy group, and selected node.
5. Check traffic capture: On desktop, test in both a browser and a terminal. On Android, test a browser and the target app, then check the connection again after locking and unlocking the screen.

For example, if the desktop HTTP proxy listens locally on 7890, use the command below to test a proxy request on its own. It affects only that request; it won’t enable the system proxy or confirm that TUN routing works.

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com/

The connection timeout is 10 seconds, with a total time limit of 20 seconds. These are troubleshooting parameters, not measured speeds. If the logs show address already in use, check whether the old service is still using the port. For no such host, check how the relevant domain is resolved. For context deadline exceeded, consider the destination and connection stage; don’t assume the subscription has expired.

Keep a rollback path and protect fixes from subscription updates

Once the first round of tests passes, restore auto-start, background operation, and custom rules. On Android, check Settings → Apps → the client → Battery for background restrictions; labels vary by system. If “Always-on VPN” or “Block connections without VPN” is enabled, make sure it points to the new client, or disabling the old app could cut off all network access.

After the next subscription update, check that your custom rules are still there. Edits made directly to subscription-generated YAML are usually overwritten on update. For persistent changes, use an override, merged config, or separate rule provider supported by the client, and verify the rule order in the final runtime config.

• Keep the old and new configs separately, with dates in their filenames to avoid confusion.
• Record the client version, mihomo core version, and reproduction steps to help track down compatibility issues.
• When asking for help, share only redacted logs. Remove subscription tokens, node passwords, and controller secrets.
• To roll back, turn off the new client’s system proxy or VPN before restoring the old service, so no stale routes remain.

A successful migration means more than opening the new interface: the subscription updates, rules match, target apps connect, and everything still works as expected after a restart or screen lock. Complete this basic test sequence before adjusting DNS, TUN, or complex overrides to keep troubleshooting focused.