Clash Quick Start: From Subscription Import to Connection Verification

Before you start, make sure a working Clash graphical client is installed and that you have obtained a subscription URL from your service provider. The client reads the configuration and forwards traffic; the subscription URL supplies nodes, policy groups, rules, DNS settings, and other configuration data. They are not the same thing. With only the client installed and no configuration imported, the proxy page is usually empty and no usable nodes are created automatically.

A subscription URL is usually a link beginning with HTTPS. Copy it from your service provider's control panel using the full-copy function to avoid missing trailing characters during manual selection. Do not post the URL in forums, screenshots, or shared documents: it may contain access parameters that identify your account. If the provider offers a general subscription, a Clash subscription, and individual node links, choose the one explicitly labeled Clash or compatible with Clash configuration.

For the first setup, temporarily disable other proxies, VPNs, accelerators, or older Clash clients that are controlling network traffic. Multiple system proxies, VPN profiles, or virtual network adapters can intercept traffic repeatedly, making the client appear connected while pages time out, some apps lose connectivity, or the outbound address stays unchanged. Exit conflicting software before starting to make troubleshooting more straightforward.

After opening the client, look for a page named Subscription, Configuration, Profiles, or Configurations. Desktop clients usually place it in the left navigation, while mobile clients may put it in a configuration area on the home screen or in the top-right menu. Choose Add, Add Subscription, or Import from URL, then paste the complete subscription link into the address field. Use the provider name or a purpose such as Daily Configuration as the name so you can manage multiple configurations later.

After saving, choose Download, Update, or Sync. The client will request the subscription and parse its configuration file; a new configuration entry should appear when this finishes. Do not stop at confirming that the entry exists: make sure it is selected as the active configuration. Some clients enable imported configurations automatically, while others continue using the previous local configuration until you click its name, enable it, or choose Set as Active. The active configuration usually has a check mark, an accent border, or an enabled status.

Next, open the Proxy or Policy Groups page and check for nodes and policy groups. Providers often use custom policy-group names, so the interface may not resemble screenshots from other guides. If you can see several policy groups and, when expanded, options such as nodes, automatic selection, or direct connection, the configuration was parsed successfully. If the page is still empty, return to the configuration page and check the update result instead of enabling the system proxy immediately.

When a subscription update fails, first read the error category shown by the client. A timeout or unreachable-network message usually means the current network cannot access the subscription URL. A format, parse, or YAML error means the response is not a Clash configuration the client can read. An unauthorized message or unexpected status code means you should check with the provider whether the subscription has expired, been reset, or needs to be regenerated. Repeatedly clicking Update will not normally fix formatting or permission problems.

If the current network requires an existing proxy to reach the subscription, keep that working network available for the first download, then switch to the new configuration. Some clients offer an option to update subscriptions through a proxy, but its location and behavior vary considerably, so avoid changing it during the initial setup. To migrate a local YAML file, change the update interval, or merge multiple configurations, continue with the Preparation and Configuration section of the multi-platform configuration guide.

Once the configuration is loaded, open Settings, Proxy Mode, or the Mode section. Common choices include Rule, Global, and Direct modes. Rule mode is recommended for first-time use. It matches domains, IPs, application processes, or geographic rules from top to bottom, then sends traffic to the selected policy group, connects directly, or blocks it. This preserves the subscription's intended routing logic and is the most common choice for everyday use.

Global mode sends most interceptable traffic through a single proxy policy. It is useful for briefly checking whether a routing rule causes an access problem, but it should not be the default answer to every issue. If a destination fails in Rule mode but works in Global mode, inspect the matching rule or policy group instead of repeatedly changing clients. Direct mode bypasses the proxy and can quickly show whether the proxy path is causing the outage.

After selecting Rule mode, open the Proxy page and find the policy group handling the main proxy traffic. It may be named Proxy, Node Selection, Proxy, Manual Selection, or something custom from the provider. Expand the group and choose an available node. If the client offers a latency test, run it once if useful, but remember that latency only reflects the probe response and does not prove that every website or app will work. Actual access after connecting is still required.

For now, do not casually change the internals of groups such as Auto Select, Failover, or Load Balance. Subscription configurations often reference multiple policy groups, so an apparent automatic policy may depend on the status of a lower-level node group. The goal of the first setup is a clear, testable route; selecting the subscription's preset policy or one explicit node is enough. After the basic connection works, explore automatic switching and custom rules as needed.

