Choose based on your needs, then check the core version
When choosing a Clash client for Windows, keep two layers in mind: the client handles the interface, subscription management, system proxy, and background services; the mihomo core handles protocols, rule matching, DNS, and TUN traffic. A client update does not necessarily include a core update, and two clients using mihomo may still generate different runtime configurations.
This article compares Clash Plus, Clash Verge Rev, and FlClash. Clash Verge Rev uses the Tauri stack, while FlClash uses Flutter; both provide a graphical interface for managing mihomo. For Clash Plus, check the release notes for the specific package and verify the running app to confirm its core, service implementation, and override capabilities. Don’t infer these from the product name alone. Unverified features are not presented as supported, and there is no fixed performance ranking that applies across versions.
- For browser proxying: Check subscription import, proxy group switching, the system proxy toggle, and whether proxy settings are restored when the app exits.
- For routing more apps: Check TUN permissions, DNS, routes, and compatibility with your corporate VPN.
- If you edit rules often: Check persistent overrides, configuration previews, and error diagnostics so subscription updates don’t overwrite local changes.
- Migrating from an older client: Test the same subscription first, then migrate rules one at a time. Don’t copy the entire configuration directory.
Key differences and what to verify
Use the table below to narrow down your options. “Verify” means a check to perform before or after installation, not that the feature is missing. Menu names can change between releases; check the current interface and documentation for your version when looking for a specific setting.
| What to compare | Clash Plus | Clash Verge Rev | FlClash |
|---|---|---|---|
| Core verification | Confirm the core name and version in the release notes and startup logs | Uses mihomo; still record the core version in the package you’re running | Uses mihomo; still record the core version in the package you’re running |
| Interface and runtime | Check the system requirements and installation type for the current release | Tauri desktop interface; check for WebView2 on Windows | Flutter interface; does not use the same WebView2 interface dependency |
| Subscription management | Test import, updates, and how local rules are preserved | Manages subscription profiles and supports configuration processing such as merges and scripts | Manages configuration subscriptions; verify override scope and workflow for your version |
| TUN usage | First confirm that the release provides a TUN option and check its permission requirements | Includes TUN and service-mode management; verify the service is running | Includes a TUN option; verify elevation and background behavior in your version |
| Best suited to | Consider the download page’s recommended option, then decide after basic checks | Users who want Windows configuration management, merging, and script processing | Users familiar with Flutter clients who want a similar workflow |
Clash Plus: verify the specific release package
If you choose Clash Plus, first check the platform and release details on the client download page, then record the version after installation. At a minimum, test that subscription import succeeds, rule mode works, and the system proxy can be restored. If you need TUN, rule providers, or script overrides, verify each capability separately. Don’t assume instructions for other Clash clients also apply to this one.
Clash Verge Rev: check configuration handling and Windows services
Clash Verge Rev is worth considering if you need to fine-tune configuration. Check what configuration the core actually receives after the subscription has been processed by merges, scripts, and interface settings. If TUN runs into permission issues, distinguish between “the interface opens” and “the background service is installed and running.” A blank screen or missing interface is a separate troubleshooting path: check the runtime environment, such as WebView2, rather than changing DNS first.
FlClash: check the workflow and configuration portability
FlClash uses Flutter, unlike Clash Verge Rev’s desktop implementation. If you’re used to FlClash on another platform, test whether selecting configurations, switching nodes, and viewing logs feel familiar. A similar interface doesn’t mean configuration directories, platform permissions, or local overrides can be copied between clients. On Windows, verify TUN, startup behavior, and the system proxy state after exit separately.
Core and protocols: check compatibility using runtime information
If the same subscription works in one client but errors in another, record both client versions, the actual core versions, and the error lines. Don’t compare package release dates alone. New protocol options, rule behavior, and DNS fields may depend on the mihomo version; an older core may not be able to parse a newer configuration.
- Open the client’s About page, core information, or startup logs and record the full version string—not just “latest.”
- Make sure the subscription returns YAML that works with Clash/mihomo, not a web page, login prompt, or format specific to another client.
- Check whether the error occurs during configuration parsing or while establishing a node connection. For parsing errors, check field names and types first; for connection errors, then check the route, authentication, and protocol options.
- Inspect the final runtime configuration to make sure the client hasn’t unexpectedly replaced subscription entries for nodes, proxy groups,
rule-providers, orrules.
For example, mixed-port is the shared listening port for HTTP and SOCKS; external-controller is the core’s control interface, not a browser proxy port. Pointing a browser to the control interface port won’t provide a working proxy, even if the client says it’s running. See the rule syntax guide for field details, and the DNS configuration guide for DNS issues.
System proxy and TUN: test them separately
The system proxy is used by apps that follow Windows proxy settings. TUN routes traffic through a virtual network adapter and typically covers more apps, but it doesn’t guarantee that all traffic will pass through a proxy node. Routing, exclusions, rules, and DNS handling determine where traffic goes. Test games, corporate VPNs, and access to local network devices rather than relying on the presence of a toggle.
Round one: test the system proxy
- Turn off the system proxy and TUN in your old client, then fully exit it. Run only one candidate client at a time.
- Import a subscription, select a node, and use rule mode. Leave TUN off for now and enable the system proxy.
- In Windows 11, open Settings → Network & internet → Proxy. Check that the manual proxy address and port match the current client.
- Visit a test website and check the client’s connection log to confirm the request used the expected policy. Don’t judge by whether the page simply loads.
- Exit the client, then check that Windows proxy settings have been restored and that no leftover proxy is blocking normal access.
Round two: test TUN and network recovery
After the basic proxy test passes, install the service or grant the required permissions as prompted, then enable TUN. Record the virtual adapter, default route changes, and any DNS errors in the logs. Test a browser, an app that doesn’t follow the system proxy, a local network address, and connectivity after waking from sleep. On a company-managed device, follow your administrator’s policies; don’t bypass restrictions by repeatedly elevating privileges or disabling security software.
If a domain won’t load but its IP address connects, check the DNS path first. If all connections fail, check the service, routes, and ports. Enabling fake-ip alone does not guarantee DNS leak protection; also check encrypted DNS in apps, browser settings, and the actual network egress.
Subscriptions and overrides: test after an update
A successful import only confirms that the current content works. For ongoing management, the key questions are whether local rules survive subscription updates, proxy group selections remain as expected, and override errors can be diagnosed. Configure Clash Verge Rev’s merge and script processing, the override options in your current FlClash version, and Clash Plus’s configuration handling according to each product’s documentation.
- Remote subscriptions: Keep the source URL and update interval, and check the last update time and any errors. Subscription URLs may contain credentials; don’t include them in public screenshots or online conversion tools.
- Local rules: Use a persistent override option supported by the client. Don’t edit a subscription cache that will be replaced at the next update.
- Rule order: Put rules that need priority before fallback rules. Check the final configuration; don’t rely on their position in an editor.
- Script migration: Parsers in older clients may use a different scripting interface from newer clients. Check the function entry point, input object, and execution stage.
The YAML below demonstrates rule order only; it is not a complete configuration you can use to replace a subscription. LAN domains and private addresses go direct first, with the proxy group named “Proxy Selection” as the final fallback; that group must already exist. How a merge tool inserts arrays depends on the client implementation. In particular, make sure an existing MATCH rule doesn’t end matching too early.
rules:
- DOMAIN-SUFFIX,lan,DIRECT
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- MATCH,Proxy Selection
After configuring everything, update the subscription manually and check the final rules, proxy groups, and logs. If your rules disappear, fix the persistence method instead of treating “paste them back after every update” as a normal workflow. See the subscription setup guide for the initial import steps.
Resource usage and update activity: compare under the same conditions
You can’t conclude that one client uses less memory just because it’s built with Tauri or Flutter. The graphical interface, core, background service, and WebView2 child processes may be counted differently. Rule set size, connection count, and log level also affect results. For a fair comparison, keep the test conditions consistent and record each client separately.
A repeatable local test
- Use the same subscription, node, and proxy mode for all three candidates. Turn off automatic node testing to avoid extra traffic affecting the results.
- After launch, let each client idle for 5 minutes. In Task Manager, record memory use for the client, core, and related processes—not just the interface process.
- Run the same browser page and file transfer for 10 minutes. Record CPU use, peak memory, disconnections, and error logs.
- Test exit, restart, and wake from sleep separately, and record whether the proxy and network recover. These are suggested test conditions, not performance results.
If you suspect a port conflict, you can check in PowerShell. 7890 is only an example; replace it with the port the client actually listens on. No output usually means there is no matching TCP listener, but it doesn’t rule out UDP or another port being in use.
Get-NetTCPConnection -State Listen -LocalPort 7890 -ErrorAction SilentlyContinue |
Select-Object LocalAddress, LocalPort, OwningProcess
Don’t judge update activity by release count alone. Check formal releases from the past 90 days, core upgrade notes, known issues, and rollback options. Track the client and core versions separately, and look for fixes relevant to your own issues. This article doesn’t list a “latest version” that could quickly become outdated; check the release history before downloading.
Choose based on your needs: keep one primary client
If you only need proxy access for websites and common desktop apps, first test subscription import, rule mode, and system proxy recovery in all three candidates. Keep the one with clear workflows, easy-to-check logs, and settings that persist after updates. You can start by evaluating the relevant Clash Plus release package, but if you need TUN or advanced overrides, verify those features in practice.
If you regularly maintain custom rules and configuration scripts, consider trying Clash Verge Rev first, and confirm the merge order and service mode in your current version. If you already know your way around FlClash, try its Windows version first and check differences in platform permissions and overrides. Compare more factors on the client comparison page; there’s no need to keep several clients running at startup just because their interfaces differ.
Five checks before completing your migration
- Keep a backup of your old configuration, but don’t let both clients compete for the same listening ports or change the system proxy.
- Confirm that subscriptions update, local overrides persist, and logs show no recurring parsing or download errors.
- Test direct-access sites, proxy sites, and local network devices, and check which rules actually match.
- Confirm network behavior is as expected with TUN disabled, after exiting the client, and after restarting Windows.
- Complete connection verification before disabling the old client’s startup entry. Don’t delete the configuration you may need to roll back to.
Your final choice should answer three specific questions: Which core version is actually running? Which changes persist after a configuration update? What happens to system proxy settings and routes when the client exits? Verifying these points is more reliable than choosing based on screenshots or product names.