What to Do After Clash for Windows Is Discontinued: A Complete Migration Guide to mihomo Clients

First determine whether you need to migrate the client, the subscription, or the local configuration

After Clash for Windows was discontinued, existing installations did not stop working immediately. As long as the subscription URL remains reachable and the current core still supports the node protocols, the old client can usually load the configuration and route traffic. The real issue is that once the core stops receiving updates, new protocol fields, rule syntax, DNS behavior, and system compatibility no longer keep pace. Keeping the old version is reasonable as a short-term fallback, but not as a long-term configuration platform.

Before migrating, separate the data into three categories. The client is the graphical interface and system integration layer; the subscription is the entry point for server-generated configuration; and the local YAML may contain custom nodes, rules, DNS settings, and TUN parameters. These should not be handled as one file. If you only use a subscription, migration usually requires saving just the subscription URL. If you have custom rules or overrides, export the configuration separately and record the device-specific settings.

What to save before migrating

• The original subscription URL, along with the subscription name, last update time, and remaining traffic quota.
• The YAML file currently in use—do not rely on client screenshots alone.
• The manually selected nodes in each policy group, such as which nodes are currently selected for “Node Selection,” “Streaming,” and “Downloads.”
• Local overrides, including DNS, TUN, appended rules, addresses that bypass the proxy, and per-application routing lists.
• The system proxy ports. A common mixed port is 7890, and the control port is often 9090, but use the actual values from the old configuration.

Find the configuration in Clash for Windows

In Clash for Windows, open “Profiles” first and confirm the name of the active configuration. For a subscription profile, record the subscription URL shown on the page; for a local configuration, use the configuration menu to open its containing folder. A common data directory is %USERPROFILE%\.config\clash, but portable builds, a custom Home Directory, and different distributions may use another path. Follow the directory displayed by the client.

When copying the directory, pay particular attention to config.yaml, subscription-generated YAML files, Provider caches, and custom scripts. Cache files are not essential to the migration; the new mihomo client will download proxy providers and rule sets again. Preserve the original configuration and the URL that can retrieve it again.

Choose a mihomo client by checking its core and system capabilities

Migration does not mean finding a Clash for Windows clone with an identical interface. A more reliable approach is to verify the core first, then examine system takeover and configuration management. Desktop clients need system proxy support, TUN, startup launch, and configuration updates; Android clients need Android VPN permissions, per-app routing, background operation, and battery-policy compatibility.

What to verify on desktop

1. Core information is visible: The “Settings” or “About” page confirms that mihomo is in use and shows the exact version.
2. Configuration errors are specific: When an import fails, the client should identify the YAML line or field instead of merely reporting that startup failed.
3. System proxy is configurable: The client can set HTTP, SOCKS, or Mixed ports; a common default is 7890.
4. TUN status is visible: The client shows whether the virtual network adapter was created and reports administrator permission or service-installation status.
5. Overrides are separate from subscriptions: Updating a subscription should not overwrite local port, DNS, and TUN changes in their entirety.

What to verify on Android

• Supports mihomo configurations and can import a remote subscription or local YAML file.
• Takes over traffic through Android’s VPN interface; a system VPN permission dialog appears when it starts.
• Provides an entry such as “Settings” → “Network” or “Settings” → “Overrides” for adjusting DNS, IPv6, the TUN stack, and MTU.
• Supports per-app proxying, allowing you to proxy only selected apps or exclude specific apps.
• The log page can show connection targets, matched rules, policy groups, and outbound nodes.

Client interface labels may vary, but core capabilities should be judged by the actual version and configuration tests. After importing, look for mihomo startup messages in the log, then open a webpage and confirm that the connection record shows the target domain, matched rule, and outbound policy. Seeing only “Connected” in the interface does not prove that DNS and the rule chain are working correctly.

Migrate the subscription by importing the original URL

If you only use a provider subscription, the safest approach is not to copy the generated config.yaml from Clash for Windows, but to add the original subscription URL again in the new client. On desktop, this is usually done through “Profiles” → “New” → “URL”; on Android mihomo clients, use “Profiles” → “+” in the top-right corner → “Import from URL.” Enter a name, update it once immediately, and then check the policy groups and node count.

