How to Migrate After the Clash Client Is Discontinued: Exporting Configs, Choosing Alternatives, and Switching Subscriptions Seamlessly

First, recognize that migration involves more than an installer

After a Clash client stops being maintained, what really needs to move is the subscription entry point, local configuration, policy selections, and system proxy state. The old application itself is usually not worth carrying forward. Take Clash for Windows as an example: after development stopped, existing versions may continue to run temporarily, but the core, protocol support, OS compatibility, and security fixes will no longer advance. OS upgrades, subscription format changes, or certificate-policy updates can suddenly break a configuration that used to work.

Before migrating, distinguish the client from the core. The client handles configuration management, tray menus, the system proxy, logs, and the interface; the core listens on ports, parses rules, and establishes proxy connections. Newer clients commonly use the mihomo core, which inherits Clash Meta capabilities and supports more proxy protocols, rule sets, traffic sniffing, and a more complete TUN configuration. Most classic Clash configurations used by older clients can be imported into mihomo, but compatibility in the reverse direction is not guaranteed.

Four types of data to save

• Subscription URL: Save the original subscription link whenever possible instead of copying only the YAML generated by a subscription converter. The original link usually contains an access token and should be treated as sensitive information.
• Local configuration: This includes hand-written rules, proxy groups, DNS, TUN, rule-set URLs, and LAN access settings.
• Policy state: Record the current selection for frequently used proxy groups—for example, which node or sub-group is selected for “Node Select,” “Streaming,” and “Downloads.”
• Network parameters: Record the mixed port, controller port, system proxy toggle, bypass list, and LAN listening range.

Copying only node names is not enough. Nodes can be regenerated from a subscription, but hand-written rules, override scripts, proxy-group selections, and DNS exclusions are usually stored locally by the client. If a node passes latency testing but websites will not load after migration, these unsynchronized local settings are often the reason.

Exporting subscriptions and configs: the process while the old client still opens

Step 1: Record the subscription source and update schedule

Open the old client’s Config or Profiles page and record each configuration name, subscription URL, last-updated time, and automatic update interval. If the interface offers “Copy subscription link,” “Edit configuration,” or “Show in folder,” use those entry points first. Do not extract links from logs: tokens may be truncated, and the log may show a temporary URL after redirection.

Keep the migration record in a local text file with at least the following fields. Never upload the token portion to a publicly accessible cloud folder, code repository, or screenshot-sharing platform.

Configuration name: Daily rules
Subscription source: https://example.invalid/api/v1/client/subscribe?token=hidden
Old client update interval: 1440 minutes
Mode: rule
Mixed port: 7890
External controller port: 9090
Common policy: Node Select → Auto Select
Local overrides: dns.yaml, rules.yaml

Step 2: Export the active YAML

In the old client, find “Edit configuration,” “View configuration file,” or “Open configuration directory,” then copy the currently active YAML. On Windows, some older Clash clients store data under the user directory at .config/clash; older tools on macOS and Linux also commonly use ~/.config/clash. Different forks may use an application-data directory, so use the interface’s “Open directory” result as the source of truth rather than searching only a fixed path.

When backing up, save more than the main config: inspect the other resources referenced by that file as well. The following fields indicate dependencies on external files or remote content:

• proxy-providers: proxy providers that may reference a local file or remote subscription.
• rule-providers: rule-set providers that may use YAML, plain text, or MRS behavior format.
• script: script rules in the old config; before migrating, confirm that the new core still supports the same syntax.
• dns.nameserver-policy: domain-specific DNS policies; omitting them changes the resolution path.
• tun: virtual network interface, automatic routing, DNS hijacking, and strict-routing parameters.

Step 3: Save overrides instead of copying runtime caches

GeoIP databases, rule-set caches, subscription caches, and runtime logs can be downloaded again by the new client. What you really need to preserve is the override content edited by the user. If the old client offers “Global extension config,” “Mixin,” “Preprocessing,” “Overrides,” or “Scripts,” copy each item verbatim and record whether it runs before or after the main config. Different execution orders produce different final dns, rules, and proxy-groups results.

Choose a maintained client for your platform

When choosing an alternative client, do not compare interfaces alone. Check the OS version, core type, configuration import methods, TUN permission flow, and update channel first. For users with existing Clash configs, a client that uses the mihomo core, accepts URLs and local YAML files, and can show the actual runtime configuration usually offers a lower migration cost.

FlClash can serve as a migration target on Windows, macOS, Linux, and Android. It provides entry points for subscription configs, local configs, the system proxy, and TUN, making it suitable for moving an old Clash setup to a mihomo runtime. Before installing, check the OS and architecture listed on the download page—for example, Windows x64 or Linux x64/arm64—to avoid mistaking an architecture mismatch for a configuration error.

Do not let two clients control the network at the same time

When the old and new clients run simultaneously, port conflicts are the most common problem. Many Clash configs use 7890 for the HTTP, SOCKS, or mixed port, while external controllers commonly use 9090. If the old core is still listening, the new core’s log may show address already in use or a bind failure.

