Clash for Windows Discontinued: Alternatives and How to Switch to Clash Verge Rev

What to prioritize after discontinuation: config sources, core, and traffic routing

Clash for Windows (CFW) no longer receives updates, but existing installations won't stop working overnight. However, its interface, dependencies, and core are no longer updated for today's network environments. A typical CFW 0.20.39 installation may still handle existing subscriptions, but a working connection doesn't make it a good long-term setup. The goal of migration is to keep reusable configuration and verify exactly what the new client loads.

It helps to separate three layers: the client handles subscription management, the system tray, and OS integration; the core parses config, matches rules, and makes connections; and subscriptions provide nodes, proxy groups, and sometimes rules. Switching clients doesn't necessarily mean switching subscriptions, but changing cores means reviewing legacy fields, scripts, and DNS behavior.

• Config sources: Record your subscription URLs, current local YAML files, and which settings come from subscriptions versus local overrides.
• Core differences: Clash Verge Rev uses mihomo, the name adopted by the successor to the original Clash.Meta project. It's not simply a new shell around the old CFW interface.
• Traffic routing: System proxy, TUN, and HTTP/SOCKS proxies configured directly in apps are three different ways to route traffic. A single toggle can't confirm a successful migration.

Comparing alternatives: Clash Verge Rev and other options

If you mainly need subscription imports, proxy selection, logs, and TUN on a Windows desktop, Clash Verge Rev is a straightforward migration path. For similar configs across desktop systems, consider its macOS and Linux versions as well. Mobile devices need clients built for their operating systems; desktop installers won't work directly on Android or iOS.

Config semantics may be compatible; the entire config directory isn't

Common fields like proxies, proxy-groups, and rules can serve as a starting point, but client UI state, subscription databases, and service installation details aren't portable. Don't copy the entire CFW data directory over the Clash Verge Rev directory, or copy old core executables into the new client directory.

CFW Parsers, client-side scripts, and Clash Premium script rules are different things. Parsers belong to the client's processing pipeline, while script rules depend on core capabilities; don't assume either will run unchanged in mihomo. Simple domain routing can be converted to standard rules. For complex scripts, verify an equivalent implementation for each one instead of just changing the file extension.

Back up before migrating: what to save beyond subscriptions

In CFW, open the General page and use Home Directory to find the actual data directory. Many older installations use .config/clash in the user directory, but portable mode and custom paths can differ, so use the location shown by your installation. Quit the app before backing up to avoid copying files while they're being written.

1. Save subscription details: Record the name and original URL of each subscription in Profiles. Subscription URLs often contain access credentials, so keep them in your private backup. Don't paste them into public support tickets, screenshots, or online conversion tools.
2. Save local config: Copy the YAML file in use, along with any rules, rule providers, and scripts you maintain. Note any subscription cache files you've edited directly; those changes may be overwritten during updates.
3. Record runtime settings: Include proxy mode, HTTP/SOCKS or mixed port, LAN access, DNS, TUN, and the control API address. Don't treat the control API secret as a proxy credential to migrate.
4. Record selected proxies: Note the node or subgroup currently selected in each important proxy group. Matching group names don't guarantee the new client will retain your selections.
5. Check external dependencies: See whether browser extensions, terminal environment variables, Git, or developer tools have hard-coded addresses such as 127.0.0.1:7890.

A subscription can restore only what the provider supplies, not all your local preferences. For example, if the old client routed a work domain directly and that rule wasn't in the subscription, it will disappear after re-importing. Keep a separate list of these differences; it's easier to check than relying on a config that merely looks complete.

Switching to Clash Verge Rev: verify the subscription before enabling the system proxy

Step 1: Install the client and make sure the core starts

Choose an installer for your operating system and CPU architecture from the client downloads page. Quit CFW and disable its system proxy and TUN before launching Clash Verge Rev. First, check the core status and logs. If the core isn't running, investigate config parsing, port conflicts, or service startup errors before repeatedly switching proxies.

Step 2: Import your subscription or local YAML

On the Subscriptions page, use the import option to add your original subscription URL. If you used a local YAML file, import it from your computer instead. Button labels may vary by version; make sure the imported result is a Clash/mihomo config the core can read. A link that returns a Base64 node list or another client-specific format may not be a complete YAML file.

After importing, select the config and check that nodes, proxy groups, and rules appear. For parsing errors, use the field or line number in the logs to find the issue. For HTTP 401 or 403 errors, check subscription access and the provider's status first. If the subscription URL is accessible only through a proxy, you can use the still-working old setup to download a config backup, but quit the old core before switching to the new client.