Choosing a mode and node does not mean system traffic is already reaching Clash. It only defines how the client should handle traffic once it receives it. The next step is to enable the system proxy, system VPN, or TUN so the target app actually sends traffic to the client.

On Windows, macOS, and common Linux desktop environments, look for System Proxy, or a Set as System Proxy switch. Once enabled, the client writes its proxy address to the operating system settings, allowing browsers and most system-proxy-aware apps to send HTTP and HTTPS requests through Clash. For the first setup, enable only the system proxy and avoid multiple interception methods so the effect of each switch remains clear.

Android and iOS clients generally use the system VPN interface to intercept traffic. After you tap Start, Connect, or the main-page switch, the system will request permission to create a VPN configuration. Confirm that the app name matches the installed client, then allow the connection. After authorization, a VPN indicator usually appears in the system status area and the client home screen shows Running or Connected. If permission was previously denied, open the system VPN settings or tap Connect again to request it once more.

Some clients also offer TUN mode. TUN creates a virtual network interface for apps that ignore the system proxy, certain command-line tools, or scenarios requiring broader traffic interception. It commonly involves administrator permissions, drivers, routing, and DNS settings. It is not necessary for a first setup. Verify the browser with the system proxy first; only configure TUN through the TUN mode configuration section when a specific app clearly ignores the system proxy.

After enabling traffic interception, watch the client's status and log areas. Normally, logs show connection entries as web requests are made, while the Proxy page retains the selected policy group. If enabling the system proxy immediately cuts off the entire network, turn it off to restore connectivity, then check whether the active configuration is valid, the client core is running, and the proxy port is occupied by another program. Avoid switching several unfamiliar options repeatedly while offline, as this makes diagnosis harder.

Also pay attention to how the desktop client exits. Some clients keep running in the notification area after the window closes, leaving the system proxy enabled; others restore system settings when they exit. Do not force-kill the process before testing is complete. If the system proxy still points to a client that has exited, the browser cannot find the proxy port and loses network access. Restart the client and disable the system proxy, or restore automatic and manual proxy settings in the operating system's network settings.

After the connection is established, do not rush to change DNS, mixed ports, LAN sharing, or bypass lists. Keep the current configuration unchanged and open a new browser window for the next verification step. If something goes wrong, this limits the possible causes to the subscription, policy selection, and system proxy instead of a large set of advanced settings.

Do not verify the setup by looking only at the client switch. An enabled status means the program is running, but it does not prove that the browser uses the proxy, that the expected rule matched, or that the current node can reach the destination. The most direct method is to record the device's outbound network information before connecting, then reopen and refresh the lookup page after connecting. Compare the outbound address or network location. Use a new private window or a full refresh to avoid stale browser results.

Next, visit one familiar site that should use a direct connection and one destination expected to go through the proxy. In Rule mode, different policies for these requests are normal. Return to the client's connection records or logs and check the rule and policy name for each domain. If a proxied destination matches Direct, inspect the rules or configuration. If it matches the proxy policy but still fails, check the node, network path, or destination service.

Test the apps you actually need to use as well. A working browser does not mean every program follows the system proxy. Command-line tools, games, store apps, and some desktop software may use their own network settings. If the browser works but an app still connects directly, check the app's own proxy options before deciding whether TUN is needed. One app failing does not by itself mean the entire Clash configuration is broken.

During verification, make one controlled comparison between Rule and Global modes: keep the same node and retry the same destination after changing only the mode. If Global works but Rule does not, inspect the rule and policy group matched by the domain. If neither mode works, compare with another clearly available node. Change one condition at a time so you can identify which setting affects the result.

After verification, switch back to Rule mode for everyday use and confirm that the system proxy or VPN state is as expected. For temporary use, disable the connection in the client before exiting. On desktop, also open the system network settings to make sure no manual proxy still points to a local port. On mobile, confirm that the VPN indicator has disappeared from the status bar.

When something fails, check from configuration loading onward instead of changing the subscription, node, mode, DNS, and TUN all at once. The Clash request path can be simplified as follows: the app sends traffic to the client, the client reads the active configuration, rules select a policy, and the policy selects a node. If any link is missing, webpages may fail to load, so the order of troubleshooting matters more than repeatedly toggling switches.

If the issue remains after following these steps, save the client logs from when the error occurs, the operating system version, client name, current interception method, and reproducible steps, then continue with the configuration FAQ section. Remove subscription URLs, account parameters, and other sensitive content before sharing logs.