Choose a client for your operating system, then follow verifiable steps to complete subscription imports, rules and routing, and DNS configuration. The documentation covers everything from first connection to TUN, Fake-IP, and rule-set maintenance.
Free foreverOpen-source codeEnglish documentationConfiguration examples you can verify
Capability profiles: from rule matches to system-wide traffic capture
Clash configuration is not just a collection of unrelated toggles. A request first goes through DNS resolution, then matches rules in order, and is handed to a proxy group that decides whether to connect directly, use a proxy, or reject it. The profiles below explain common capabilities separately while retaining verifiable configuration keys and interface states.
Current profile
Rules match in configuration order; proxy groups make the final choice
Clash checks requests from the first line of rules and stops at the first match. Put exact domain rules before broad rule sets, with the fallback MATCH rule usually at the end. Proxy groups separate the rule result from the actual node: a rule sends traffic to a group such as PROXY, DIRECT, or a custom group, while the group type and user selection determine the final exit.
When troubleshooting routing, first confirm that the configuration has been reloaded, then inspect the destination domain, matched rule, and selected policy in the connection details. Unlike proxy tools with only a global toggle, Clash lets you verify rule order, policy names, and the final exit step by step—useful when direct connections to mainland China, proxies for selected domains, and LAN exceptions must coexist.
DOMAIN,api.example.com,PROXYExact domain
DOMAIN-SUFFIX,example.org,PROXYDomain suffix
GEOIP,CN,DIRECT,no-resolveIP geolocation
MATCH,FINALFallback match
Matching: top to bottomExit control: proxy groupsVerification: connection logs
DNS profile
Bring domain resolution into routing decisions
With built-in DNS enabled, the client can choose a listening address, upstream resolvers, fallback resolvers, and an enhanced mode. Fake-IP returns a reserved address first, then the core stores a mapping between the domain and that address so connections carrying only the destination IP can recover the domain and participate in domain-rule matching. This improves rule visibility; it does not change the real website address.
Before configuring it, make sure no other local service is using the listening port, then decide whether to listen on external interfaces based on your LAN-sharing needs. If LAN devices, printers, or special applications are incompatible, add their domains to fake-ip-filter. Check resolution results, rule matches, and upstream reachability in that order instead of changing several DNS parameters at once.
Enhanced mode: Fake-IPFilter key: fake-ip-filterVerification: DNS queries and logs
Traffic-capture profile
System proxy and TUN mode handle different traffic scopes
A system proxy mainly affects applications that follow the operating system's proxy settings, such as browsers and some desktop software. TUN mode uses a virtual network interface to capture a broader range of TCP and UDP traffic, making it useful for programs that ignore system proxy settings. You do not have to enable both. For a first setup, verify the subscription, nodes, and rules with the system proxy, then add TUN if specific applications require it.
TUN startup failures are commonly related to permissions, virtual adapters, route conflicts, or other network tools. Keep one variable clear while troubleshooting: quit similar software, confirm administrator privileges, and check the client log for the interface creation result. LAN sharing also requires enabling allow-lan separately and allowing the listening port through the firewall.
System proxyFor applications that follow proxy settings
TUN modeCapture traffic through a virtual interface
Allow LANExpose the listening port to devices on the same network
Basic capture: system proxyExtended capture: TUNShared configuration: allow-lan
Configuration profile
Subscriptions provide remote content; local overrides preserve personal settings
Subscriptions are usually maintained by the service provider. Refreshing one rewrites its proxy nodes, proxy groups, and rules. Direct edits to a generated subscription file may be overwritten at the next update. A more reliable approach is to place ports, DNS settings, rule patches, and policy changes in the client's supported override or merge features, keeping a clear boundary between remote configuration and local changes.
When an import fails, check that the link is complete, authorization is not required or has been provided, and the response is actually Clash-compatible YAML. If the import succeeds but connections fail, check whether a usable option is selected in the proxy group, whether the configuration passes syntax checks, and whether the system proxy is enabled. Validate “fetching the configuration” and “using the configuration” separately; this is faster than repeatedly importing it.
Connection detailsView the destination, matched rule, proxy group, and actual exit to distinguish rule issues from node issues.
Domain sniffingRecover domains from connections where applicable, providing fuller information for domain-rule matching.
External rule setsUse rule-providers to update rule content independently and reduce maintenance of the main configuration file.
Control interfaceConnect compatible panels through a controlled interface to view connections, logs, rules, and policy status.
Platform entry
Open the download page by operating system
The home page provides platform links only; it does not distribute installer files directly. On the download page, compare system architecture, client maintenance status, and installation method before choosing software. On mobile, also check system permissions and background-execution limits.
Windows
Desktop clients and system proxy
Best for desktop users who need a graphical interface, rule inspection, and launch at startup. Confirm your system architecture before downloading, import the configuration after installation, and then enable the system proxy. If a store app cannot connect, see the UWP loopback guide.
macOS installers are usually separated by processor architecture. Check the chip type in “About This Mac,” then choose the matching build. On first launch, follow macOS prompts to grant network-extension or proxy-modification permissions instead of repeatedly switching between clients.
Android clients use the system VpnService to create a local VPN connection. Confirm the authorization prompt on first connection. If the connection drops frequently after the screen locks, add the client to the battery-optimization whitelist and allow background activity plus any required auto-start permission.
iPhone and iPad clients are obtained through the App Store. After importing a subscription, the first connection requests permission to add a VPN configuration. The client can establish a network tunnel only after the corresponding VPN entry appears in system settings and authorization is complete.
Choose a graphical client for desktop environments; servers, routers, and containers are often better suited to running the Mihomo core directly. Before deployment, define the service user, configuration directory, log location, and startup method to simplify updates and troubleshooting.
If you are unsure which client to use, open the download page for your platform first, then check each client card's compatibility notes and maintenance status.
Installation alone does not mean traffic is passing through Clash. Complete configuration import, policy selection, and system traffic capture in order, then verify the result in the connection log. Each step depends on the previous one: without a valid configuration there are no proxy groups, without a usable policy you cannot assess connection problems, and without traffic capture the browser continues using its original network path.
In the client's configuration, subscription, or Profiles page, paste the complete link and wait for it to download and pass syntax parsing. For a local YAML file, use the file-import function. After importing, you should see a configuration name, proxy groups, and rules—not just an empty list. If a format error appears, inspect the response returned by the link before clicking update repeatedly.
02
Choose a mode and policy
For everyday use, start with rule mode so requests are routed according to the configured rules. Open the proxy or policy page and choose an available exit in the primary proxy group. An automatic group follows its own logic, while a manual group uses the currently selected option. Global mode is useful for short-term testing, not as a replacement for maintaining rule configuration.
03
Enable traffic capture and verify the match
On desktop, enable the system proxy first; on mobile, confirm VPN authorization. Visit a target site, then inspect its domain, rule, and policy route on the client's connection page. Opening a webpage only proves that a connection works. The routing configuration is confirmed only when the match result is as expected. If a game or specialized program needs capture, evaluate TUN afterward.
Open-source context
Open-source ecosystem, core relationships, and update boundaries
Clash-related clients are made up of multiple independent projects. When evaluating a product's source, features, and maintenance status, check the core, graphical interface, configuration format, and release channel separately rather than relying only on whether its name contains Clash.
Project history shaped today's ecosystem
Clash originally established a broad client ecosystem around a rule-driven proxy core and YAML configuration. After the original project stopped updating, compatible community cores and graphical clients continued to be maintained independently. Today's desktop and mobile clients may use the Mihomo core, or they may include their own service layer and configuration interface. Shared rule syntax does not mean identical interface features, so the guides distinguish general configuration principles from client-specific steps.
When downloading, check three facts: which operating system the software targets, which core it includes or calls, and whether the project still publishes updates. A discontinued client may still be useful for viewing older configurations, but should not be assumed to support every feature in newer cores. The download page places maintenance status and platform architecture on the same card, reducing mistakes caused by choosing software based only on an old tutorial's title.
Mihomo continues and extends configuration capabilities
Mihomo is one of the commonly used Clash-compatible cores. It retains core concepts such as rules, proxy groups, DNS, and the control interface while continuing to support richer rule sets, TUN, domain sniffing, and configuration features. Graphical clients turn these capabilities into settings, status pages, and import flows; the core parses configuration, establishes connections, executes rules, and writes logs.
When setting names differ, refer back to configuration keys and logs. For example, “Allow LAN” in the interface usually maps to allow-lan, “Mixed port” to mixed-port, and “Enhanced mode” may map to DNS's enhanced-mode. Using configuration keys as a shared language is more reliable than following a screenshot of an old interface.
Treat client, core, and configuration updates as three separate layers
Client updates fix interface, system-integration, and installation issues. Core updates may change protocols, rules, or the network stack. Subscription updates mainly change nodes, proxy groups, and remote rules. Their sources and release cycles differ. When a problem appears, note which layer changed most recently before deciding whether to roll back configuration, reload the subscription, or read the client's release notes.
Rule sets can also be updated independently of the main configuration. After external rules are referenced through rule-providers, the main file only needs to retain the rule-set name, behavior type, source, and refresh interval. This simplifies maintenance, but you must still verify that the rule-set format matches behavior and that the referenced name actually exists in rules.
Verify the source
Confirm that the project name, release channel, and supported platform match. Similarly named clients may be developed by different maintainers, with different installer formats and configuration directories. The download page groups clients by platform to prevent mistaking a core archive for a graphical application installer.
Verify the configuration
Start by using the client's syntax checker or logs to confirm that the YAML loaded successfully. Indentation errors, duplicate keys, mismatched policy names, and missing rule references can prevent loading or produce routing results different from what you expect.
Verify runtime behavior
Review the destination domain, destination address, matched rule, and policy chain in the connection log. Judging configuration only by whether a webpage opens mixes DNS, rule, node, and system-proxy problems together and makes troubleshooting broader than necessary.
Selected questions
Four common checks for first-time users
The sections below are troubleshooting starting points only. The full Q&A is organized in the Help Center by fundamentals, installation and configuration, usage tips, and troubleshooting.
The subscription imported successfully. Why hasn't my system network changed?
Importing a configuration only loads the data. You still need to select that configuration, choose an exit in the primary proxy group, and enable the system proxy or mobile VPN. Then check the connection log. If no new connections appear, first verify that system traffic capture is enabled instead of importing the subscription again. Continue with the first-connection guide.
How do I choose between rule, global, and direct mode?
Rule mode matches requests against the configuration one by one and suits everyday use. Global mode sends most requests through one policy and is useful for brief exit testing. Direct mode helps confirm the local network or temporarily bypass the proxy. Switching modes cannot fix an invalid subscription; inspect the specific connection and logs while troubleshooting.
A rule is present but never matches. What should I check first?
First confirm that the configuration was saved and reloaded. Then check that the rule appears before broader rules, that its policy name exists, and that the target connection still includes a domain. Once an earlier rule matches, later rules are not evaluated. See the advanced configuration manual for syntax and priority details.
I cannot connect after enabling TUN. How can I narrow down the cause?
Disable TUN first and confirm that the system-proxy mode connects normally. Then quit other VPNs, virtual-adapter tools, and network filters, and check administrator permissions and the client log. If the basic proxy also fails, address the configuration, DNS, or policy issue first. See the Help Center for more troubleshooting categories.
The Help Center also covers Clash UWP loopback, GeoIP updates, LAN sharing, Fake-IP filtering, and system-proxy settings.
Each article focuses on one scenario and provides configuration keys, navigation paths, and verification steps. For a systematic reference to all parameters, use the advanced configuration manual; for an end-to-end workflow, use the first-connection guide.
Starting with mixed-port and allow-lan, this guide explains the listening address, firewall access, proxy settings for mobile devices, and the troubleshooting order for failed connections.
Explains the authorization flow for Android's local VPN and outlines how to troubleshoot background activity, battery policies, and disconnects after screen lock—useful when the system frequently terminates the client.
Covers common rule types, top-to-bottom matching order, and the no-resolve parameter, with reusable troubleshooting steps for rules that fail to match.
The article list also covers getting iPhone clients, routing structures for mainland China and destinations outside China, and maintaining custom rules.