Choose the right graphical client for your operating system, then use the actual configuration terminology to import subscriptions, route traffic, and configure the system proxy. Coverage focuses on the mihomo kernel, multi-protocol compatibility, and Chinese configuration documentation.
The homepage only routes you to the right platform. The download page lists each client, system architecture, package format, and maintenance status in one place. Selecting a platform opens its corresponding tab directly, so you do not have to compare installers repeatedly.
Best suited to desktop users who need tray controls, system proxy switching, and TUN mode. The download page lists Clash Plus, Clash Verge Rev, FlClash, Clash Nyanpasu, and the archived Clash for Windows, while distinguishing actively maintained projects from legacy clients.
Go to downloadsFor devices with Intel or Apple silicon. On the download page, confirm the processor architecture first, then choose Clash Plus, Clash Verge Rev, FlClash, or the archived ClashX Meta to avoid mixing installers built for different architectures.
Go to downloadsFor phones, tablets, and some TV devices. Compare Clash Plus, Clash Meta for Android, FlClash, and Surfboard on the download page; before installing, choose an arm64, arm, or universal package that matches the device architecture.
Go to downloadsiPhone and iPad users can open the Clash Plus App Store page from the download page and visit the official site at clashplus.io. After importing a subscription, iOS will ask you to approve the VPN configuration. Connection status can be checked in both the client and system settings.
Go to downloadsFor desktop environments, choose Clash Verge Rev or FlClash; servers, soft routers, and automated environments typically run the mihomo kernel directly. On the download page, confirm the distribution, CPU architecture, and package format before choosing a graphical client or command-line kernel.
Go to downloadsIf you are unsure which client to use, start by checking each client card for supported platforms, maintenance status, and intended use.
View all clients →Use the left index to switch topics, the center panel to follow the actual configuration logic, and the right panel to see supported platforms, related protocols, and next steps. Concepts are not flattened into generic feature labels; the material follows a configuration file from loading through activation.
Clash Plus, Clash Verge Rev, FlClash, and similar projects provide the interface, configuration management, tray controls, and system integration; mihomo reads YAML, establishes proxy connections, handles DNS, and selects policies according to rules. When choosing a client, first confirm the operating system and maintenance status, then check whether its built-in kernel supports the protocols and fields used in your configuration. Comparing interfaces alone can obscure the kernel version that actually determines compatibility.
Desktop users generally benefit from a graphical client because subscription updates, system proxy toggles, proxy-group switching, and log viewing are centralized in one interface. Servers and routers place more emphasis on resource control, service management, and reproducible configuration, making mihomo easier to integrate with systemd, containers, or automation scripts. The core concepts are the same, but installation methods, permission boundaries, and troubleshooting paths differ.
A subscription URL may return a complete Clash configuration or only a list of proxy nodes. A complete configuration usually includes proxies, proxy-groups, rules, and a DNS section, allowing it to produce a working routing structure immediately; a node list needs a client or converter to add proxy groups and rules. If the import succeeds but no policies appear, check the content type first instead of repeatedly toggling the system proxy.
Updates can overwrite content managed by the subscription, so temporary local edits may not persist. For custom rules, prefer the client's override, merge configuration, or rule-providers features to keep personal rules separate from the upstream subscription. This preserves node updates while reducing the need to edit YAML after every refresh. When editing manually, also check indentation, list nesting, and whether the current kernel supports each field.
The rules engine checks domains, domain suffixes, IP ranges, processes, or rule sets in sequence. The first matching rule determines which proxy group handles the connection. More specific rules generally belong near the top, broader rules near the bottom, with MATCH catching anything left unmatched. If a broad rule comes first, later specific rules will not take effect even when their syntax is correct. This is a common reason traffic fails to follow rules that are visibly present in the configuration.
Large configurations are easier to manage when rules are split into rule-providers maintained in separate files and updated as needed. During troubleshooting, verify that the provider loaded successfully, its behavior type matches, the target proxy group exists, and DNS results are not affecting IP-based rules. More rules are not necessarily better: clear priorities, stable sources, and an explainable final match are easier to maintain than stacks of duplicate entries.
A select group leaves the decision to the user, making it suitable for a fixed egress or an explicit target switch; url-test chooses a member based on test results; fallback prioritizes availability and moves to the next member when the current one fails; load-balance distributes connections across multiple members. These are not different names for the same feature: their selection logic, stability, and connection consistency differ substantially.
Automatic proxy groups need a test URL, probe interval, and tolerance. Short intervals increase background activity, while a tolerance that is too small can cause frequent switching. Apps involving login sessions or long-lived connections also require attention to session impact when the egress changes. Define whether the goal is manual control, failover, or connection distribution before choosing a group type, and have rules reference only stable group names.
The system proxy mainly affects apps that follow the operating system's proxy settings. It is straightforward to enable or disable and works well as an initial verification path. Some command-line tools, games, and apps with their own network stack may ignore it; a browser can work while other programs connect directly. During troubleshooting, verify the client listening port, system proxy state, and whether the specific app reads proxy settings.
TUN mode captures a broader range of traffic through a virtual network interface. It often requires extra permissions and coordination with routing, DNS, and the firewall. Although it covers more applications, it can also conflict with other VPNs, virtual machines, and security software. Start with the system proxy for basic verification, then enable TUN only when broader coverage is needed. If problems appear, check permissions, routes, DNS, and conflicting software in that order.
Clash is an ecosystem made up of kernels, graphical clients, rule sets, and configuration tools. Understanding the role of each layer makes selection and troubleshooting easier than treating every product with Clash in its name as the same application.
The original Clash established widely used models for YAML configuration, proxy groups, and rule-based routing, and many desktop and mobile clients built graphical interfaces around them. After the original project entered archival status, community development shifted toward continuing forks. Clash.Meta expanded protocol, DNS, rule, and runtime capabilities and was later maintained under the mihomo name. The “Clash clients” seen today are often not different installers from one repository, but combinations of interface projects with compatible kernels and configuration formats.
This relationship directly affects selection. A legacy client may still run, but it may not keep up with system changes or new configuration fields; an active client usually updates its bundled kernel, installation flow, and system integration. Migration does not require rewriting everything at once: copy the subscription URL and essential local overrides first, then check proxy groups, rule-providers, DNS, and TUN settings one by one to confirm that the new client recognizes them correctly.
The graphical client manages profiles, tray menus, startup behavior, kernel controls, and system proxy switching. The mihomo kernel handles protocol connections, traffic sniffing, DNS, rule matching, and policy execution. Rule sets describe which policy should handle a domain or IP, while subscriptions distribute nodes or complete configurations. A problem in any layer can produce similar symptoms on the surface, but the correct fix may be entirely different.
For example, “unable to connect after a subscription update” may result from invalid subscription content, a client that failed to write the configuration correctly, an unsupported kernel field, a proxy group referencing a missing member, or traffic that never entered the client. Layer-by-layer checks work better than repeated reinstalls: confirm that the configuration parses, then that the kernel starts, then inspect proxy groups and logs, and finally verify system proxy or TUN capture.
mihomo retains the common Clash configuration structure while adding more protocols, DNS options, rule capabilities, and runtime parameters. Basic fields are usually easy to migrate, but configurations involving tun, sniffer, geodata, rule-providers, profile, or experimental features should be checked against the current documentation. A client may also keep its own override files, scripts, or interface settings outside the original YAML, so exporting a single configuration file may not capture all local state.
Judge compatibility by three questions: which kernel does the client version support, which fields does that kernel support, and what content does the current subscription actually use? Do not infer capabilities from names alone or assume an option in one client's interface exists on every platform. The protocol handbook further compares the design priorities of SS, VMess, Trojan, VLESS, Hysteria2, and TUIC, along with how they are represented across kernels and subscription formats.
Client updates usually fix interface, installation, permission, or system compatibility issues. Kernel updates affect protocol implementations, the rule engine, DNS, and configuration fields. Subscription updates change nodes, proxy groups, or rules. Their schedules do not necessarily align. When a problem appears, noting which type of change happened most recently can greatly narrow the investigation. After a subscription update, check configuration differences first; after a client upgrade, verify the kernel and permissions; after only a network change, prioritize DNS, routing, and reachability.
A safer update process keeps the currently working configuration, reviews the new release notes, and verifies configuration loading and basic connectivity before restoring TUN, overrides, and automatic policies step by step. For long-running servers, place configuration under version control and use a service manager to control restarts. Desktop users can preserve migration evidence with the client's configuration backups and logs.
These questions help determine what to read next; they are not a substitute for a complete tutorial. Start with the smallest working configuration, then add complex rules and traffic-capture modes gradually.
Open the download page for your operating system and start with a maintained client that provides an installer for your current system architecture. If you want a unified interface, begin by exploring Clash Plus; if you prefer an open-source desktop workflow, compare Clash Verge Rev and FlClash. After installation, import your configuration and verify it with the system proxy rather than changing every advanced setting at once. View the complete setup guide →
The subscription may contain only a node list rather than a complete Clash configuration with proxy-groups and rules. It may also have failed to parse, leaving only partial content. Check the client's configuration error and the subscription type first, then decide whether to use a client template, subscription converter, or local merge configuration. Never submit a subscription URL containing sensitive information to an untrusted page.
This is usually related to traffic-capture scope. The system proxy affects only apps that read system settings, while some programs use their own network configuration. Confirm that the target app supports an HTTP or SOCKS proxy before considering TUN mode. Before enabling TUN, understand its permission, DNS, and routing requirements and possible conflicts with other VPN software. Check the system proxy step by step →
Routine upgrades usually preserve configurations, but moving between clients, uninstalling with cleanup, or changing the configuration directory may require a new import. Before making changes, record the subscription URL, override rules, proxy selection, and TUN settings. After upgrading, confirm that the profile exists and loads successfully, then check the kernel, system proxy, and startup settings. Avoid changing several variables at once.
Recent coverage focuses on mobile background activity, the relationships among open-source Clash projects, and proxy-group selection. The articles use verifiable configuration terminology and are intended for readers who have completed the basic installation.
Start with background keep-alive behavior, system battery restrictions, rule complexity, and connection modes to identify increased mobile power use and frequent client restarts. The article distinguishes system limits, continuous client activity, and network reconnects, then provides a step-by-step comparison path.
Read the full article →Map the relationships among the original Clash, Meta, mihomo, and common graphical clients, including their project roles, maintenance status, and selection boundaries. Recommended for users migrating from legacy clients or assessing configuration compatibility across layers.
Read the full article →Compare the selection logic, switching conditions, and network scenarios for three automatic proxy-group types. Learn how probe intervals, tolerance, failover, and connection consistency interact to create stable, predictable routing rules.
Read the full article →The full list also covers Windows UWP loopback restrictions and compatibility differences among Clash kernel versions.
View all articles →