1. In the old client, record the subscription update time, node count, and the names of the main policy groups.
2. Add the same subscription URL in the new client and set an update interval, such as 1440 minutes.
3. After the update finishes, select the configuration and wait for the core to reload it.
4. Open the “Proxies” page and confirm that GLOBAL, DIRECT, REJECT, and custom policy groups are displayed correctly.
5. Test at least two nodes one after another, recording latency and actual connectivity.

Latency is useful only for an initial shortlist. A node showing 42 ms is not necessarily faster for downloads than one showing 95 ms. For migration acceptance testing, perform three concrete checks: whether a webpage opens within 2 seconds, whether continuous 1080p playback buffers frequently, and whether the stable speed for the same test file is noticeably lower than before migration. If every node fails, check DNS, the system proxy, and TUN first instead of repeatedly changing subscriptions.

Why copying generated configuration is not recommended long term

A generated configuration reflects one subscription update. Node addresses, certificate parameters, policy groups, and rules may all change later. Copying it can provide a temporary recovery path, but it will not receive future updates automatically. If the configuration also contains proxy-providers or rule-providers, make sure the Provider URLs remain valid and that the new client can recreate the local cache paths.

Migrate local YAML: validate first, then update device-specific fields

mihomo is highly compatible with classic Clash configurations, so common sections such as proxies, proxy-groups, rules, proxy-providers, and rule-providers can usually remain in use. Do not begin by rewriting the syntax extensively. Keep a copy of the original, import it directly, and read the first explicit error. Change one category of fields at a time to make troubleshooting easier.

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

external-controller: 127.0.0.1:9090

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16

proxy-groups:
  - name: Node Selection
    type: select
    proxies:
      - Auto Select
      - DIRECT

rules:
  - GEOIP,CN,DIRECT
  - MATCH,Node Selection

The example uses 7890 as the Mixed inbound port, 9090 as the external control port, and 1053 for the DNS listener. These values may work on a desktop, but they should not be copied mechanically to every device. Android clients usually manage the VPN inbound connection and control interface themselves, so manually configured listen addresses may conflict with built-in services.

Fields that can usually be kept unchanged

• Node protocol parameters in proxies that are supported by the current mihomo version.
• The select, url-test, fallback, and load-balance structures in proxy-groups.
• Domains, IPs, processes, and rule-set references in rules; process rules are affected by system permissions.
• Remote URLs, update intervals, and health-check behavior for proxy-providers and rule-providers.
• DNS nameserver, fallback, nameserver-policy, and fake-ip-filter rules.

Fields to check or rewrite for each device

• external-controller: It is best restricted to 127.0.0.1. If an old configuration listens on 0.0.0.0:9090, the control interface is exposed to the local network.
• secret: Set a separate value when enabling remote control, and enter the same value in the corresponding panel connection settings.
• interface-name: Windows, Linux, and Android use different network interface names, so after migration you usually need to remove the old value or select the correct interface again.
• routing-mark: This is mainly used for policy routing on Linux and has no equivalent effect when copied to Windows or Android.
• tun: Supported stacks, auto-routing behavior, and DNS hijacking methods differ between platforms.
• Local Provider path: A Windows path such as C:\Users\... cannot be used on Android. Replace it with a relative path or let the client manage it.

Do not copy the entire TUN configuration across platforms

tun:
  enable: true
  stack: mixed
  auto-route: true
  strict-route: true
  dns-hijack:
    - any:53

Desktop TUN generally requires administrator privileges or a system service; Android relies on the system VPN interface. A single Android device can maintain only one primary VPN takeover tool at a time. If another VPN, a corporate work-profile VPN, or a local firewall is running, the mihomo client may be unable to create its interface.

If webpages open after migration but apps cannot connect, temporarily switch the TUN stack from system to mixed or gvisor under “Settings” → “Network” and compare the results. Then check the per-app proxy list. Fully stop and restart the service after switching to prevent the old virtual-interface state from affecting the test.

The right layering for consistent desktop and Android configurations

Consistency across devices does not mean using exactly the same YAML file everywhere. A better structure is to treat nodes, remote rules, and policy groups as the shared layer, while ports, TUN, LAN access, per-app routing, and system permissions belong to the device layer. Update the shared layer through subscriptions or Providers, and keep the device layer in each client’s override feature.

Content suitable for sharing across devices

• Node subscriptions and proxy-providers.
• Policy group names and their basic selection logic.
• Domain rules, IP rules, and remote rule-providers.
• DNS upstreams and domain-routing policies.
• Common direct, reject, and proxy rules.

Content to maintain separately on each device

