How to Migrate from Clash for Windows: Clash Verge Rev, FlClash, and Other Alternatives

What to migrate: Handle the client, kernel, and configuration separately

The original Clash for Windows project (CFW) has been discontinued since 2023. Installed copies may continue to work, but you can no longer rely on the original project for future OS compatibility, protocol support, or bug fixes. The goal is not to copy the entire installation folder, but to preserve your subscription sources, routing rules, and essential settings, then let the new client set up its own runtime environment.

The client handles the interface, subscription management, system proxy, and service controls. The kernel parses configuration, establishes connections, and applies rules. CFW has supported different kernel setups over time, so the client's name alone won't tell you what your old configuration can do. Before migrating, note the kernel type and version actually in use, then check which kernels the new client includes. Don't compare client version numbers as if they were kernel versions.

• Prioritize: Subscription URLs, local YAML files, custom rules, proxy group names, and rule-set sources.
• Set up separately: System proxy, launch at startup, service permissions, TUN adapter, and routing settings.
• Keep if needed: Current proxy group selections, speed-test settings, DNS settings, and proxy ports configured in individual apps.
• Don't copy over: The old client's database, kernel executables, cache folders, or virtual network adapter drivers.

Choose an alternative by platform and configuration workflow

Windows desktop users can start by comparing Clash Verge Rev and FlClash. Both manage configurations with the mihomo kernel, but differ in interface, configuration enhancement options, and system integration. Linux and macOS users should check package architecture, while Android users need the Android build and platform-specific proxy setup—not the Windows installer or instructions.

Check the version reported by the kernel running on your device

Client and kernel updates use separate version numbers, and some clients let you switch kernels. First, note the version shown in the client's kernel information or logs. If you can locate the kernel executable, you can also check its version in a terminal. Run the command below from the directory containing the executable; the filename depends on your installation:

# Windows PowerShell
.\mihomo.exe -v

# macOS / Linux
./mihomo -v

Don't replace the old client's kernel just to display a newer version number. The control interface, launch arguments, and directory conventions may not be compatible. When choosing a client, check which protocols your subscription requires, then confirm that its actual kernel supports them. “Can import Clash configuration” does not mean every mihomo extension field is supported.

Back up before migrating: keep the source files and effective configuration

The subscription file shown in the old client may differ from the configuration the kernel actually uses. CFW Parsers, Mixin, or manual edits may change ports, rules, and proxy groups after the subscription is fetched. If you save only the subscription URL, added rules can easily disappear in the new client.

1. Record the current setup. Note the client and kernel versions, configuration name, operating mode, and whether system proxy and TUN are enabled.
2. Save subscription details. Keep the original subscription URL and provider name. Subscription URLs often contain access tokens, so don't include them in public notes or screenshots.
3. Copy local files. Open the configuration folder in the old client and copy the YAML files, referenced local rule sets, and custom scripts to a separate backup folder.
4. Save the processed configuration. If the old client lets you view its runtime configuration, save a copy and distinguish it from the original subscription. Runtime configurations may contain credentials in plain text, so store them as sensitive files.
5. Save system settings. Note the HTTP/SOCKS ports, LAN sharing, bypass list, and proxy addresses configured separately in browsers or command-line tools.

On Windows, check the active manual proxy under Settings → Network & internet → Proxy. If the old configuration uses 127.0.0.1:7890, write down the address and port; this is a common example, not a setting used by every PC. On macOS, check System Settings → Network → your network service → Details → Proxies. Menu names may vary slightly by OS version.

Import subscriptions: restore connectivity first, then add enhancements

Add the original subscription URL on the new client's subscription or configuration page, update it, and select the resulting profile. Depending on the build, the page may be called “Configuration,” “Subscription,” or “Profiles.” The important checks are that the download succeeds, the kernel loads, and the node list isn't empty. If you need to generate a new link through your subscription provider, first confirm that its format is compatible with mihomo.

1. Turn off system proxy, TUN, and background services in the old client, then quit it. Closing the window may leave the client running in the system tray.
2. Import a configuration into the new client and start in Rule mode. Don't enable TUN, LAN sharing, or launch at startup yet.
3. Select a known working node, check the connection logs, then enable the system proxy and visit the sites you use every day.
4. Once basic connectivity works, add custom rules, DNS settings, rule sets, and configuration enhancements.
5. Manually update the subscription once and check that your enhancements are still there. This helps catch changes that worked only in the current file.

Resolve port conflicts by checking processes—not by repeatedly changing settings

The old and new kernels can't listen on the same address and port at the same time. If the logs show address already in use, check which process is listening on port 7890 instead of repeatedly changing the port. Example diagnostic commands:

# Windows PowerShell
Get-NetTCPConnection -State Listen -LocalPort 7890 |
  Select-Object LocalAddress, LocalPort, OwningProcess

