Start by distinguishing the client, core, and subscription
Choosing a Clash client means choosing three things: the interface for managing configuration, the core that processes rules, and how traffic is routed through the system. FlClash and Clash Verge Rev are both graphical clients. mihomo is a core that can also run independently as a command-line program. A subscription provides nodes or a complete configuration; it is not a client and does not determine whether the system proxy is enabled.
If the same subscription behaves differently in two clients, that does not necessarily mean the nodes have changed. Core versions, DNS overrides, rule order, TUN status, and policy group selection can all affect the route a connection takes. Before comparing clients, standardize these conditions instead of relying on the latency shown on the home screen.
Bottom line: If you want a similar experience on desktop and Android, start by evaluating FlClash. If you mainly manage multiple subscriptions and overrides on desktop, consider Clash Verge Rev. For Linux servers, mihomo is usually the direct choice. Check compatibility against the installer, core version, and release notes for the specific build you plan to use.
This guide compares workflows, not version numbers that may soon change. Before installing, note the client version and core version separately. They use different versioning schemes, so a higher client version does not indicate broader protocol support.
Platform support and maintenance status
| Client | Primary platforms | Best suited to | What to verify |
|---|---|---|---|
| FlClash | Windows、macOS、Linux、Android | Import configurations, choose policies, and check runtime status through a consistent interface | Installer for your target architecture, mobile VPN permissions, and actual core version |
| Clash Verge Rev | Windows、macOS、Linux | Desktop subscription management, configuration enhancement, and service mode | Override scope, service installation status, system proxy, and TUN settings |
| Clash Nyanpasu | Windows、macOS、Linux | Desktop configuration management and core-related settings | Maintenance status of the relevant build, core selection, and how configuration enhancements are applied |
| mihomo | Supported Linux systems and architectures | Configuration files, command line, and system services | Service permissions, network routing, controller access, and upgrade rollback |
| Clash for Windows | Legacy desktop releases | A migration reference for existing setups | No longer maintained; not recommended for new deployments |
The same platform name does not mean the installation requirements are the same
- Windows: Check whether you need x64 or ARM64. The system proxy usually does not require administrator privileges, but installing a service, creating a TUN adapter, or changing routes may require elevation.
- macOS: Check whether your Mac has Apple Silicon or an Intel processor. Opening the app for the first time and enabling network components are separate steps; a system permission prompt does not automatically mean installation failed.
- Linux desktop: Check the package format and runtime dependencies. After installation, verify that your desktop environment reads the system proxy settings and that you have the permissions needed for TUN.
- Android: FlClash routes traffic through Android's system VPN interface and requires your permission. Typically, only one VPN can be active per user at a time, so check whether another VPN, packet-capture, or firewall app is already using it.
Do not assume a desktop installation method also applies to iOS. FlClash and Clash Verge Rev are not commonly released for iOS. Check separately whether an iOS proxy app supports the subscription format you need. Support for importing some nodes does not mean the app can use a complete mihomo configuration.
Dimension 1: Core updates and protocol compatibility
mihomo continues the technical direction of Clash Meta. A client that bundles mihomo does not necessarily include the same core build in every release. To check whether a new protocol field, DNS option, or rule behavior is supported, look at the core actually running in the installed build—not just the product name.
Record three details after installation
- In the client's About, version information, or core management screen, note both the interface version and core version. Menu names vary by release, so do not assume every client uses the same navigation path.
- After importing a configuration, check the startup logs for unsupported proxy types, rule parsing errors, or listener failures.
- Check that all parameters required by the new protocol are present. Changing a node's
typeto a different name does not convert it to another protocol.
FlClash is a good fit if you want the client to manage the core and interface together. With Clash Verge Rev, also check the core update controls and release notes. If your build lets you switch cores, back up your configuration first, then verify DNS, UDP, and TUN behavior after the update. Development builds can help test specific fixes, but a newer version number alone is not a reason to use one for every workflow.
In a standalone mihomo setup, you can test the configuration first. The filename below is an example of a local configuration file; run the command in an environment where mihomo is installed:
mihomo -v
mihomo -t -f ./config.yaml
-t checks whether the current core accepts the configuration. It does not verify node connectivity, DNS availability, or rule outcomes. A graphical client may also generate configuration before startup, so testing the original subscription file does not replace checking the final runtime configuration.
Dimension 2: Interface and traffic routing
One practical advantage of FlClash is that its desktop and Android workflows feel similar: import a configuration, connect, choose a policy group, and review connection logs. Clash Verge Rev is more focused on desktop workflows, including tray controls, the system proxy, service mode, and configuration management. Choose based on the tasks you perform every day, not the number of settings shown in a screenshot.
Test the system proxy and TUN separately
The system proxy sends traffic from apps that follow system settings to a local proxy listener; some terminal tools and games do not use it automatically. TUN routes eligible traffic through a virtual network adapter, but still depends on permissions, routes, DNS, and exclusion rules. It does not mean every connection will use the proxy once enabled. Rules and policy groups determine the final outbound route.
- For browser-based work, start with the system proxy. Confirm that sites load and the expected rules match before deciding whether you need TUN.
- For command-line tools, specify the proxy explicitly first to rule out the possibility that the app is ignoring system proxy settings.
- Test TUN for games, UDP apps, or software that ignores proxy settings. Also confirm that the node and outbound route support the traffic in question.
For example, the command below applies only if mixed-port is actually set to 7890 in the active configuration. Port 7890 is just an example, not a universal default across clients:
curl --proxy http://127.0.0.1:7890 https://example.com/
If an explicit proxy works but direct access fails, first check the app's proxy settings and routing method. If the local port is unreachable, check whether the core is running and whether another process is using the port before changing subscriptions.
Dimension 3: Subscription and override management
The boundary between subscription updates and local customizations is easy to overlook over time. Editing a file generated from a subscription can mean losing your changes the next time it updates. A safer approach is to use the remote subscription for nodes or the base configuration, and local overrides for additional rules, DNS, listener addresses, and personal preferences.
Check these four things when comparing override features
- Scope: Does a change apply only to the current configuration or to all configurations? Will your DNS settings still apply when you switch subscriptions?
- Order: Are local rules inserted before subscription rules or appended at the end? Rules appended after
MATCHgenerally will not get a chance to match. - Merge behavior: Object fields may be merged, while arrays may be replaced or appended. Check how the client handles overrides; you cannot infer the behavior from the YAML structure alone.
- Visibility: Can you inspect the final runtime configuration and rule match logs? Seeing a successful save in the editor does not prove that the core loaded the configuration.
Clash Verge Rev's configuration enhancement workflow suits desktop users who maintain local merges or script-based processing. Available controls and execution order depend on the installed version. FlClash users should also check where overrides are configured and what they affect; do not assume desktop and Android store configuration in exactly the same way.
The following snippet illustrates rule order; it is not a complete configuration ready to import. It sends corporate intranet traffic directly and routes everything else through the existing PROXY policy group. Before using it, confirm that the group exists and replace the example domain with your actual intranet domain:
rules:
- DOMAIN-SUFFIX,office.example.com,DIRECT
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- MATCH,PROXY
Do not replace the entire
ruleslist with this snippet without checking how the client handles it. If the client replaces arrays, it may remove all existing rules. First confirm the difference between prepend, append, and replace behavior.
Subscription URLs often contain credentials. When migrating, filing a support issue, or sharing screenshots, redact the full URL, node passwords, and controller secrets. Do not submit a real subscription to an online converter you do not trust.
Dimension 4: Test performance and reliability under the same conditions
A different client interface does not imply a faster or slower connection. With the same core, nodes, routes, DNS, and test target, differences between graphical clients mainly come down to interaction, configuration generation, and resource usage. This guide does not rank speeds without specifying the device, versions, and network conditions.
A repeatable comparison workflow
- Run only one client at a time. Quit the other client and its background services to avoid port conflicts or overlapping TUN routes.
- Use the same node and disable automatic policy switching. Keep
mode: rule, DNS settings, and test targets consistent. - Test the system proxy first, then TUN separately. Run each test three times under the same conditions and record successful connections and elapsed time; do not draw conclusions from a single outlier.
- After five minutes at idle, record memory and CPU usage. Distinguish the interface process from the core process, and keep log levels consistent.
- Test one subscription update, one network change, and one wake-from-sleep cycle. Check whether the connection recovers and policy selections are preserved.
Keep the URL and timeout settings consistent when testing latency. Clients may use different probe targets: a reading of 80 ms in one client and 150 ms in another is not a valid comparison if the targets and methods differ. These figures are examples only, not measurements from this guide.
When a connection drops, note the time, destination domain, matched rule, and outbound name first. Saying only that a client is slow does not help distinguish a DNS timeout from an unreachable node or a rule sending traffic through the wrong exit.
Narrow down your options by use case
| Use case | Start by evaluating | What to verify |
|---|---|---|
| Switching between desktop and Android | FlClash | Subscription import on both devices, policy selection, VPN permissions, and background operation |
| Desktop work with multiple configurations and local rules | Clash Verge Rev; compare with FlClash as well | Configuration enhancement order, tray controls, wake-from-sleep recovery, and direct intranet access |
| Looking for another desktop workflow | Clash Nyanpasu | Release maintenance, configuration migration, and compatibility with the actual core |
| Headless Linux server | Standalone mihomo | Service startup, listener binding, permissions, log rotation, and rollback |
| Migrating an old Clash for Windows setup | A maintained desktop client | Configuration parsing, matching ports, policy group names, and rule order |
You do not need to install a desktop environment on a server to use Clash
On a Linux server, you can run mihomo under a service manager such as systemd. Specify the configuration file path, service user, restart policy, and log retention method. If only local apps need access, bind the proxy port to the loopback address. Consider allow-lan, authentication, and firewall rules only if you explicitly need to offer proxy access to your local network.
external-controller is a control interface, not a regular proxy port. If you use 127.0.0.1:9090, it is accessible only from the local machine; use a secured tunnel for remote management. Do not expose the controller directly to the public internet for convenience, and make sure to configure secret.
When migrating an old client, move the configuration—not the whole directory
Save your subscription sources, personal rules, DNS settings, and policy group selections, then import them into the new client. Different projects use incompatible databases, caches, and service configurations; copying an entire directory can bring along outdated paths or state. Before launching the new client for the first time, disable the old client's system proxy, TUN, and background services. Confirm it has exited and the system proxy settings have been restored.
Pre-install and post-install checklist
- Before installing: Confirm your operating system and CPU architecture, review the release notes, and save your existing configuration and a working installer for rollback.
- First launch: Note the client and core versions, import one configuration, and check the logs for parsing errors and port conflicts.
- First connection: Check rule mode, the actual mixed port, and the active policy group. Verify one routing method before adding settings such as TUN.
- First subscription update: Confirm that local rules and DNS preferences are still in place. Check the final runtime configuration, not just the editor.
- During regular use: Test wake-from-sleep recovery, switching between Wi-Fi and mobile data, access to your company intranet, and network recovery after quitting the client.
FlClash, Clash Verge Rev, and standalone mihomo are not interchangeable versions of the same tool. The first two make graphical configuration and everyday switching easier; the last offers a more direct way to run a service. The right choice should leave you with configuration you can understand, logs you can use to troubleshoot, updates you can roll back, and compatibility with your platform and network permissions. For configuration field details, see the Configuration Reference. For installation and first connection steps, see Getting Started.