• Desktop Mixed, HTTP, SOCKS, and control ports.
• Whether LAN devices may connect, along with the listen address.
• Windows service mode, startup launch, and TUN driver status.
• Android per-app proxying, persistent VPN operation, battery optimization, and mobile-network behavior.
• Whether IPv6 is enabled, the MTU value, and the specific TUN stack.

For example, a desktop can keep mixed-port: 7890 so a browser or development tool can connect manually to 127.0.0.1:7890. Android does not require other apps to enter this port; the VPN interface takes over traffic centrally. Treating the desktop port as a “required setting” across devices can cause Android startup conflicts or create ineffective configuration.

Policy group selections do not sync automatically

Even when desktop and Android use the same subscription, a node selected locally in one client usually will not sync automatically. Setting “Node Selection” to a Hong Kong node on desktop will not make the phone select that same node immediately. For more consistent behavior across devices, have the main policy group reference a url-test automatic latency-testing group with a sensible test URL, interval, and tolerance.

proxy-groups:
  - name: Auto Select
    type: url-test
    use:
      - provider-main
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

  - name: Node Selection
    type: select
    proxies:
      - Auto Select
      - DIRECT

Here, interval: 300 means testing every 300 seconds, while tolerance: 50 reduces frequent switching when the latency difference is no more than 50 ms. The test URL should be stable and return a small response. Results can still vary between networks, so a phone on cellular data may not select the same node as a desktop on broadband.

Post-migration verification order and common problems

After migration, do not check only one webpage. Verify the configuration load, DNS, rule matching, node connectivity, and system takeover in that order. This helps identify whether the problem is configuration parsing, name resolution, policy selection, or the virtual network adapter.

1. Configuration loading: The log contains no YAML parsing errors, duplicate ports, or failed Provider downloads.
2. DNS resolution: Domain requests return results without repeated timeouts, SERVFAIL errors, or query loops.
3. Rule matching: When visiting common sites, connection records show the expected rule and policy group.
4. Node connectivity: Test at least two nodes in different regions to rule out a single-node failure.
5. System takeover: Disabling the system proxy or stopping the VPN changes the network path as expected, and restarting restores it.

Import succeeds, but every node times out

First check the system time on the phone or computer; certificate handshakes are sensitive to clock differences. Then update the subscription and make sure the node parameters are not from an old cache. If domain-based nodes time out while IP-based nodes work, focus on DNS. If the log shows connection refused, the node’s service port may be unreachable; with i/o timeout, also investigate the local network, routing, and firewall.

Some apps cannot connect in Rule mode

Temporarily switch to Global mode only for diagnosis. If Global works but Rule does not, the issue is usually in the rules, policy groups, or rule-set updates. Check that the policy group referenced by the final MATCH exists, then confirm that the group has a working node selected. After diagnosis, switch back to Rule instead of hiding rule errors behind Global mode.

Android stops the client soon after startup

Open Android “Settings” → “Apps” → the relevant client → “Battery,” then allow background activity or choose “Unrestricted.” Also check the connection status under “Settings” → “Network & internet” → “VPN.” Menu names vary by manufacturer. If Always-on VPN is enabled, make sure another VPN app has not been assigned the same role.

Local rules disappear after a subscription update

This means the changes were written directly into the subscription-generated file and the update replaced the entire configuration. Restore the original subscription and move device rules into the client’s overrides, a merged configuration, or a separate Provider. Let the shared subscription update nodes and use local overrides for fixed settings; separating the two makes ongoing maintenance possible.

How to maintain the setup after migration

After migrating, record the client version, mihomo core version, subscription update interval, and key overrides. When a problem appears, first compare the times of the latest client update, core update, and subscription update; this usually narrows the scope quickly. The client UI version and core version are separate concepts, so when investigating protocol or rule behavior, record the core version first.

Keep the configuration readable as well. Use stable policy group names, organize rules by purpose, and give Providers clear update intervals. Before making changes, copy a known-good version; when adjusting DNS, TUN, or rule sets, change only one module at a time and verify the result in the log. This way, even if you later switch to another mihomo client, the shared configuration can continue to work.

For most users, migration can be reduced to three steps: save the subscription and old YAML, choose a maintained mihomo client, and configure desktop and Android device parameters separately. The subscription updates nodes, shared rules make traffic decisions, and local overrides handle system differences. Managing these boundaries is more stable and easier to troubleshoot than copying the entire old directory.