Import a Clash Subscription and Make Your First Connection

PRECHECK / READY

Before You Start: Check the Client, Subscription, and System Time

Before configuring Clash, confirm that a maintained client compatible with your system is installed. On desktop, distinguish between Windows, macOS, and Linux; on macOS, also choose between Intel and Apple Silicon. On mobile, select the Android or iOS version from the appropriate app store or download page. If the client is not installed yet, open the Download Center, choose the client for your platform, install it, and then return here.

You will also need a working subscription URL or YAML configuration file. Subscription URLs are usually generated by the service provider and let the client download nodes, policy groups, rules, DNS settings, and other configuration. When copying a URL, select everything from the beginning to the end. Do not omit query parameters or add spaces before or after it. A subscription URL contains account configuration details and should not be posted in screenshots, public logs, or chat groups.

A local file ending in .yaml or .yml can also be loaded through the client’s file import function, but it will not automatically receive updates from a remote subscription. Before using it, confirm whether the provider supplied a “subscription URL” or a “configuration file.” Do not mistake a web dashboard URL, order page URL, or single-node share text for a Clash subscription.

Finally, check the system date, time, and time zone. An incorrect clock can prevent secure connections, causing all nodes to time out, certificate timestamps to appear invalid, or subscription requests to fail. Enable automatic time synchronization, then confirm that the network itself can reach the subscription URL. Once ready, keep the client open and continue to Step 1.

STEP 02 / MODE SELECT

Choose a Proxy Mode: Decide How Traffic Is Handled

Choose Rule Mode for Your First Setup

Open the Settings, Configuration, or Mode page and find options such as Rule, Global, and Direct. For your first connection, choose Rule mode. It evaluates each connection against the rules in the configuration and determines whether to proxy, connect directly, or reject it. Common local network addresses and some local services can remain direct, while destinations that require a proxy are handled by policy groups. This is the standard setup for most subscription configurations.

Global mode usually sends most connections through a single proxy policy. It is useful for briefly checking whether a rule is preventing a website from using the proxy, but it is not a universal fix. Direct mode bypasses proxying and is useful for temporary pauses or comparison tests. These modes change traffic decisions; they do not replace node selection or repair unavailable nodes automatically.

Select a Node in a Policy Group

Switch to the Proxies, Proxy, or Policies page. This is usually not a simple node list but a collection of policy groups. Common names include “Node Selection,” “Proxy,” “Auto Select,” and “Failover,” or groups organized by website purpose. Find the group handling most of your traffic, then choose a specific node or use an automatic testing group supplied by the subscription.

If policy groups reference one another, the top-level group may point to a regional group that contains the actual nodes. Follow the current selection through each level until it reaches an available node. Do not stop when the top level says “Auto Select”; confirm that the automatic group has candidates and that at least one node can connect successfully after testing.

If the client offers latency testing, run a test on the current group first. The latency value reflects response time under those conditions and does not equal download speed or guarantee access to every website. For the initial setup, choose one node that responds normally; there is no need to chase the lowest number. See the Glossary for node regions, multipliers, protocols, and automatic policy behavior.

Keep the Original Rules

Avoid editing rules, DNS, or policy-group structures during the first connection. Subscription configurations usually include a workable baseline; verify that the original configuration connects before customizing it. Adding custom rules too early can mix together unavailable nodes, a disabled system proxy, and incorrect rules, making troubleshooting harder.

If a domain must use a specific policy, handle it after the first successful connection and first understand that rules are matched from top to bottom and stop at the first match. Rule syntax, common fields, and override merging are covered systematically in the Rules section of the Configuration Reference. For now, keep Rule mode enabled, confirm that the main policy group has a selected node, and continue to the connection step.

STEP 04 / VERIFY ROUTE

Verify That It Works: Cross-Check the Webpage, Connections, and Logs

Start with a Basic Browser Test

Keep the client connected, open a new browser window, and visit a target website that normally requires a proxy. Do not merely refresh a page that was already open before connecting; browser cache, existing connections, and DNS results can affect the test. After it loads, visit a site that normally should remain direct to confirm that both traffic types work in Rule mode.

If the client provides a Connections, Active Connections, or activity log page, watch it while visiting the site. Normally, the relevant domain or destination appears with the matched rule, policy group, and final node. Connection records are more reliable than the webpage alone: a page may load from cache, while the records show whether the new request entered Clash.

Confirm the Rule and Node Path

Find the domain you just visited in the connection records and check which rule matched it. If the target shows DIRECT, the rule classified it as a direct connection. If it was expected to use the proxy, briefly compare with Global mode. If it works globally but fails in Rule mode, the issue is usually the rule or policy selection. Switch back to Rule after testing instead of staying in Global mode.

If the record shows that the request entered a proxy policy but the page still will not load, return to Proxies and try another node, then visit the site again. Do not change the mode, DNS, TUN, and subscription at the same time; change one condition at a time so you know what affected the result. If several nodes fail, check for a recent subscription update, a stable device connection, and any service status notice.

Use Logs to Locate the Failure

If the page does not load, open the Logs, Runtime Logs, or activity records and review entries from the time of the test onward. Configuration parsing errors usually appear when starting or switching configurations; connection timeouts occur while contacting a node; DNS problems may appear as domain-resolution failures; and a port conflict can prevent the local proxy listener from starting. Do not capture only the final line. Keep the surrounding sequence, because timing is often more informative than a single error term.

If no new request appears in the logs, first check whether the system proxy is enabled, whether mobile connection permission is active, and whether the browser uses its own proxy settings. If the request appears but the node connection fails, check the node and subscription. If the node connects but domain resolution fails, investigate DNS. Following the traffic path helps avoid reinstalling the client or making major configuration changes too early.

Keep a Recoverable Setup After Testing

After verification succeeds, keep the working node and Rule mode. Note the active configuration name and confirm that the subscription page can update manually. If a problem occurs later, restore this verified setup first, then determine whether the cause is a changed node, a subscription update, or a change in the local network. To pause use, disable the system proxy on desktop or disconnect on mobile; there is no need to delete the subscription.

If the connection still fails after these checks, open Common Issues and continue under “Installation and Configuration” or “Troubleshooting.” Log analysis, DNS, TUN, port conflicts, and configuration parsing are separate issues; handling them separately is more effective than repeatedly reinstalling the client.