Step 3: Set the port, then enable the system proxy

In Settings, find the port settings and check the actual mixed port; in some versions, this is under Clash Settings. The example below uses 7897, but that isn't a universal default. If you keep the old port 7890, make sure no old process is using it. If you choose a new port, update any apps with a hard-coded proxy address.

1. Set the mode to Rule and select a known working proxy or node.
2. Enable System Proxy, leave TUN off for now, and test a few familiar websites in your browser.
3. Check the Connections page or logs for matched rules, proxy chains, and connection results to confirm requests are reaching the new core.
4. Once basic proxying works, restore startup, service mode, and TUN one at a time so you can isolate any issues.

Keep custom rules: migrate overrides and proxy group names together

Subscription updates usually fetch the remote config again. To keep local rules long-term, put them in a client-supported extension, merge config, or script mechanism rather than editing the downloaded subscription cache directly. The exact settings vary by version; what matters is checking the final config to confirm local rules made it into rules and appear before the fallback rule.

The example below illustrates rule order; it isn't a complete subscription. It uses example.com as a test domain and PROXY as a sample proxy group name. In your config, the name must match exactly.

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

• Order: Rules are evaluated from top to bottom. A regular rule placed after MATCH won't work as intended.
• Target: DIRECT is a built-in policy. PROXY must refer to an existing node or proxy group; update references if a subscription renames it.
• Merging: Check whether the extension mechanism prepends, appends, or replaces the entire array. Replacing rules incorrectly can remove all the subscription's routing rules.
• Rule providers: Check the URL, format, behavior type, and local path for rule-providers. Absolute paths from an old computer won't work on another one as-is.

Don't assume every top-level field in the old YAML must be kept. The new client may manage listen ports, the control API, and TUN settings. If both local overrides and the UI change these fields, check which setting takes precedence. Use the config reference to review what each field does.

DNS and TUN: go beyond connectivity and verify app behavior

Check DNS first, then troubleshoot specific domains

After switching from the old core, DNS behavior may change how sites load—including fake-IP, real IP resolution, the path DNS queries take, and how rules are matched. Start with the new client's default settings, confirm public websites work, then restore your DNS customizations gradually. Don't pile on DNS snippets from unknown sources just to fix one site.

If your browser works but a company intranet domain doesn't, first check whether the system relies on internal DNS provided by a VPN and whether the domain needs a dedicated DNS policy. A synthetic address in fake-IP mode isn't itself a DNS error. Only consider filtering or domain resolution policies when an app needs the real IP to work.

Test TUN separately

The system proxy mainly serves apps that honor the OS proxy settings. TUN uses a virtual network adapter and routes to capture more traffic, but it doesn't guarantee compatibility with every app, protocol, or network. On Windows, follow the client's prompts to install or enable the required service, confirm you have the necessary permissions, and then turn on TUN.

• Turn off TUN in the old client to prevent two sets of automatic routes from changing traffic paths at once.
• Test a browser, an app that doesn't follow the system proxy, and a LAN address separately.
• Check for conflicts with your company VPN, virtual machine network, or security software.
• If the intranet stops working with TUN enabled, turn TUN off to compare behavior, then investigate routes and DNS. Don't delete several settings at once.

Verify or roll back: use ports, requests, and rule logs to find issues

The PowerShell commands below assume you've confirmed that the new mixed port is 7897. The first checks whether the local port is reachable; the second explicitly sends a request through the HTTP proxy. The sample site's response is useful for a basic connectivity check, but doesn't replace testing the sites you actually use.

Test-NetConnection 127.0.0.1 -Port 7897
curl.exe --proxy http://127.0.0.1:7897 --connect-timeout 10 --max-time 20 -I https://example.com

TcpTestSucceeded : True means only that the local port is reachable—not that the proxy node or remote website is working. If an explicit proxy request succeeds but the browser fails, check the system proxy and the browser's own proxy settings first. If the request fails too, use the client logs to check the selected policy, node connection, and DNS.

Before wrapping up the migration, update the subscription, quit and reopen the client, and restart the system at least once. Then check direct-access websites, proxied websites, and intranet resources. To roll back, first turn off the new client's system proxy and TUN, then quit its core before restoring the old client. Don't run both clients at once to try to "catch" traffic the new one missed.

Once the new setup is stable, remove the old client if you wish, but keep any necessary subscription and rule backups. Going forward, manage the client version, core version, subscription content, and local overrides separately; when something breaks, change only one at a time. For your first setup, see the Getting Started guide. For common connection issues, visit Troubleshooting.