1. Disable the system proxy and TUN in the old client.
2. Exit the old client completely and confirm that its tray icon has disappeared.
3. On Windows, run netstat -ano | findstr :7890 in a terminal to check the port.
4. On macOS and Linux, run lsof -i :7890 to see which process is using the port.
5. Start the new client only after confirming that the port has been released.

If you must compare configurations in parallel for a short time, temporarily change the new client’s mixed port to 7891, but do not enable two system proxies or two TUN interfaces at once. Restore a unified port after testing so browsers, terminals, and development tools do not point to different cores.

Import into FlClash: subscription first, local YAML as a fallback

Import with a subscription URL

Launch FlClash, open the “Config” page, choose to add a config from a URL, paste the saved subscription address, and update it. After import, do not enable the system proxy immediately. First check whether the config generated nodes, proxy groups, and rules. A normal subscription should show proxy nodes, one or more policy groups, and a rule list; a config with nodes but no rules may be a node subscription rather than a complete Clash config.

Set the automatic update interval according to how often the subscription service changes. For everyday use, 1440 minutes—once a day—is a reasonable setting; if nodes change frequently, use 360 minutes. Short intervals increase request volume and may trigger rate limits. On migration day, update manually once first, confirm that the response is valid, and only then enable automatic updates.

Import a local YAML file

If the original subscription URL has expired but the old client can still display its current config, import the backed-up YAML first. Keep in mind that local YAML contains a snapshot of nodes and rules from the time it was exported; it cannot receive later server-side changes automatically. Once connectivity is restored, replace it with a valid subscription as soon as possible, or move the nodes and rules into a configuration you control.

Before importing, use mihomo’s config-check command to validate the syntax. If a standalone mihomo executable is available on the system, run this in a terminal:

mihomo -t -f ./config.yaml

A successful check only means the YAML can be parsed; it does not mean every remote rule set, node address, or DNS server is reachable. For an indentation error, confirm that the YAML uses spaces rather than tabs. For a duplicate-key error, check whether merging configs created two sibling dns or rules fields.

Verify configuration paths

After importing, open “Settings” → “Parameters” and check the run mode, mixed port, LAN access, and external-controller settings. The Config page controls subscription content; Parameters controls how the client runs. Keep the two separate. If the config explicitly contains mixed-port: 7890 while the interface specifies another port, follow the runtime config ultimately generated by the client and its logs.

Rules, DNS, and TUN checks after migration

Was the rule order preserved?

Clash evaluates rules from top to bottom and stops at the first match. Even when every rule survives migration, changing their order changes the result. Check the final rules so that LAN and direct domains are handled first, followed by service and proxy rules, with a fallback entry last. A typical structure looks like this:

rules:
  - DOMAIN-SUFFIX,example.cn,DIRECT
  - DOMAIN-KEYWORD,streaming,Streaming
  - GEOIP,CN,DIRECT
  - MATCH,Node Select

MATCH should be last. If it appears earlier, rules below it will never take effect. After migration, also verify that proxy-group names exactly match the third field of each rule, including spaces, capitalization, and non-ASCII characters. If a rule points to “Node Select” but the group was renamed to “Proxy Select,” the core will report that the policy cannot be found.

Does DNS still use the original operating mode?

Common mihomo DNS enhancement modes include fake-ip and redir-host. If the old client used fake-ip, do not switch modes in the new client without evaluating the impact. A typical Fake IP pool is 198.18.0.1/16, a range reserved for benchmarking rather than real public addresses. A domain resolving to 198.18.x.x does not by itself indicate a DNS failure.

Check these fields in particular:

• Is dns.enable set to true?
• Does enhanced-mode match the old configuration?
• Are nameserver and proxy-server-nameserver reachable on the current network?
• Does fake-ip-filter retain domains for LAN devices, time synchronization, game platforms, and printers?
• Does nameserver-policy still handle domains in mainland China and outside China as intended?

If only proxy-node domains fail to resolve after migration, check proxy-server-nameserver first. This field resolves the proxy servers’ own domain names and cannot rely on a proxy connection that has not been established yet, or it may create a resolution loop. During testing, search the logs for DNS, lookup, timeout, and the node domain name.

Enable TUN in stages

TUN takes over more traffic than the system proxy, including apps that ignore OS proxy settings. The first enablement on Windows may require administrator privileges and a virtual network adapter; macOS requires approval for a network extension; Android displays a VPN connection authorization prompt. During migration, prove that the regular system proxy works before enabling TUN.

After enabling it, check auto-route, strict-route, DNS hijacking, and interface selection. If LAN devices become unreachable, first check whether private ranges are being sent through the proxy by mistake. Common private ranges include 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. When an enterprise VPN runs alongside TUN, both may compete for the default route, so preserve direct access to required networks according to your organization’s requirements.

A seamless-switch verification checklist

