How to tell a client has stopped being maintained
Most clients in the Clash ecosystem are graphical shells built around the same underlying proxy core (originally Clash Premium, and now more often Clash Meta and its successor mihomo). The core handles rule matching, protocol parsing, and traffic forwarding, while the client handles config management, the UI, and platform integration. When a client's repository has gone months without a commit, the Releases page is stuck on an old version, and the issue tracker is piling up with unanswered compatibility reports, it's reasonable to conclude the project has been discontinued.
What matters more than the fact that it's discontinued is why. If the maintainer simply moved their effort to a successor project (often noted directly in the repo's README as "please migrate to XXX"), the migration path is usually smooth and the config format barely changes. But if the client became completely incompatible because of upstream core API changes, or was pulled for distribution-compliance reasons, you should be more cautious — it's better to switch to a replacement with a genuinely different architecture rather than keep waiting on the old client.
A few concrete signals help cross-check whether a client is really discontinued: the app can no longer fetch update notifications after long periods, its bundled rule-set update source keeps returning 404, or the developer has posted an explicit end-of-life notice in the community (Telegram group, Discord, or GitHub Discussions). Any single signal on its own could just be a temporary network hiccup or a misread, so it's worth confirming at least two of them before committing to a migration — otherwise you might move house during what turns out to be a brief lull, not an actual shutdown.
Check whether configs and subscriptions carry over as-is
The first step isn't to rush and uninstall the old client — it's to confirm whether your existing config file and subscription link will actually work on the new client. A Clash-family config is fundamentally YAML, and its core fields (proxies, proxy-groups, rules) are portable across nearly all clients, because they follow the core's spec rather than something a client invented on its own. What isn't portable are client-specific extensions. Common friction points include:
- Different clients support different versions of the
proxy-providersremote-provider syntax, with slightly different field names or required fields; - GUI clients often insert their own private fields at the top or bottom of the config (theme preference, tray-icon behavior, etc.); these are simply ignored on a new client and won't be carried over, though they don't affect proxy functionality either way;
- TUN mode implementation varies across core versions — the
tunfield structure used by older clients (for example, the accepted values forstack) has since changed on newer mihomo cores, so a straight copy-paste may need manual adjustment.
The subscription link itself usually needs no extra handling — the subscription URL simply returns a standard config or a Base64-encoded node list, and the client's role is just to fetch and parse it. Adding the same subscription URL in a different client works fine without any changes on the provider's side. What actually needs manual transfer are the local overrides and custom rules you set up in the old client — those live only on your device and are never included in the subscription feed itself.
Before migrating, export the full effective config from the old client — that is, the subscription content merged with your local overrides as it actually runs — rather than keeping only the subscription link. That way, even if the new client uses different override syntax, you can rebuild everything by hand against the original rules instead of trying to recall what you'd changed from memory.
Exporting local overrides and custom rules, step by step
Local overrides are a mechanism most Clash clients provide for adjusting the delivered config without touching the subscription source itself — adding custom rules, tweaking DNS settings, enabling TUN mode, changing the LAN listen port, and so on. This content exists only in the client's local storage, so it must be manually exported before switching clients, or you'll be reconfiguring every personalization from scratch. A sensible order to follow:
Locate the override file's physical path
Most clients store overrides as a separate YAML file in the config directory (usually alongside the cached subscription file) rather than writing them directly into the subscription file. Find that directory and copy it out — that's far more reliable than screenshotting each setting from the UI.
Separate rule overrides from parameter overrides
Rule overrides (custom DOMAIN, IP-CIDR entries) can usually be pasted wholesale into the equivalent section of the new client; parameter overrides (ports, DNS, TUN interface name) need to be re-entered against the new client's own field names, since UI labels and underlying field names don't always match one-to-one across clients.
Record any custom ordering inside proxy groups
If you manually reordered nodes within a proxy group or altered the grouping logic (rather than relying entirely on the subscription's default grouping), that information generally isn't stored in the override file at all — it lives in the client's UI state. Take a screenshot or write it down separately, then rebuild the order in the new client.
Back up the client's own runtime settings
This includes launch-on-startup, system proxy mode, mixed-port settings, and similar client-level preferences that have nothing to do with the proxy config itself — after migrating, you'll need to re-enable each of these individually in the new client.
Choosing an actively maintained replacement, by platform
When picking a replacement client, weigh two hard signals first: how active the repository's commit history is, and whether it keeps pace with the latest mihomo core releases. The core determines protocol support and rule-matching accuracy, so a client that lags behind may not support newer protocol parameters (for example, updated Hysteria2 options) at all. Desktop and mobile follow somewhat different logic, so it's worth separating them:
Windows / macOS / Linux desktop: the mainstream path right now is toward newer clients built on Tauri or similarly lightweight frameworks — they tend to use fewer resources, update more predictably, and typically bundle the latest mihomo core by default, so there's no need to manually swap core binaries. When migrating, confirm how the new client takes over the system proxy (PAC vs. direct system-proxy settings) and whether TUN mode requires installing an extra virtual network adapter driver.
Android: Android clients generally implement full-device proxying through the system's VpnService interface. After switching clients you'll need to re-grant VPN permission and check whether the new client needs to be re-added to the system's battery-optimization exemption list — otherwise it's prone to being killed in the background, causing silent disconnects. The per-app proxy list (which apps route through the proxy, by package name) also needs to be reconfigured in the new client, since it doesn't carry over automatically from the old one.
iOS: iOS clients are more constrained by App Store review policy, so before picking a replacement it's worth confirming the target client actually installs and can be granted Network Extension permission on your current iOS version. Config-file compatibility works the same as on desktop, and subscription links can be reused directly.
Don't pick a replacement based purely on download count or how polished the interface looks — check its repository's recent commit history and release cadence first. A plain-looking client with monthly updates is a far safer long-term bet than a beautifully designed one that hasn't shipped anything in six months.
A checklist to re-verify after migration is done
Once the config is imported into the new client, don't assume everything just carried over unchanged. These are the items most commonly missed in real migrations — the kind that leave things "looking fine but quietly wrong":
- DNS settings: the new client's default DNS policy may differ from the old one (for example, whether
fake-ipmode is enabled), which directly affects domain resolution and routing accuracy — check every field underdnsagainst your old config. - LAN and mixed-port settings: port numbers may reset to defaults on the new client; if your router or other devices depend on a fixed port to connect, restore the values you were using before migrating.
- Rule-set update sources: some clients bundle remote rule sets (GeoIP, GeoSite databases). After switching clients, these update URLs need to be reconfigured, or the rule set will stay frozen at whatever version shipped with the client initially and gradually go stale.
- Auto-speedtest parameters for proxy groups: url-test, fallback, and similar auto-switching groups rely on a test URL (
urlfield) and a check interval (interval). If the new client falls back to defaults here, it may no longer match values you'd previously tuned for your specific network conditions, affecting how sensitive automatic switching is. - Launch-on-startup and system-proxy takeover: this is the one most people forget — after finishing the functional migration, many people forget to re-enable launch-on-startup, then can't figure out why the proxy isn't active after a reboot.
It's worth keeping the old client installed on migration day rather than removing it immediately — run the new client for a day or two to confirm stability, then clean up the old version and its config directory. That way, if you discover a missed override later, you can still go back and check the original setting instead of trying to reconstruct it from memory.