First Clash Connection: Choosing Nodes, Testing Latency, Confirming the Proxy Works

First, understand the three layers of the node list

Once the client is installed and the subscription imported, most people get stuck right at the node list — not because they can't find a node, but because they don't know which one to tap. The Clash core organizes nodes into three layers: the outermost is the "proxy group" — labels like "Auto Select," "Manual Switch," "Hong Kong," or "United States"; in the middle are the actual nodes, and a single subscription can bring in dozens or even hundreds of them; the innermost layer is the "policy," which decides how a proxy group picks a node — url-test (auto speed test, picks the fastest), fallback (primary/backup switching), select (manual choice), or load-balance.

Open the client's "Proxy" or "Nodes" page and every clickable group card you see corresponds to a proxy group. Expand one and you get a row of node entries, each followed by a number plus "ms" — that's the latency. On your first connection you don't need to understand every policy type; just remember two things: which group is the currently active exit, and which node inside that group is selected. Most clients highlight the currently selected entry with a color or a checkmark.

Batch speed testing: where does the latency number come from

The node list page usually has a speed-test button, often a circular arrow or stopwatch icon. Tapping it triggers a test on every node in the current group, and after a few seconds the number next to each node refreshes. This number isn't "download speed" — it's latency. The client uses that node to reach a test endpoint (commonly Google's generate_204 or a built-in test endpoint in the client) and records the time between sending the request and receiving a response, in milliseconds.

Low latency doesn't mean fast downloads, but it does reflect two things: the routing distance between the node's server and your network, and whether the node is currently struggling — if latency shows a timeout or several thousand milliseconds, the node is very likely unavailable right now; don't worry about the exact number, just skip it.

• Under 100ms: very responsive, good for streaming video or real-time voice calls.
• 100–300ms: normal range, no noticeable impact on browsing or downloading.
• Above 300ms or a timeout: the route is likely congested or the node is having issues — switch nodes first.

It's worth re-running the speed test after switching networks (say, from Wi-Fi to mobile data), since latency depends directly on your local exit route, not a fixed value set by the subscription provider.

Manual vs. automatic speed testing

If a proxy group's policy is url-test, the client automatically runs a speed test at a set interval (often configured for every few minutes) and switches traffic to the currently fastest node — you'll see a group like "Auto Select" that you never need to tap manually. If the policy is select, it's entirely manual: the speed-test number is just a reference, and you decide which node to use by tapping it yourself.

Choosing a node by latency: what else matters besides the number

Simply tapping the node with the lowest latency isn't always the best move, for three reasons:

1. Latency measures a short connection, not sustained throughput. Some nodes have very low latency but limited bandwidth, so large downloads or HD video may still stutter. In that case the latency number can't help — you have to judge by actual use.
2. Regional nodes serve different purposes. If your subscription groups nodes by region (Hong Kong, Japan, US, and so on), which region to pick depends on where the service you want to reach is actually hosted — comparing latency only makes sense within the same region, not across regions.
3. Paid subscriptions often mark a traffic multiplier. Node names often include a multiplier like "0.5x" or "2x," which represents the billing rate for data usage. Picking a lower multiplier saves your data allowance but has nothing to do with latency itself.

Unless you have a specific reason not to, the simplest approach is to just use a proxy group labeled "Auto Select" or "Auto" — it has the url-test policy built in and continuously picks the lowest-latency available node within that group, with no manual work needed. Manual mode is for when you know a specific route is more stable and want to stick with it.

Switching proxy modes: Rule, Global, or Direct

Once a node is selected, there's another switch that's easy to overlook — proxy mode. Clash clients typically offer three modes from the main screen or settings:

On your first connection, Rule mode is the recommended starting point — it's also the default in most clients. Rule sets (such as the common GEOIP or GEOSITE lists) automatically decide which domains need the proxy and which stay direct, so you don't have to maintain a list by hand. If you suspect a site isn't going through the proxy, you can temporarily switch to Global mode as a comparison test, then switch back to Rule mode afterward to avoid routing all traffic through the proxy unnecessarily.

Confirming the proxy is actually working: three ways to check

Picking a node and setting the mode doesn't guarantee traffic is actually flowing the way you expect. The three methods below go from easy to more involved — it's worth doing at least two of them before you fully trust the setup.

Method one: check whether the exit address changes on an IP-lookup page

Open any web page that shows your current public IP, note the result while in Direct mode, then switch to Rule or Global mode and reload the same page. If the IP address and location are clearly different the second time, traffic is genuinely being routed through the proxy node. If the result is identical both times, the proxy isn't active — go back and check the node selection, the proxy mode, or whether the client's system proxy toggle is actually on.

Method two: check the client's traffic stats or connection log

Most Clash clients show a live list of active connections on the main screen or a "Log" page, including the domain being accessed, the rule it matched, and which node handled it. Open a web page, then check that list — if you see the domain entry tagged with an actual node name (not DIRECT), that request genuinely went through the proxy. This method is more precise than an IP check, since it can pinpoint exactly which domain went through the proxy and which one went direct.

Method three: verify system-level proxy settings or the VPN icon

When Android's TUN mode takes over all traffic, the status bar usually shows a persistent key or small lock icon, indicating the system-level VPN service is running. If the client instead uses a local HTTP/SOCKS proxy rather than TUN, you'll need to check the system's Wi-Fi details or proxy settings to confirm the proxy address and port have actually been entered and enabled. This step mainly catches the edge case where the client's UI shows "connected" but the system hasn't actually taken over traffic.

Common troubleshooting order:
1. IP-lookup page shows no change → check whether the proxy mode is stuck on "Direct"
2. IP changed but a specific site won't load → check the connection log for which rule that domain matched
3. Log shows the proxy was used but the page still fails to load → try a different node to rule out a single node issue

Each method has a different focus: an IP lookup verifies whether "the exit has changed," the connection log verifies "which traffic specifically went through the proxy," and system settings verify "whether the takeover method is correct." For everyday use, a single IP-lookup check to confirm things are generally working is enough — save the connection log and system settings checks for when you're troubleshooting a specific issue.

Common mistakes to avoid

• Treating the latency number as network speed — low latency only means a fast response, not high bandwidth.
• Leaving Global mode on for convenience — local services end up routed through the proxy too, which can trigger location-based security checks.
• Not re-running the speed test after switching networks — latency is closely tied to your local exit route, and numbers will change after switching from Wi-Fi to mobile data.
• Assuming it works just because the client UI looks connected — "connected" in the UI only means the process is running, not that traffic is actually being routed through it. An IP-lookup check is the real evidence.

Once you've gone through these steps, you can be fairly confident the subscription, node, and mode are all configured correctly. If a connection ever drops out later, the same logic applies — check node latency, then proxy mode, then confirm whether the IP has actually changed — layer by layer, without needing to reinstall the client.