Import a subscriptionSwitch proxy modeRule-based routing
Clash downloads Choose your operating system
Start by identifying your operating system, then check your processor architecture. Find installers, system requirements, and available clients on the download page. This homepage organizes the options so you don't have to hunt through similarly named projects.
For Windows, macOS, Android, and iOS, start with Clash Plus, then compare other clients by interface and core support. On Linux desktops, consider Clash Verge Rev or FlClash; for servers and routers, see the core section. Similar client names don't guarantee the same installer, configuration fields, or maintenance status.
Importing configuration, matching rules, routing traffic, and resolving domain names are four common tasks when using a client. Understand what each one does before changing settings, and troubleshooting becomes much easier.
Configuration management
Import subscription → Update configuration → Set as active
Subscription formats and active configuration
A subscription link provides configuration; it isn't a connection service that comes bundled with the client. Before importing, check whether the source provides Clash YAML, a collection of proxy links, or another format that needs conversion. After importing, review the parse results, set the configuration as active, and check that policy groups appear. Menu names vary by client, but the same three steps apply: retrieve, parse, and enable. Subscription updates may overwrite manual edits, so use the client's override or merge features for changes you want to keep.
In rule mode, rules are evaluated in order, and the first match usually determines where traffic goes. Domain, IP range, and fallback rules each serve a purpose, so don't judge a configuration by checking individual syntax alone. PROXY in the example must be the name of a policy that actually exists in your configuration; subscriptions don't all use that name. Before adding a custom rule, confirm where it belongs, then check the connection log to see which rule matched. Editing specific rules preserves other apps' routing behavior better than switching to global mode, and makes issues easier to isolate.
System proxy writes a local proxy address to your operating system's settings, which works for apps that honor that setting. Some command-line tools and games don't. TUN mode routes traffic through a virtual network adapter and routing rules, typically covering more apps, but it can involve permissions, DNS, and compatibility with other VPNs. To get started, test the connection with one routing method, then expand coverage as needed. It's easier to find the source of a problem than when every option is enabled at once. A VPN permission on a phone is not the same as a desktop system proxy; treat them as separate settings.
Fake-IP assigns domains internal addresses so the core can associate later connections with their domain names and apply domain rules. Enabling it alone won't fix every DNS issue: DNS requests must also follow the correct resolution path. For LAN devices, specific apps, or cache compatibility issues, configure filters to suit your setup rather than copying someone else's list wholesale. When checking DNS, look at the resolver used by the app, the system cache, and the client logs. Core support for configuration fields also varies.
The client interface handles imports and user actions, the core applies the configuration, and the subscription provider supplies connection details. A successful import only means the file was received or parsed; it doesn't guarantee a working remote connection. An enabled switch doesn't mean every app is using the proxy, either. Keep these layers separate: that way, you won't reinstall the client over and over when a subscription expires, or keep switching policies when an app ignores the system proxy.
Check real requests after connecting
To test, open an app that should use the proxy, then check the connection log for the destination, matched rule, and outbound policy. If the test fails, note which step went wrong and change one setting at a time. Latency tests, page loads, and file transfers measure different things and aren't interchangeable. To compare clients, read the Choosing Guide before deciding whether to switch interfaces or cores.
Open-source ecosystem and core guide
Clash is both the name of a historic project and a common shorthand for a wider client and configuration ecosystem. Understanding how projects are related before downloading—and reading release notes after updating—is more reliable than judging a client by its name alone. Clash Home provides download guides and Chinese-language resources; it isn't affiliated with client development teams.
From the original Clash to mihomo
The original Clash established a familiar workflow based on YAML configuration, proxy policy groups, and rule-based routing. Community projects continued to build on it. Clash.Meta is a historic name you'll often encounter in the ecosystem, while mihomo continues that core lineage. Older articles, configuration files, and client descriptions may still say Meta. Consider the project name, the core actually in use, and when the documentation was written; these aren't simply unrelated software projects.
After the original project ceased maintenance, clients took different paths: some were archived, some switched to actively maintained cores, and others kept their old interface while adding support for newer configuration features. A familiar interface doesn't confirm protocol support. For newer protocols, rule providers, or DNS fields, check the documentation for the core bundled with your current client. Being able to open an older configuration doesn't mean every field is supported or applied.
What the client interface and core each do
A graphical client typically handles the tray menu, subscription management, launch-at-startup settings, system proxy, and log display. The core handles connections, DNS, rule evaluation, and outbound selection. They may be updated separately. Seeing an option in the interface only means the client offers that control; its effect still depends on permissions, core capabilities, and the active configuration. When an error occurs, first determine whether the interface action failed, the configuration failed to load, or the connection failed to establish.
Don't choose a client based only on how many interface features it offers. For everyday use, look at how clearly it manages configurations, how easy it is to read logs, and whether it reliably preserves the custom settings you need. If you frequently edit rules, compare override and merge options. If you need to route command-line tools or games, check TUN and routing support. On mobile, factor in background restrictions. The client Choosing Guide compares these differences by use case.
Configuration compatibility and subscription sources
Proxy protocols, transport methods, and configuration formats are different things. A subscription containing a proxy that uses a particular protocol doesn't mean every Clash client can read it. Even with the same protocol, transport options and extension fields may differ. If import fails, first determine whether the subscription is a complete YAML configuration, a collection of proxy links, or a format specific to another client. Changing the file extension won't change its contents or add missing configuration structure.
Subscription links often grant access to your account. Hide the full link and connection credentials when sharing screenshots, logs, or support requests. Before converting a configuration, find out where the conversion tool runs and what data it processes; a third-party service may see the original subscription. Conversion can adjust the format to a limited extent, but it can't give a core support for a protocol it doesn't implement. For help choosing between Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and TUIC, read the protocol and core guide.
Updates, rollbacks, and reproducible troubleshooting
Before updating, save your current configuration, custom rules, and any interface settings you need, then read the release notes relevant to your use case. New protocol support, changes to DNS behavior, and configuration field updates deserve more attention than interface changes alone. Client updates, subscription updates, and rule-set updates are three different things: the first replaces the application, the second fetches connection and policy settings, and the third replaces the data used for matching. Completing one doesn't mean the others have changed.
If a problem appears after an update, test with your existing configuration and a clearly defined scenario, then check the logs and connection records. Note your operating system, client name, core, routing method, and error message, but don't share sensitive configuration. Reproduction steps are usually more helpful than simply saying that you can't connect. Download links for discontinued clients remain available for existing use cases; for long-term use, compare actively maintained alternatives first.
Common questions before getting started
Why do I need a subscription or configuration after installing the client?
A client provides tools for connecting and routing traffic; it doesn't include a working remote connection configuration. Subscriptions usually provide nodes, policy groups, and rules, while a manual configuration requires you to supply those details yourself. If you already have a link, check its format first, then follow the user guide to import and enable it. A rules file without a usable outbound connection can't establish a remote connection just by switching modes.
Which should I use: rule, global, or direct mode?
For everyday routing, start with rule mode, where traffic follows the matches in your configuration. Global mode generally sends traffic through the global policy, while direct mode connects without a proxy. These modes change how the core handles traffic; they don't make an app's traffic get routed through it in the first place. When testing, check both the mode and whether system proxy or TUN is working as expected. Follow the steps in the getting started guide to check each one.
Why are downloads or videos still slow when latency is low?
A latency test usually measures the time taken by one specific request. It doesn't directly tell you sustained transfer speed, packet loss, or whether the destination service is available. The test endpoint, connection reuse, and remote server load can all affect the result. Test with the app where you're actually seeing the problem, then check the policy and errors in the connection log. Don't keep changing configurations based on a single millisecond reading. For details, see latency tests vs. real-world speeds.
Why does the same subscription behave differently in different clients?
Clients can differ in core protocol support, configuration preprocessing, rule merging, and default DNS behavior. Some adapt imported content; others load it more directly. To compare them, use the same original configuration, temporarily disable extra overrides, and check the error logs. A successful import once doesn't prove full compatibility. Read the protocol guide first, then decide whether to adjust the configuration or switch clients.
Clash Usage Notes
Understand the mechanics behind common settings. After your first connection, start with the issue you're facing: interpret the test results, check how traffic is routed, then inspect the ports and local environment.
Learn how clients send speed-test requests, choose test endpoints, and set timeouts. Find out why low-latency nodes can still feel slow, and how bandwidth and packet loss affect the experience.
See how traffic reaches the client through system proxy settings or a virtual network adapter. Compare coverage for command-line tools, games, and UDP, with recommendations for different use cases.
Commands for finding processes using a port on Windows, macOS, and Linux; where to change mixed-port and the controller port; and which settings to update afterward.