Clash First Connection Guide: Pick a Node, Test Latency, Verify Proxy

After importing a subscription into Clash, many people pause right at the node list: a long string of names followed by numbers, with no clue which one to click. This article walks through a complete "first connection" flow, starting from opening the node list all the way to confirming traffic is actually going through the proxy — every step includes a concrete action you can follow, with no assumption that you already know the jargon.

Get familiar with the client's layout first

Different Clash clients (Clash Verge, ClashX, Clash for Windows, and others) vary slightly in detail, but the core layout is largely the same, usually split into four areas:

• Proxies: the node list page, organized by the groups defined in your subscription — the main focus of this article.
• Rules: shows the routing rules currently in effect, which decide what traffic goes through the proxy and what connects directly.
• Connections: shows active network connections in real time, and is a key way to check whether the proxy is actually working.
• Settings/General: basic configuration like the system proxy toggle, TUN mode toggle, and mixed port all live here.

For first-time use, confirm that either "system proxy" or "TUN mode" is turned on — picking a node without enabling one of these traffic-takeover methods means your browser still won't go through the proxy. System proxy works by configuring the OS-level HTTP/HTTPS proxy settings; it's simple to set up and is enough for most browsing and apps. TUN mode takes over all traffic at the network layer instead, offering better compatibility — especially useful for apps that don't read system proxy settings — but it usually requires an extra permission prompt.

Understand proxy groups before picking a node

The node list isn't a flat list — it's organized into "proxy groups." Common group types include:

• Proxy / manual selection group: you can manually click any specific node here; once selected, this group sticks to that node and won't auto-switch.
• Auto / auto-select group: the client automatically picks the best-performing node based on latency test results, and re-tests and switches on the interval set by the subscription.
• Fallback group: prioritizes a primary node and automatically switches to a backup when the primary becomes unavailable.
• Select category groups (e.g., "Streaming," "Local Services," depending on how the subscription's rule file is organized): route different types of traffic to different strategies, letting you pick a node separately for each category.

For first-time users, the simplest approach is: find the main proxy group (usually named Proxy, or given a custom name by your subscription provider), open the dropdown, and manually select a node shown in green or with a low latency number — make sure this group connects properly first, then decide whether to switch to auto-select. If the subscription splits traffic into multiple category groups, it's worth checking each group's currently selected node to make sure none of them is stuck pointing at a dead node.

Run a latency test and understand the numbers

A latency value in milliseconds (ms) is usually shown to the right of each node name. Click "Test" on the node list page, or the refresh icon next to an individual node, to manually trigger a latency test. A few things to keep in mind when reading this number:

1. The test target is a latency probe address, not the specific site you actually want to visit. The client sends a request to a preset test address (typically a stable, reliably reachable domain) and measures the round-trip time. This roughly reflects the network condition between the node and the test address, but isn't exactly the same as the real speed you'd get visiting a particular site.
2. Rough reference ranges: under 200ms is usually smooth; 200–500ms is still usable but you may notice slight delay in page loads and video buffering; above 800ms or a timeout means it's worth switching nodes.
3. A "timeout" or red marker doesn't necessarily mean the node is dead — the probe request itself might have been dropped by an intermediate network — but it could also mean the node really has failed. Either way, it's simplest to just switch to a node with normal latency rather than trying to diagnose the cause.
4. Latency fluctuates over time, especially during peak hours. If a node that's normally stable suddenly spikes on one test, wait a few minutes and test again to rule out a one-off fluctuation.

Steps to confirm after switching nodes

After clicking a new node, don't assume it's taken effect right away — confirm it in this order:

1. Check that the node list actually shows the new node as "selected" (usually highlighted or checked).
2. Go back to Settings and confirm the system proxy toggle is on, or that TUN mode is enabled. Either one is enough — there's no need to enable both at once.
3. Open the "Connections" page and watch for new connection entries, checking whether the destination domain and the node name used match what you expect.

If pages load noticeably slower or fail to load after switching nodes, go back and re-check that node's latency first, then consider whether a rule is routing this type of traffic to a different group using a different node.

Verify the proxy in a browser

The most direct method is visiting a page that shows your current outbound IP and location. Steps:

1. Before turning on the proxy, visit an IP lookup page once and note the address and region shown — this is your direct-connection baseline.
2. Confirm a node is selected in Clash and that either system proxy or TUN mode is on.
3. Refresh the same IP lookup page (a hard refresh is best, to avoid browser cache) and compare whether the newly displayed address and region have changed.

If the region now matches the node's location, the proxy is working. If it still shows your local network's address, the system proxy is most likely not turned on, or the browser has its own separate proxy setting overriding the system one (some browsers allow this — worth checking).

You can also open the client's "Connections" page while browsing and watch for a matching connection entry appear in real time for the domain you're visiting, tagged with the node you just selected. This confirms exactly which node handled that request, which is more precise than just checking the IP.

Verify the proxy from the command line

The command-line method suits users comfortable troubleshooting in a terminal, and is more reliable when browser cache or extensions make results ambiguous. Using the common curl command on macOS and Linux as an example:

curl -x http://127.0.0.1:7890 https://ifconfig.me

This sends the request through the local HTTP proxy port, and the response is your outbound IP address. The port number should match the mixed port or HTTP port shown in the client's settings page — defaults vary between clients, so don't just copy the number from this example; use what's actually shown in your interface.

If TUN mode is enabled instead of the system proxy port, you can send the request without the -x flag, since TUN mode already takes over traffic at the network layer:

curl https://ifconfig.me

Compare the IP returned before and after enabling the proxy — if the address changes and matches the selected node's region, the proxy path is working. If the command times out or the connection is refused, first check whether the port number is correct, then check whether the client's proxy listener is actually running.

Troubleshooting order when verification fails

If the proxy still doesn't appear to be working after following the steps above, work through the following checks one at a time rather than changing multiple settings at once:

• Check the node first: is the latency normal, or did you happen to select a dead node? Switch to a node with normal latency and re-test.
• Then check the takeover method: confirm the system proxy toggle or TUN mode status — at least one should be on, and make sure the domain you're testing isn't listed in your OS's proxy exception/bypass list.
• Then check rule matching: open the Rules page and confirm the domain you're testing is routed to a proxy group rather than matched to DIRECT. Some subscriptions set local-network or region-specific domains to direct connection by default, in which case you won't see an IP change even if the proxy is working fine.
• Finally check the client process: confirm the Clash core process is actually running and hasn't exited or crashed — some clients keep the old "selected" state visible in the UI even after the core process dies, creating the illusion that everything "looks like it's on."

Once you've gone through each check, repeat the earlier browser or command-line verification step to confirm the issue is actually resolved, rather than assuming it's "probably fine now."

Build a quick everyday verification habit

Once the initial setup works, it's worth keeping a short confirmation step for every time you switch nodes or restart the client, rather than running through the full process each time: open the "Connections" page to check for new connections, or run the same command-line command from earlier — it takes only a few seconds to confirm the path is working. This habit is especially useful when troubleshooting "why did this suddenly stop connecting" — since you already know what a normal state looks like, spotting an abnormal one becomes obvious at a glance.