Clash for Windows Discontinued: Alternatives and Migration to mihomo-based Clients

Migrate subscriptions and rules first, then restore the system proxy and TUN

Clash for Windows is no longer maintained. The goal of migration isn't to find an installer with an identical interface, but to move your subscription sources, custom rules, override logic, and system-level settings separately. Start by testing the new client's system proxy. Once you’ve confirmed that rules and DNS work as expected, enable TUN. Don't let two clients modify the system proxy or manage routes at the same time.

Clash for Windows is a graphical client; mihomo is a proxy core. They operate at different layers. mihomo retains the Clash configuration model while adding protocol and configuration capabilities. Clients built on this core may still differ in how they merge configurations, manage services, and expose script interfaces. A valid old YAML file doesn't mean every setting from the old client has been migrated.

How to choose a Clash for Windows alternative

Windows users can start by comparing Clash Verge Rev and Clash Nyanpasu. Both are graphical clients, but support for mihomo doesn't mean their configuration directories, override formats, or service components are interchangeable. Before downloading, verify the project name, latest release notes, OS requirements, and which core is actually enabled.

Choose based on the complexity of your existing configuration

• Using just one subscription? Focus on how easily you can import and update it, choose proxy groups, and view logs. Don't add migration steps for features you don't currently use.
• Have custom rules and overrides? Check whether rules can be inserted at the beginning, how global and subscription-level settings are merged, and whether you can inspect the final running configuration.
• Rely on TUN? Check service installation, administrator permissions, virtual network adapters, and compatibility with other VPNs. Being able to turn on TUN doesn't guarantee that all apps are routed correctly.

Don't identify a project by a similar-looking download filename or the UI version alone. The graphical client and core have separate version numbers; record both when troubleshooting compatibility. Find installers in the Download Center. This article doesn't recommend an old client installer as a migration destination.

Back up before migrating: separate the original subscription from the running config

Using the interface labels in the commonly used Clash for Windows 0.20.39 release as an example, first check the configuration sources under Profiles, then note your proxy group selections under Proxies, and finally review the ports, System Proxy, Allow LAN, and TUN status under General. The locations may differ in other versions, so don't rely on screenshots alone to find a setting.

1. Save your subscription source. Record the subscription URL, configuration name, update interval, and whether it goes through a conversion service. A token in the URL is an access credential—don't include it in log screenshots.
2. Save the subscription YAML. You'll need it to reimport the config and compare it offline. Saving only the URL won't preserve rules added locally afterward.
3. Save the final running configuration. It shows which fields actually took effect, but may include client-generated ports, control interface settings, and cache paths. Don't use it as-is to overwrite the new client's configuration.
4. Save Parsers, Mixin, and scripts separately. Note which changes apply only to a specific subscription and which apply to every configuration. Don't rely on a single YAML file that merely looks complete.
5. Record external dependencies. Include rule-providers, proxy-providers, local rule files, custom DNS settings, and control panel connection parameters.

Don't copy the entire old configuration directory over the new one. The client's database, cache, service state, and core cache may be incompatible. Move only configuration and rule files you've identified—not the old program's entire runtime environment.

Import the subscription: run the original config on its own first

1. Turn off System Proxy and TUN in the old client, quit the app, and make sure its service is no longer managing network traffic.
2. Open the new client and import the original subscription URL from its subscription or configuration management page. If you only have a local YAML file, import it as a local configuration; don't assume it will automatically get an update URL.
3. Leave custom overrides off for now. Update the subscription once, enable the configuration, and check that the proxies and proxy groups appear.
4. Set the mode to Rule and reselect proxies in your proxy groups. The old client's cached selections usually aren't carried over with the YAML file.
5. Check the local listening port, then enable the new client's system proxy and test a regular webpage and a site that should use the proxy.

Use the active port, not the one you remember

The old setup may have used 7890, while the new client may use a different port. Terminals, browser extensions, and developer tools that still point to the old address may fail even when the system proxy works. The snippet below overrides ports; it isn't a complete configuration. If the client manages ports through its UI, change them there instead.

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

mixed-port provides a shared HTTP and SOCKS listening port. In Windows PowerShell, use the command below to test a connection explicitly through the HTTP proxy. If the active port isn't 7890, use the value shown in the running configuration.

curl.exe --proxy http://127.0.0.1:7890 --head https://example.com/