# macOS
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux
ss -ltnp 'sport = :7890'

If you confirm that you need to switch to port 7891, update browser extensions, terminal environment variables, and any other manually configured proxy clients as well. The system proxy toggle affects only apps that follow system settings; it doesn't guarantee that every program will switch automatically.

Migrate rules and custom settings: check references, order, and overrides

mihomo supports many Clash-style configurations, but migration isn't a matter of copying every field verbatim. First, check the name references between proxies, proxy-providers, proxy-groups, and rules. If a proxy group is renamed but rules still use its old name, configuration loading may fail. Rules are evaluated from top to bottom, so put the fallback MATCH rule last; otherwise, later rules won't be reached.

Use a minimal configuration to verify that local files load

The minimal YAML below is for testing whether the new client can load a configuration. It provides direct connections only—no proxy nodes—and isn't a replacement for your subscription. Once the kernel loads it successfully, add your real nodes or providers and proxy groups. Don't use this template to overwrite a subscription file.

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

proxy-groups:
  - name: Default route
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,Default route

Here, Default route appears as both the proxy group name and the rule target, so the two entries must match. mixed-port provides both HTTP and SOCKS proxy access on one port. The example doesn't define external-controller, so it doesn't expose a control interface. If the client manages that interface itself, follow the configuration it generates.

Migrate subscription enhancements and rule sets one by one

• Parsers and Mixin: These are client-side processing features, not standard kernel configuration sections. Recreate their effects using the merge or scripting options in the new client; don't assume the old scripts will run unchanged.
• Rule sets: Keep the rule-providers sources, behavior, format, and update interval. Check that names in RULE-SET references still match.
• Local paths: Relative paths from the old folder may no longer work in the new working directory. After moving local rule files, check the path the kernel actually resolves and confirm it has permission to read the files.
• Legacy script mode: If the old configuration relies on Clash Premium scripting, don't assume mihomo offers the same runtime behavior. Recreate the routing logic with rules or client-side processing supported by the target kernel.
• Proxy group state: The group definitions may transfer, but the current selection may not. Choose an outbound route again, then check that automatic speed tests and failover work as expected.

DNS and TUN: enable them last and test them separately

Use the system proxy to verify connectivity and rules before enabling TUN. This makes DNS, routing, and permission issues easier to troubleshoot. TUN captures traffic at the virtual network adapter level and usually requires system permissions or a background service. Windows service installation, macOS network permissions, and Android VPN authorization work differently, so set them up again on the target system.

Migrate DNS settings as a whole. fake-ip mode returns addresses mapped to domain names, but doesn't by itself guarantee that DNS queries go through the proxy. Also check DNS upstreams, nameserver-policy, related routes, and TUN DNS hijacking settings. Browser Secure DNS, in-app DoH, and other VPNs can also change how DNS queries are resolved.

• LAN services: Test your router's admin page, NAS, and printer. If local domains rely on your router's DNS, make sure the relevant queries still go to an appropriate local resolver.
• Work network: Test company intranet domains and VPN access. If multiple virtual adapters change the default route, disable them one at a time to identify the conflict.
• DNS cache: After switching Fake-IP modes or DNS policies, restart the app you're testing. On Windows, run ipconfig /flushdns if needed to clear the system DNS cache.
• Listening interfaces: Enable LAN sharing only when other devices need access, and check the firewall rules. A single-device migration doesn't require exposing proxy ports to your LAN.

If the system proxy works but TUN causes problems, check permissions, routes, and DNS first rather than changing subscriptions. A successful node speed test only confirms that one test request completed; it doesn't prove that app traffic is being routed correctly.

Verify and roll back: update the subscription before retiring the old setup

At a minimum, test a regular browser, tools with manually configured proxies, and apps that require TUN. The table below lists checks and expected results, not pre-measured test results. Repeat each check three times against the same target, recording the time, matched rule, and outbound route. A one-off successful connection isn't enough to call the migration complete.

If it fails, roll back in reverse order

Turn off TUN and the system proxy in the new client, stop its background services, and confirm that the listening ports have been released. Then start the old client and restore its original configuration and proxy settings. Don't let both clients compete for the system proxy or TUN routes. If the new client has exited but your browser still can't connect, check whether the system still has a manual proxy set to 127.0.0.1:7890 even though no service is listening on that port.

After subscription updates, an OS restart, and tests in your everyday apps all pass, remove the old startup entry and uninstall the old client. Keep an offline configuration backup and migration notes, including the new client version, actual kernel version, ports, and where to find enhancement settings. If a subscription change or OS upgrade causes trouble later, these details help you identify whether the issue is in the client, kernel, or configuration—without having to retrace the entire setup.