Clash Client Setup Guide: From Subscription Import to Connection Verification

A subscription link is a URL starting with https://, provided by your service provider on their account or subscription page, usually next to a "Copy Subscription Link" or "Copy" button. Once the client fetches this URL, it receives a complete profile containing a node list and routing rules. The link itself isn't tied to any specific client — the same link works in any Clash-based client. If you're unsure about terms like "subscription" or "profile," check the Terminology Quick Reference.

1. Copy the Subscription Link

   Log in to your provider's website, find the subscription page, and click the copy button to put the link on your clipboard. If copying it manually, make sure you select from https:// all the way to the end without leading or trailing spaces or line breaks — a truncated link is the most common cause of import failure.

2. Open the Client's Subscription Page

   Launch the client and find the "Subscription" entry in the side or bottom navigation (some clients label it Profiles or Configs). This page starts out empty, with a URL input field and an "Import" or "Download" button at the top.

3. Paste and Import

   Paste the link into the input field and click Import. The client starts downloading the remote profile, and within a few seconds a new entry appears in the list showing the profile name, last-updated time, and sometimes traffic usage. If the download fails, first check whether your device can reach the provider's website directly, then double-check the link is complete. If it still fails, see the installation and setup category in the Help Center.

4. Activate the Profile

   Click the newly added profile entry to select it. Most clients mark the currently active profile with a highlighted border or a checkmark. Only the active profile gets loaded by the core — a profile that exists in the list but isn't selected has no effect.

Once the profile is active, the subscription stage is complete. The client now holds the node list and rules, but it hasn't taken over any traffic yet — the next step is deciding how traffic gets routed.

The proxy mode determines how the core handles every outbound connection. The switch is on the client's main screen or under "Settings → Outbound Mode," with three options side by side that switch instantly, no restart needed. Here's how the three modes behave:

Rule mode is the right choice for daily use. The rule sets bundled with a subscription profile already cover routing decisions for common sites: local sites go direct, sites that need a proxy go through the node, and the two types of traffic don't interfere with each other. Global mode forces even local traffic through the node, which slows things down and burns through your data allowance — it's only meant as a short-term troubleshooting tool. How rule matching works and how rule sets are organized is advanced material and isn't covered in this guide; check the rules and routing category in the Terminology Quick Reference, and see the Help Center for common mismatch issues.

After the first two steps, the core has loaded the profile in Rule mode, but the operating system hasn't handed its traffic over yet. This step covers picking a node and turning on the takeover switch — both are required: select a node without flipping the switch and no traffic reaches the client; flip the switch without a working node and traffic reaches the client but can't go anywhere.

1. Test Node Latency

   Go to the "Proxies" page (labeled Proxies or "Policy Groups" in some clients) to see the node groups from your subscription. Click the lightning bolt or speed-test icon in the top corner of a group, and the client will run a latency test on every node in it; within a few seconds a number in milliseconds appears next to each one. Lower is better; a node showing "timeout" is currently unavailable.

2. Select a Node

   Click one of the nodes with normal latency — its name gets highlighted once selected. If the group is an auto-select (url-test) type, the client picks the lowest-latency node on its own, so you can just leave it at the default.

3. Enable Traffic Takeover

   Go back to the main screen and turn on the "System Proxy" switch. On Windows and macOS, this points the system's HTTP proxy to the local port the client is listening on (commonly 7890). On macOS, the first time you enable it, a series of network extension and keychain authorization prompts will appear — approve each one; see the macOS Permissions Setup Guide for what each prompt means and how to fix issues. On Android and iOS, the equivalent is a "Start" or connect button — the first tap triggers a system VPN authorization prompt that must be allowed, or the client won't work.

4. Confirm It's Running

   Once the switch is on, watch the client's status indicators: the desktop tray or menu bar icon lights up, a VPN key icon appears in the mobile status bar, and the traffic counter on the main screen starts showing upload/download numbers. Seeing these signs confirms traffic is flowing into the client.

Once a connection is established, it's worth confirming it with an actual test. Two independent verification methods are recommended: start with a browser check for a quick visual confirmation, then a command-line check, which is precise down to the port and can tell apart "the client never got the traffic" from "the node itself isn't working."

1. Browser Verification

   Open the client's "Connections" or log page and keep it visible. Then use a browser to visit a site that was previously unreachable. If the page loads normally and a new record for that domain shows up in the connections list with the outbound marked as the selected node, it's working. If the page doesn't load but a record still appears, traffic is reaching the client but the node's outbound is failing — go back to step 3 and pick a different node with normal latency. If there's no record at all, the system proxy hasn't taken over traffic — check the switch state and the browser's own proxy settings.

2. Command-Line Verification

   Open a terminal and send a request directly through the client's local port, bypassing any uncertainty around the system proxy setting:

   curl -x http://127.0.0.1:7890 -I https://www.google.com/generate_204

   A response of HTTP/2 204 or 200 confirms the entire chain — "device → client → node → destination" — is working. A connection refused error means the port is wrong or the client isn't running; check the mixed port setting in the client's settings. A long timeout with no response means the request reached the client but the node couldn't get outbound — go back to step 3 and address the node.

3. Confirm Direct Traffic Isn't Wrongly Proxied

   While still in Rule mode, visit a frequently used local site and confirm in the connections list that its outbound is marked DIRECT. If a local site is also going through the node, check whether the outbound mode got accidentally set to Global, or refer to the Help Center for rule-matching troubleshooting.