Clash Setup Guide: A Four-Step Walkthrough from Import to Verification

Before diving in, make sure two things are ready. First, the client is installed and opens without issues: Clash Verge Rev is the recommended pick for Linux desktop users, and platform-specific choices and install steps are covered on the Get the Client page — if installation gets stuck, the full manual has a detailed per-platform section we won't repeat here. Second, you'll need a working subscription link — usually provided in your subscription provider's user dashboard, a full URL starting with https://. If terms like "subscription provider" or "subscription" are new to you, spend a minute checking the matching entries in the glossary; the rest of this guide uses these terms without further explanation.

With both in hand, let's start with step one. The whole process usually takes under ten minutes, and each step ends with a clear "what you should see when it's done" checkpoint — confirm it before moving on.

A subscription is essentially a config source hosted remotely: the client fetches the node list and routing rules from this link and generates a complete config.yaml locally. So step one is simply getting the client to recognize this link.

1. Find the "Copy Subscription Link" or "Import to Clash" button in your provider's user dashboard and copy the full URL. It typically looks like this (example uses a fake address):

   https://example.com/api/v1/client/subscribe?token=xxxx

   Note the token= parameter at the end must be complete — even one missing character will cause the server to reject the request.
2. Open the client and go to the subscription management page: it's called "Profiles" in Clash Verge Rev's sidebar, "Configs" in FlClash, and Clash Plus has its subscription management area on the home screen.
3. Paste the link into the input box at the top of the page and click "Import." The client immediately requests the URL and parses the response — on a normal connection, a profile card appears within seconds showing the config name and last-updated time, plus traffic usage info if your provider supplies it.
4. Click this card to set it as the active profile. A selected-state indicator (a highlighted border or checkmark) appearing on the card confirms it worked — that's the completion marker for this step.

If you have a config.yaml file instead of a link, use the same subscription page: choose "Import File," or just drag the file into the client window — the rest of the steps are identical.

Once your profile is active, go to the "Proxy" page. There are three mode toggles at the top — take a minute to understand how each behaves before deciding, since this is where new users most often guess wrong.

Bottom line: keep the default Rule mode. The rule set bundled with your subscription already routes common sites correctly, no manual tweaking needed. For how rule matching works and what rule types like DOMAIN-SUFFIX and GEOIP mean, see the "Rules & Routing" category in the glossary; if you want to write your own routing rules later, the full manual has a dedicated chapter — no need to touch it on your first setup.

The lower half of the Proxy page shows proxy groups and node lists. Expand the group named "Proxy Select" or PROXY, click the latency test button once (usually a lightning bolt or waveform icon), and the client tests latency across all nodes at once, showing a millisecond value next to each. Pick a node with a low, green-colored value and click to select it. For what these latency numbers mean and what counts as normal, see the dedicated entry in the glossary.

Clash doesn't have a big "Connect" button like a traditional VPN. Once the client is running, it opens a mixed proxy endpoint on 127.0.0.1 port 7890 (the default mixed-port) — "connecting" really just means pointing your system's network traffic at this port. There's only one switch involved:

1. Go to the "Settings" page and turn on the "System Proxy" toggle. The client writes HTTP/HTTPS proxy settings into your desktop environment's network settings (the proxy config in GNOME/KDE), and browsers along with most GUI apps will pick it up automatically.
2. Confirm the port shown next to the toggle or in the port settings area is 7890, and check your system tray icon — most clients change the icon's color or add a badge once the system proxy is on, which is a quick visual cue that it's active.
3. The equivalent steps on other platforms: Windows and macOS also use a "System Proxy" toggle; on Android, Clash Meta for Android has a start button on the main screen that triggers a system VPN permission prompt — just allow it; on iOS, Clash Plus asks to add a VPN configuration on first launch, confirm it once in the system dialog, and it's controlled by the in-app toggle from then on.

One type of traffic ignores the system proxy: command-line programs in the terminal. They only respect environment variables, so export them temporarily in your current terminal session when needed:

export https_proxy=http://127.0.0.1:7890
export http_proxy=http://127.0.0.1:7890
export all_proxy=socks5://127.0.0.1:7890

These lines only apply to the current terminal window and stop working once you close it, so they won't affect your system-wide settings. If you want every app — including ones that ignore proxy settings — routed through the proxy automatically, that's what TUN mode handles; it has a higher setup bar and isn't needed for your first run. See the TUN chapter in the full manual when you're ready.

A toggle being on doesn't mean the proxy is working. Check these four items from the outside in — only when all four pass is the setup truly complete:

1. Browser check. Open a site that was previously unreachable — if it loads normally, that's basic confirmation. If nothing changes, force-refresh with Ctrl+Shift+R first to rule out browser cache before concluding anything is wrong.
2. Command-line check.Run a request in your terminal that explicitly specifies the proxy, bypassing system proxy settings entirely, to test the proxy chain directly:

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

   If it returns HTTP/2 200 -style response headers, the chain from client to node to target site is working end to end.
3. Connections page check. Go back to the client's "Connections" page, which lists every connection passing through Clash in real time: domain, matched rule, and exit node. Confirm the domain you just visited shows up in the list, and that its exit is your selected proxy node rather than DIRECT — this instantly tells you whether rule-based routing is working as expected.
4. Exit IP check. Visit any IP lookup site in your browser — the address shown should match your node's region, not your local ISP's address.

If any check fails, the failure point itself is a clue: if the browser fails but curl works, the system proxy likely wasn't written to your desktop environment — go back to step three and toggle it off and on. If curl also fails, it's likely a node issue — go back to step two, retest latency, and switch nodes. If both pass but a specific site still misbehaves, it's usually a rule-matching issue. For a step-by-step approach to tracing logs, see our technical notes, and for deeper troubleshooting strategies, check the full manual.