This test only checks whether the specified proxy endpoint can handle one request. It doesn't verify TUN, rule behavior, or every app. If you get 407 Proxy Authentication Required, check local proxy authentication. If the connection to 127.0.0.1 fails, first check the port and whether the core is running.

Rules and override scripts: migrate the logic, not the interface

Clash for Windows Parsers and Mixin aren't the same interfaces as the merged configurations or script overrides in newer clients. JavaScript scripts are especially likely to differ in their input objects, entry functions, available APIs, and execution stages. Don't just change an old script's file extension and enable it, and don't assume a client script can access all browser or Node.js features.

Sort old customizations into three categories

• Field overrides: For example, log-level and allow-lan. Check whether the client manages these fields, then choose a UI setting or an override.
• List changes: For example, adding rules, DNS servers, or proxy group members. Check whether the new tool replaces the whole list or supports prepending and appending entries.
• Programmatic changes: For example, filtering proxies by name, renaming them in bulk, or generating proxy groups dynamically. Rewrite these for the target client's current script interface and compare the resulting configuration.

Rules are evaluated from top to bottom. If a company domain that should bypass the proxy is appended after MATCH, it won't match. The snippet below shows just two rules that should go before the fallback rule; it isn't a complete, standalone configuration:

rules:
  - DOMAIN-SUFFIX,corp.example,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve

corp.example is used here to demonstrate matching an internal domain; replace it with a domain you manage. Don't replace the subscription's entire rules list with these two lines. Instead, merge them using the target client's supported prepend-rule or script interface, and keep the existing rules and fallback policy.

Check rule providers and local paths together

The type, behavior, and format values in rule-providers must match the file contents. Old absolute paths may not work in the new installation directory; check relative paths against the working directory actually used by the new client's core. If you see an error such as proxy group not found, check that the policy group referenced on the right side of the rule exists, including matching spaces and capitalization.

DNS, TUN, and external control: restore these three groups last

DNS: preserve what each setting does, not every field

Compare dns.enable, enhanced-mode, nameserver, and fake-ip-filter with the old configuration. With Fake-IP, 198.18.0.0/16 is a common address range for mappings, not a remote proxy address. After switching cores or DNS modes, your browser or system may still have old results cached. Close and reopen the app you're testing; if needed, run ipconfig /flushdns on Windows.

Don't switch every DNS setting to public servers just to get rid of one resolution error. Company intranet domains may rely on internal DNS. During migration, test one internal domain and one public domain, then check the logs to confirm that requests follow the expected route.

TUN: check permissions before routing

Once the system proxy test passes, disable other VPNs or apps that manage virtual network adapters. Then install the service component or grant administrator permissions as required by the new client. Check the final values of tun.enable, stack, auto-route, and dns-hijack. Protocol stacks and system environments vary, so don't treat one stack value as a universal fix.

Test once with TUN off and once with it on: check webpages, internal sites, LAN devices, and apps that need UDP. A working webpage doesn't prove UDP forwarding works; that also depends on the proxy protocol, proxy server, and rules. If you lose connectivity, turn TUN off and return to the verified system proxy baseline before troubleshooting one setting at a time.

External control: don't expose the old listening address

If you use an external panel, check external-controller and secret again. For local access only, use a loopback address such as 127.0.0.1:9090. Don't expose the service on every network interface just to reconnect an old panel. Update the port and secret saved in the panel too. Desktop users generally don't need to expose the control interface to their LAN.

Can't connect after migration? Troubleshoot by symptom

When reporting an issue, include your OS version, client version, core version, time of the error, and minimal reproduction steps. Remove subscription URLs, proxy passwords, control secrets, and sensitive internal domains from configs and logs first. For more help, see the Help Center and Advanced Configuration.

Verify and roll back: update once, restart once

• The subscription updates successfully, all proxies and proxy groups are present, and custom rules haven't been overwritten.
• The mode is set as expected, commonly used proxy groups have been reselected, and the connection log shows the correct rule matches.
• Test the browser, terminal, and internal sites separately. If you need TUN, also test LAN access and UDP apps.
• Ports and overrides remain correct after restarting the client; after restarting the system, services and startup behavior work as expected.
• System Proxy, TUN, and auto-start are all disabled in the old client. Neither app is changing system settings back and forth.

To roll back, first turn off System Proxy and TUN in the new client, then quit the app and its services before restoring the old setup. Don't run both clients with system-level traffic management enabled for comparison. Once migration is verified, remove the old program and keep a sanitized migration note with the subscription source, override file locations, and final ports for your next device change.