Review clients for five platforms, subscription and rule configuration, and system integration troubleshooting in one place. Confirm your operating system and processor architecture first, then open the matching platform guide for installers and setup steps.
The homepage is for finding your platform. Check installer types, maintenance status, processor architecture, and download buttons together on the download page.
For Windows 10 and Windows 11 desktop systems. On the download page, confirm your system architecture first, then choose from Clash Plus, Clash Verge Rev, FlClash, Clash Nyanpasu, and other clients. After installation, use the system proxy or configure TUN mode according to your permissions and coverage needs.
Go to downloadsmacOS installers are separated into Intel and Apple Silicon builds. M1, M2, M3, M4, and newer Apple chips generally use ARM, while older Intel Macs use x64. On first launch, follow the system prompts for network extensions, proxy settings, or required permissions; the filename alone does not confirm a successful installation.
Go to downloadsThe Android page provides client downloads for phones and tablets. Most recent devices use ARM64, while older devices may require ARM or a universal package. After importing a subscription, Android displays a VPN connection consent dialog; the client can process app traffic through its rule core only after authorization.
Go to downloadsInstall Clash Plus on iPhone and iPad through the App Store. The download page includes the store entry and the official website, clashplus.io. When enabling a configuration for the first time, iOS asks to add a VPN configuration. After system verification, return to the client to choose a subscription, proxy group, and connection mode.
Go to downloadsOn Linux desktops, choose Clash Verge Rev or FlClash; servers, software routers, and containers typically run the mihomo core directly. Before desktop installation, check the deb, rpm, and distribution type. Command-line deployment also requires a configuration directory, service permissions, startup behavior, and proxy environment variables.
Go to downloadsThe same operating system name does not mean installers are interchangeable. macOS distinguishes Intel from Apple Silicon; Android commonly uses ARM64, ARM, or universal packages; Linux may involve AMD64, ARM64, ARMv7, and different package formats. An incompatible architecture often causes the installer to fail, an unsupported-file warning, or the core to exit immediately after starting.
For everyday desktop and mobile use, choose a graphical client so subscription updates, proxy-group switching, system proxy settings, and logs are available in one interface. Servers and routers are better suited to running mihomo directly, with processes managed through configuration files, systemd, or containers. The rule concepts are similar, but installation paths and troubleshooting entry points differ.
Installing a client does not mean that network traffic is already routed through it. Import a working subscription or local YAML configuration, update it, choose a proxy group, and enable the system proxy or TUN mode as needed. When connections fail, check the client logs first. Avoid changing DNS, ports, rules, and proxy modes at the same time, or it becomes difficult to identify the cause.
Trace the path from an incoming request through rule matching, subscription updates, system integration, and core compatibility.
Rule mode does not send every connection to the same node. The client checks domains, IPs, processes, ports, or rule sets in the configured order, then passes a match to the designated proxy group. A proxy group can select a node manually or choose an exit through health checks, failover, or load balancing. The final MATCH catches requests not matched earlier, so rule order and fallback behavior directly affect the result.
When troubleshooting incorrect routing, first use the logs to confirm which rule matched the request, then inspect that rule’s proxy group and current selection. Unlike tools that offer only a global connection, Clash rules can place direct, proxied, blocked, and different routes in one configuration—but maintainers must define priorities clearly. Change one rule group at a time so higher-priority rules do not hide lower-priority ones.
A subscription link usually returns a remote configuration or a collection of nodes. After downloading it, the client must parse the YAML, save a local copy, and load its proxies, proxy groups, rules, and DNS settings into the core. A successful update only confirms that remote content was retrieved. Check the configuration list and runtime logs to verify that usable nodes exist, the current core recognizes the syntax, and all proxy-group references are valid.
A reliable management routine records the update time, update result, and currently active configuration. When a subscription fails, check in order that the link is complete, the network can reach it, the response is valid configuration, and the client reports no parse errors. Do not repeatedly delete all application data; export local changes first and distinguish remote configuration issues from client networking problems.
A system proxy changes the operating system’s HTTP, HTTPS, or SOCKS settings. Applications that honor those settings send requests to the client’s listening port. Some command-line tools, games, virtual machines, and applications with their own network stack may ignore them. TUN mode uses a virtual network interface to capture a broader range of IP traffic. It suits environments that need wider application coverage, but usually requires extra permissions and changes the DNS and routing troubleshooting path.
Choose a mode based on what you need to capture rather than enabling every option at once. Test the system proxy first with browsers and standard desktop applications. If a program ignores proxy settings, then evaluate TUN. If connectivity fails after enabling it, check core logs, virtual adapter permissions, the default route, the DNS listening port, and conflicts with other VPN software. Do not confuse node timeouts with system-integration failures.
Desktop and mobile clients in the Clash ecosystem mainly handle the interface, configuration management, system integration, and process control. The underlying core parses rules and forwards connections. Different clients may bundle different core versions or allow the core to be replaced. mihomo is the main actively maintained branch today, extending Clash Meta’s configuration capabilities. The original Clash and some older clients are no longer maintained; older configurations may still work, but new fields should not be assumed to be compatible.
Before migrating clients, record the current ports, DNS mode, rule providers, proxy groups, and TUN settings, then check which fields the target core supports. Similar interface labels do not guarantee identical configuration directories or launch arguments. For server deployments, read the core logs and service status directly. Separating interface, configuration, and core issues can greatly narrow the search.
System-proxy requests usually reach the client through its HTTP, SOCKS, or mixed-port listener; TUN traffic first enters the virtual network interface. If an application never appears in the logs, check the capture path, listening address, and system settings before changing nodes.
A domain may be resolved by the system or handled by the client’s DNS module. fake-ip, redir-host, remote resolution, and fallback policies can change the query path. When a domain fails but its IP is reachable, trace the resolution chain instead of checking only the proxy node.
The rule name, proxy group, and final node in the logs form a complete decision record. If a request takes the wrong exit, check whether an earlier rule matched first, then verify the rule-set update time and the proxy group’s current selection.
If the correct rule matches but the connection still times out, focus on node reachability, protocol parameters, the local firewall, and restrictions at the destination. Stage-by-stage diagnosis prevents random changes among rules, DNS, system integration, and nodes.
Client names, graphical interfaces, and proxy cores are not the same project. Before downloading or troubleshooting, identify which layer the issue belongs to.
Clash established a core workflow based on YAML configuration, rule matching, proxy groups, and multi-protocol proxying. After the original project stopped being maintained, the ecosystem did not converge into a single product; multiple core branches and graphical clients continued to evolve. When reading older guides, check whether they refer to original Clash, Clash Meta, mihomo, or a specific client. Settings with the same name may use different fields and defaults across versions.
Clash Plus, Clash Verge Rev, FlClash, Clash Nyanpasu, and ClashX Meta generally refer to implementations or graphical clients for different platforms. Clients provide subscription management, proxy selection, system-proxy controls, logs, and update entry points. Cores such as mihomo listen on ports, handle DNS logic, match rules, and establish outbound connections. If the interface opens but proxying fails, check whether the core started successfully.
mihomo continues Clash Meta’s maintenance direction while adding capabilities for rules, DNS, tunnels, and protocols. Compatibility does not mean every old configuration can be copied directly, nor that a new configuration can run on an older core. During migration, load logging level, ports, proxy groups, rule providers, DNS, and TUN settings one at a time. Test after each layer so a parse error can be traced to a specific field.
The download page populates client versions and download URLs from a version list; entries without version information are hidden. Judge whether a project is still maintained by reviewing releases, commit activity, and announcements—not simply by how widely its name is used. Archived clients are marked for archival use in the download list. For new installations, prefer clients with ongoing releases, support for the current operating system, and compatibility with the current core configuration.
Use these questions to quickly identify where to start troubleshooting. For terminology and related concepts, continue to the glossary.
First confirm that the configuration loaded successfully, the proxy group has an available choice, and the system proxy is enabled. If browser requests do not appear in the client logs, the issue is usually in the system proxy or capture path. If requests are logged, continue by checking rule matches and node connectivity. See the glossary for the difference between system proxy, mixed port, and TUN mode.
A successful update may only mean that the request received a response. Confirm that the response is valid configuration, the client can parse its fields, the proxy list is not empty, and the recently updated configuration is active. Check the update log for YAML parsing, field compatibility, or proxy-group reference errors, then consult the glossary to understand subscriptions and local configurations.
Browsers and desktop programs that honor system proxy settings can start with the system proxy, which follows a more direct path. For games, command-line tools, or applications that ignore system proxy settings, evaluate TUN mode. TUN involves the virtual network adapter, routing, permissions, and DNS path, so check all of them after enabling it. See the glossary for related terminology.
A rule match only confirms that routing decisions are complete; it does not guarantee a successful outbound connection. Check the proxy group’s current selection, node parameters, destination reachability, local firewall, and network restrictions. If the same node fails for every destination, focus on the node and protocol. If only certain domains fail, inspect DNS, the destination, and more specific rule conditions. See the glossary for how the terms relate.
These articles follow reproducible network paths and document diagnostic methods, log-based investigation, configuration boundaries, and recovery steps.
Start with test results, the system resolution path, and client logs, then review fake-ip, remote resolution, and fallback settings one by one. The article distinguishes browser results, operating-system queries, and the client’s DNS module so conclusions are not based on a single web test.
Compare the project relationships, configuration compatibility, and maintenance status of the three core branches, and explain how graphical clients combine with cores. Use this guide before migrating a configuration to identify fields that need review and older guidance that may no longer fit the current environment.
Compare the complete path from application requests to the proxy core, including troubleshooting for permissions, virtual adapters, DNS, and routing. Useful when some applications bypass the proxy, enabling TUN breaks connectivity, or the system proxy has no effect.