Clash Tutorial: Subscription, Mode, Connection and Verification
Start with a working Clash subscription, then import the configuration, select Rule mode, route system traffic through the client, and check the result. Each step begins with a visible result from the previous one, making this guide easy to follow after a first installation.
Prepare the Client and a Valid Configuration Source
Before starting, install a Clash graphical client and obtain a Clash configuration source from your service provider. The most common source is a subscription URL beginning with https://; it may also be a local YAML configuration file. Subscription URLs, single-node links, and YAML files serve different purposes: a subscription URL can usually be updated periodically by the client, a YAML file is a complete configuration imported once, and a single-node link may not work directly in the client's subscription field.
If the client is not installed yet, open the client downloads page and choose a graphical client for your operating system. Windows and macOS users generally use desktop clients with system proxy controls and configuration management; Android and iOS use the system VPN interface to route traffic; Linux desktops can use graphical clients, while server and router environments require additional knowledge of the core, service management, and configuration paths. This page covers the shared first-connection workflow for graphical clients; deeper system integration is covered in the complete user guide.
After installation, start the client, but do not open other proxy tools, browser proxy extensions, or system-level traffic-routing programs at the same time. When multiple tools modify the system proxy, virtual network adapter, or DNS, it becomes difficult to tell which one is handling traffic. If another proxy app was used previously, exit it and check the system network settings for any leftover manual proxy address. Once these preparations are complete, begin with subscription import so each following step has a clear result to check.
Import a Clash Subscription and Confirm the Configuration
Find the Configuration or Subscription Page
After opening the client, look for the “Configuration,” “Subscription,” or “Profiles” page. This page stores configurations that the client can load; it is not the “Proxy” or “Proxies” page. The proxy page is used to choose policy groups and outbound nodes, and meaningful content appears there only after a configuration loads successfully. The configuration page commonly includes options for importing from a URL, importing a local file, setting an update interval, and viewing existing configurations.
If you received a subscription URL, choose “Import from URL” or an equivalent option and paste the address into the field from beginning to end. Do not add spaces, line breaks, or Chinese punctuation when copying it. You can give the configuration a recognizable service name, but the name only affects local display and does not change the subscription. After saving, click “Import,” “Download,” or “Update,” then wait for the client to finish the request.
If you received a YAML file, choose local file import and select a file with the .yaml or .yml extension. Do not paste part of the YAML file into the subscription URL field, and do not treat an ordinary webpage address as a subscription URL. For a clearer explanation of these formats, read Clash Subscription Links and YAML Configuration Explained.
Confirm That the Configuration Has Loaded
After a successful import, a new entry should appear in the configuration list. Select it to make it the active configuration, then open the “Proxy” page and inspect its contents. Normally you will see several policy groups, such as auto select, node selection, failover, or groups organized by purpose; the selectable nodes or other policies are inside those groups. Group names are determined by the configuration provider, so they do not need to match the examples exactly.
A brief “Import successful” message is not enough. Check that the configuration update time has changed, that policy groups appear on the proxy page, and that the runtime log contains no obvious YAML parsing errors. If an entry appears in the configuration list but the proxy page remains blank after switching to it, the imported content may not be a complete Clash configuration, or the client may not have set the new entry as active. Return to the configuration page, select the entry, and enable it or set it as the active configuration again.
If Import Fails, Check the Input Type First
If the client reports a network error, an unexpected status code, or a download failure, reopen your service provider's management page in a browser and confirm that the subscription is still valid before copying the URL again. Do not share the complete subscription URL in public webpages, screenshots, or group chats, because it can often be used to retrieve your personal configuration. If the client reports a YAML syntax error, the problem may be in the configuration rather than the network connection. Ask the provider to regenerate the configuration, or use the provider's clearly labeled Clash subscription entry.
Do not enable the system proxy immediately after importing. First confirm that the configuration displays policy groups, because the next step requires choosing an actual outbound option from them. The relationship between configurations and policy groups is extensive, so this guide covers only the checks needed to establish a connection. For a complete explanation of proxy groups, rule providers, and configuration structure, see the glossary and the system user guide.
Choose Rule Mode and the Main Policy Group
Start with Rule Mode
After the configuration loads, open the “Mode,” “Proxy Mode,” or “Mode” setting. Common options include Rule, Global, and Direct. For a first setup, choose Rule mode. It evaluates traffic against rules such as DOMAIN, IP-CIDR, GEOIP, and MATCH, then passes each connection to the designated policy group. This lets destinations that require a proxy use a proxy group while keeping local-network or explicitly direct destinations on a direct connection.
Global mode sends most traffic handled by the client to one global policy, which can help temporarily determine whether rules are causing access differences, but it should not be treated as the default without checking. Direct mode bypasses proxy nodes for handled traffic and is often useful for pausing proxy behavior or running comparison tests. These modes change traffic-routing logic; they do not start or stop the client. Even when the interface says “running,” Direct mode may show no change in the proxy outbound path.
Choose the Actual Outbound on the Proxy Page
After selecting Rule, open the “Proxy” or “Proxies” page. It usually displays policy groups in separate sections. Find the group responsible for choosing the main outbound; it may be named “Node Select,” “Proxy,” “PROXY,” or something else chosen by the configuration provider. Open that group and select a specific node, an auto-select group, or a failover group. If you are unsure, start with the auto-select option provided by the configuration. Do not switch options randomly across multiple levels: one policy group may reference another, and the final outbound depends on the complete reference chain.
Some clients display a latency-test button beside each node. A latency test only indicates whether the client can connect to a target under the test conditions and gives an approximate round-trip time; it does not by itself prove that every webpage will work. After making your selection, note the current main policy group and selected item. If a problem occurs while establishing the connection, you can return here and choose another working option without importing the entire subscription again.
Distinguish Proxy Mode from Traffic Routing
Rule, Global, and Direct determine how traffic is routed after it enters the client; the system proxy, VPN interface, and TUN determine which traffic enters the client in the first place. These are separate layers. On a desktop, enabling Rule without enabling the system proxy or TUN may leave an ordinary browser connecting directly. Conversely, with the system proxy enabled but Direct selected, traffic passes through the client but ultimately leaves through a direct connection.
This guide starts with the easiest setup to observe: enable the system proxy on desktop, and authorize the system VPN connection on mobile. TUN covers more applications that do not read system proxy settings, but it also involves a virtual network adapter, DNS, administrator permissions, and routing tables. There is no need to adjust every advanced option during the first connection. Complete one verifiable connection using the basic method, then read the TUN chapter in the manual if your applications require it.
Start the Core and Route System Traffic Through the Client
Start the Core First, Then Enable the System Proxy on Desktop
Windows and macOS clients usually expose “core running” and “system proxy” as two separate states. First click the start button, service mode option, or core switch, and confirm that the status changes from stopped to running. Then enable the “System Proxy” switch so the operating system sends requests from apps that support proxy settings to the client's listening port. Some macOS clients request system authorization the first time they modify network settings. Follow the system prompt, then return to the client and confirm that the switch remains enabled.
If the client offers options such as “Start at Login,” “Silent Start,” or “Restore System Proxy Automatically,” you can leave them unchanged during the first connection. Complete one manual start and verification first, confirm that the configuration works, and then decide whether to enable automation. This makes it easier to distinguish configuration errors, permission issues, and inconsistent startup order.
The process in a Linux graphical environment is similar to desktop clients, but different desktop environments may read system proxy settings differently. If a browser connects while command-line tools show no change, the client is not necessarily at fault; command-line programs may need to read environment variables separately or require TUN routing. These cross-application differences belong to system configuration and can be reviewed in the Linux and command-line traffic chapter after the basic connection works.
Allow the Mobile VPN Connection Request
Android and iOS clients use the system VPN interface to route traffic. After you tap the client's start button, the system displays a VPN connection confirmation. Read the prompt and allow the connection. A VPN indicator usually appears in the status bar, and the client interface shows that it is running. The VPN indicator means traffic is being handled by the current client's local interface; whether it ultimately connects directly or through a proxy is still determined by the rules and policy group selected in the previous step.
If Android disconnects soon after the screen locks, check the system's background activity and battery-use restrictions; avoid changing several power-saving options at once during the first connection. As long as a foreground test completes, continue to the next verification step. After confirming that the basic configuration works, adjust the settings one by one using Android VpnService and Background Operation Settings.
Check Status and Logs, Not Just the Switch Color
After starting the client, wait a few seconds and open its log page. A normal startup usually records configuration loading, listening-port creation, and network-interface initialization. The exact wording varies between cores, so do not look for one fixed message. Instead, confirm that the same error is not repeating continuously. A single failed connection may be an unrelated background request; if the same error appears every second, resolve it before continuing the test.
Common startup problems include a listening port occupied by another program, insufficient system proxy permissions, an unreadable configuration file, and an unreachable selected node. For a port conflict, exit other proxy tools and restart the client. If a node fails to connect, return to the proxy page and choose another option. If the configuration cannot be read, return to the first step and select the active configuration again. Avoid repeatedly toggling several advanced switches while an error is present, as this makes troubleshooting harder to follow.
Verify the Connection, Matched Rules, and Direct Paths
Generate an Observable Request in the Browser
Keep the client running, fully close and reopen a browser window, and visit a webpage you want to test. Reopening the browser reduces interference from existing connections and cached data. A page loading is only the first result; return to the client and open its “Connections,” “Logs,” or “Connections” page to confirm that the browser request actually entered the client.
Find the domain you just visited in the connection records. The record usually shows the destination address, matched rule, policy group, and final outbound. If the record exists and the outbound matches the proxy policy selected in step two, both system traffic routing and rule-based routing are working. If the page loads but the connection records do not change at all, the browser may be bypassing the system proxy or the client may not be handling that application. Check the system proxy switch first instead of changing the subscription again.
Test a Proxied Destination and a Direct Destination Separately
Rule mode is not meant to make every request follow the same path; it routes different destinations according to the configuration rules. Run at least two tests: visit one destination expected to use the proxy and one commonly used site expected to connect directly. Compare the rules and outbounds in both connection records. If the proxied destination enters the main proxy group while the direct destination shows DIRECT or an equivalent direct policy, basic Rule-mode routing is working.
If every request enters the same proxy group, first confirm that the mode is not Global. If every request shows a direct connection, confirm that the mode is not Direct and that the main policy group has not accidentally selected DIRECT. If a matched rule differs from expectations, do not infer the result from the domain name alone. Clash matches rules from top to bottom, so an earlier rule may already have determined the route. For details on rule order, the MATCH fallback, and rule providers, see the rule-routing chapter in the system manual.
Use a Status Change for a Comparison Test
To rule out webpage caching, run a reversible comparison: keep the client running, temporarily switch the mode to Direct, reload the test page, and observe the new connection record; then switch immediately back to Rule and load it once more. The outbound in the two records should change with the mode. When finished, restore Rule and confirm that the main policy group is still set to the option you selected earlier.
If connection records show that traffic used the proxy but the webpage still does not work, the problem is usually related to the node connection, DNS resolution, restrictions imposed by the destination service, or the certificate environment rather than the system proxy switch itself. First try another working option in the same policy group, then check the error type in the logs. Timeouts, resolution failures, and certificate errors require different troubleshooting orders; see the Troubleshooting FAQ and HTTPS Certificate Errors Explained.
You can also visit a familiar network-information lookup page and compare the outbound information before and after connecting, but do not rely on a single website's result. Browser extensions, cached data, and IPv4-versus-IPv6 path differences can affect one-off results. The most reliable basic check combines three pieces of evidence: the request appears in the client's connection records, the matched rule is expected, and the webpage loads successfully. The configuration is complete only when all three are true.
Routine Updates and Recovery After Setup
After the basic connection passes verification, routine use usually requires maintaining only three states: the active configuration, the main policy group, and the traffic-routing switch. When subscription content changes, click Update on the configuration page and confirm that the active configuration has not changed. When a node becomes unavailable, switch to another option within the main policy group instead of repeatedly deleting and reimporting the subscription. When you are done using the client, disable the system proxy or mobile connection before exiting so the system network state remains clear.
Do not treat subscription updates, mode changes, TUN, DNS, and the system proxy as one combined switch. Configuration updates fetch new rules and policies; the mode determines how traffic is distributed; the policy group determines the actual outbound; and the system proxy or VPN interface sends traffic into the client. Once these four layers are clear, most problems can be localized by checking the current state of each one.
Basic Setup Checklist
- Configuration: The subscription has been imported and the active configuration updates normally.
- Mode: Keep Rule for everyday use, with a specific option selected in the main policy group.
- Connection: The core is running, and the system proxy or mobile VPN is enabled.
- Verification: Connection records show the domain, matched rule, and final outbound.
- Recovery: When something goes wrong, check configuration, policy group, traffic-routing method, and logs in that order.
If all four steps are complete, continue with the complete guide from beginner to advanced, covering client selection, rule structure, TUN, DNS, and routine maintenance. If you need to solve one specific problem, start with the Frequently Asked Questions. For unfamiliar configuration terms, browse the Clash glossary by category instead of introducing too many advanced settings during the basic workflow.