Import a Clash Subscription and Verify the Connection

Before you begin

Before starting, prepare an installed Clash graphical client and either the subscription URL provided by your service provider or a YAML configuration file ready for import. A subscription URL is usually a link beginning with https://; YAML files commonly end in .yaml or .yml. You only need one of these. Do not paste a web dashboard login URL, plan page URL, or QR code screenshot as subscription text.

If the client is not installed yet, choose your platform from the client download page. Windows and macOS users can usually open the graphical interface after installation. Android and iOS will request system VPN permission the first time a connection is created; approve it when prompted. On Linux, desktop users may launch the app from the application menu, while server environments are better suited to the core and command-line configuration, which is outside this lightweight guide.

For the first setup, temporarily close other running proxies, VPNs, and network-filtering tools. Multiple programs changing the system proxy or listening on the same port can make the client appear active while the browser bypasses the current configuration. Quit older programs before opening the Clash client to reduce port and routing conflicts. If a work or campus network requires a fixed proxy, record the original settings first so they can be restored later.

Also make sure the system clock is accurate. Subscription services and some encrypted connections rely on correct time information; a large date or time-zone mismatch may appear as failed subscription updates, failed handshakes, or certificate errors. Once these checks are complete, keep the client window open and begin the next step from the configuration page.

Choose a proxy mode

Use Rule mode for first-time setup

Once the configuration is loaded, open the Proxy, Proxies, or Mode page. Find the global mode selector, which usually offers Rule, Global, and Direct. For first-time setup, choose Rule mode. In this mode, each connection is matched against the configuration's rules from top to bottom, then sent through a proxy policy, connected directly, or blocked. Everyday web traffic and local network traffic do not have to follow the same path.

Global mode sends most traffic through one policy or node. It can help determine temporarily whether a site works through a specific node, but it is not a good default when you do not yet understand the configuration. Direct mode bypasses proxy policies and is useful for quickly checking whether a problem is related to the proxy path. These modes change traffic handling; they do not delete the subscription or alter the nodes. Switch back to Rule mode after troubleshooting.

Choose an available node for the policy group

After selecting Rule mode, inspect the policy groups. Each group is an endpoint that rules ultimately point to; it may contain individual nodes or another auto-select group. Expand the main group whose name is closest to Node Select, Proxy Select, or Proxy. If it contains Auto Select or Latency Select, choose the automatic policy first. If it contains only individual nodes, choose one marked available by the service provider.

Some clients provide a latency-test button beside each node. The result only describes the response from the client to the test target; it is not the actual speed for every website. During first-time setup, do not repeatedly chase the lowest number. A returned result and an available status are enough to continue. If every node times out, refresh the subscription first and check whether this device can open ordinary web pages. Do not change DNS, ports, and rules at the same time, or it will be difficult to identify the cause.

The configuration may also include separate policy groups for streaming media, messaging, AI services, or software downloads. For the first setup, keep their defaults and work only with the main proxy group. These subgroups often reference the main group, so choosing a node there provides an available exit for related rules. Differences between the terms policy group, node, and rule can be checked in the glossary.

Make sure the mode is not being overridden

Some clients remember the selected mode, while some configurations use overrides to lock runtime parameters. After choosing Rule mode, switch to another page and return to confirm that the interface still shows Rule. If it changes back automatically, check Overrides, included configurations, or startup settings in Settings. Temporarily disable unclear mode overrides, then select Rule mode again. Leave the main policy group pointed to an available node before starting the system connection.

Verify that it works

Check whether the client receives requests

Open a browser and refresh a familiar webpage, then switch to the client's Connections or Logs page. You should see the browser's domain, destination, matched rule, and selected policy. New connections appearing continuously mean that browser traffic has reached Clash. If the list does not change at all, check whether the system proxy is enabled, whether the browser uses its own proxy settings, and whether the client is still running in the background.

The rule information in the connection list is useful. A local website may show DIRECT, meaning it was connected directly according to the rules; a site that should use a proxy should show the main proxy group or a specific node. If every request follows the same path, first check whether the mode was accidentally set to Global or Direct. A page loading by itself does not prove the configuration is correct, because a site that already works directly cannot confirm that the proxy path is active.

Check the exit result

Next, visit a trusted IP or network-exit lookup page and note the reported region or network information. Switch to Direct mode and refresh once, then switch back to Rule mode and refresh again to compare the results. If the test request uses the selected node in Rule mode but returns to the local network exit in Direct mode, the system proxy, core, and policy group are working together. Restore Rule mode after the comparison.

If the exit result does not change but the client connection list shows the request, check which rule matched it. Some test sites may be assigned DIRECT by the configuration, which does not mean the proxy is broken. Test another target that is clearly expected to use a proxy and inspect its policy chain in the connection details. Why a rule matches a policy and how rules are evaluated from top to bottom are covered in the rule syntax reference.

Test direct and proxy paths separately

A complete check should cover both types of request: one website expected to connect directly and one expected to use the proxy. The direct site should load normally and show DIRECT or the relevant direct group in the connection record; the proxied site should show the proxy policy group and the actual node. Only when both match expectations can you confirm that Rule mode is connected and routing traffic correctly.

Run one more subscription refresh test. Return to the configuration page, click Refresh, and confirm that the update time changes while the active configuration remains selected. After the refresh, reopen the proxy page and check whether the main policy group selection was preserved. Some subscription updates rebuild policy contents; if the selected node was removed, the client may return to a default. Select an available node again; reinstalling the client is not necessary.

Save a reproducible working state

After verification, remember four key details: the active configuration name, running mode, main policy group selection, and system proxy or TUN status. If access fails later, compare these four items first; they often reveal that the configuration changed, the mode was switched, the node stopped working, or system capture was disabled. Before editing YAML, keep a copy that loads successfully so you can revert if a syntax problem appears.