“Import successful” only means that the client accepted the configuration. To complete the migration, verify the system proxy, rule matches, DNS, subscription updates, and restoration on exit. Follow the sequence below, moving on only after each step passes.

1. Core startup: The logs show no port conflict, YAML parse failure, or missing policy group.
2. Node test: Select a node with stable latency and run a TCP or URL test. The latency value only shows that the test target is reachable; it does not mean every website will be accessible.
3. System proxy: Enable the system proxy and confirm that browser traffic appears in the connection records.
4. Rule matching: Visit targets that should go direct and targets that should use the proxy, then check whether the policy-group names in the logs match expectations.
5. DNS check: Confirm there are no persistent resolution timeouts and that both LAN domains and commonly used sites resolve.
6. Subscription update: Run one manual update, record its duration and response status, and confirm that an empty response will not overwrite the config.
7. TUN test: After the system proxy passes, enable TUN and test apps that do not read system proxy settings.
8. Exit recovery: Exit the new client and confirm that the OS proxy settings are restored and the browser no longer points to the closed 127.0.0.1:7890.

Prevent traffic bypass during the switch

If your work environment requires all external traffic to pass through a proxy, do not rely on a “quick switch” and hope for the best. Disconnect applications that need protection or temporarily disable the network, load the config in the new client, enable the system proxy or TUN, and only then reconnect. Existing browser keep-alive connections, downloads, and messaging sessions will not necessarily reconnect through the proxy automatically, so restart the relevant apps deliberately.

On Android, check “Always-on VPN” and “Block connections without VPN” in the system VPN settings; the exact labels vary by manufacturer. On Windows and macOS, check whether the old client left a manual proxy behind after exiting. If the system proxy still points to 127.0.0.1 but no process is listening on that port, the usual result is that every browser page fails to load.

Common migration failures and fixes

Subscription update succeeds, but the node list is empty

First check whether the subscription response is a complete Clash YAML. Some services return different formats based on the User-Agent, or may return a login page, an error JSON response, or plain text containing only node links. Try a compatible request method in the new client’s subscription settings; if the service explicitly requires a dedicated User-Agent, configure it as instructed by the service. Do not mistake an account-center URL on the website for a subscription URL.

Nodes work, but all traffic goes direct

Confirm that the run mode is not direct, then open “Settings” → “Parameters” and check that the mode is Rule. Next, check that MATCH exists at the end of the rules and that its target proxy group currently selects DIRECT. Some configs remember policy-group state, while a new client may select the first option in the group on initial import; the two states may differ.

Web pages load, but command-line tools bypass the proxy

The system proxy mainly affects programs that honor OS settings. Command-line tools may require explicitly setting HTTP_PROXY, HTTPS_PROXY, or ALL_PROXY, or they can be handled through TUN. If the mixed port is 7890, set the proxy temporarily to http://127.0.0.1:7890 for testing. Clear the terminal environment variables afterward so commands do not keep targeting a dead port after the client exits.

LAN devices lose connectivity after enabling TUN

Disable TUN first to confirm whether route takeover caused the problem, then inspect the policy for printer, NAS, or router addresses in the connection records. Private ranges usually belong on DIRECT, but enterprise networks may use other ranges. Do not simply delete the entire TUN configuration; add direct rules for the actual networks and check for conflicts with strict routing or another VPN.

Can the old client be deleted after migration?

It is safer to uninstall the old client only after completing at least one subscription update, one system reboot, and one TUN test. Keep the YAML and subscription record before uninstalling, but do not leave the old client configured to start automatically. On Windows, check startup items under “Settings” → “Apps” → “Startup”; on macOS, check whether the old app is still allowed to run in the background under “System Settings” → “General” → “Login Items & Extensions.”

An actionable migration sequence

A simple configuration can usually be migrated in about 20 to 40 minutes; environments with custom rule sets, enterprise VPNs, and TUN should reserve additional testing time. Follow the sequence below to reduce rollback costs:

1. Copy the subscription URL from the old client and export the current YAML and all override files.
2. Record the mode, ports, policy-group selections, DNS mode, and TUN state.
3. Download the new client matching your OS architecture, and leave autostart disabled for now.
4. Disable the system proxy and TUN in the old client, then exit the old process completely.
5. Import the subscription URL into FlClash; if the URL is no longer valid, import the local YAML instead.
6. Check the proxy groups, rule count, DNS fields, and remote rule-set status.
7. Enable the system proxy first to verify browser access and rule matching, then enable TUN.
8. Update the subscription manually, reboot the system, and test everything once more.
9. Disable autostart for the old client, then uninstall it after the new client has proved stable.

The core of migration is not moving an old directory into a new one; it is rebuilding a verifiable configuration chain: the subscription updates, YAML parses in mihomo, rules point to existing policy groups, DNS resolves node and destination domains, and one client alone controls the system proxy and TUN. Once each item is confirmed, a discontinued client does not force users to recreate every rule or interrupt their existing subscription.