First Connection to Clash: Picking a Node, Testing Latency, and Verifying the Proxy Works

After importing a subscription, understand what the proxy page is showing you

Successfully importing a subscription link is only step one — what actually decides "how to connect" in the config file is the proxy-groups section. Open the proxy page in your client and you'll usually see several group names, such as "Auto," "Manual," "Streaming," or "Fallback." Each group holds a set of specific nodes. These groups aren't just arbitrary display labels — they're functional units whose behavior is defined by the type field in the config file:

• select: A manual switch group — you click whichever node you want to use. Good for when you already know exactly which line you want.
• url-test: An auto-testing group — the client periodically probes the latency of every node in the group according to the configured test-url and interval, then switches to the fastest one automatically. Ideal for everyday use if you don't want to fiddle with it manually.
• fallback: A failover group — nodes are probed in order, and the client only switches to the next one if the primary node becomes unreachable. This prioritizes stability over absolute lowest latency.
• load-balance: A load-balancing group — connections are distributed across multiple nodes according to a policy, commonly used when running several lines in parallel.

On your first connection, it's worth checking which type of group you're using. If it's a url-test auto-select group, you don't need to pick a node manually — the client will test speeds and switch on its own. If it's a select manual group, you'll need to run the latency test yourself and pick a node with a low number and a stable line.

Batch latency testing: how it works and what the numbers actually mean

Each node on the proxy page usually shows a latency number or a "test" button, and clicking the batch-test icon next to a group's title triggers a latency check for every node in that group at once. This latency isn't the full round-trip time to whatever site you're eventually visiting — it's the time it takes for your local client to reach that node's proxy server, and for the node to then reach the test address (the test-url in the config, typically a well-connected address outside mainland China), measured in milliseconds.

Here's a rough reference range for reading the numbers (actual results vary by network environment, so treat this only as a baseline):

• Under 200ms: Fast response — good for video streaming, voice calls, and other latency-sensitive uses.
• 200–500ms: Usable range — browsing and file downloads should feel mostly smooth.
• Over 500ms or timing out: Likely congestion or a broken node — try switching to a lower-latency node in the same group.

Keep in mind that a latency test reflects "connection quality," not download speed. Some nodes look great on latency but have limited bandwidth, so large file transfers still feel sluggish; other nodes have slightly higher latency but plenty of bandwidth, making them more consistent for big downloads. For everyday browsing, prioritize latency; for large downloads, also check the node's labeled bandwidth tier or line type (dedicated transit lines are usually more stable than regular nodes).

Batch testing does consume some response resources on the node servers, so avoid clicking it repeatedly in quick succession. Generally, running it once after a connection feels off or after switching networks (say, from home Wi-Fi to a mobile hotspot) is enough — most clients also let you set an automatic testing interval so you don't have to trigger it manually every time.

Turn on the system proxy and pick the right mode

Once you've picked a node, the next step is making sure applications on your system actually hand their traffic off to Clash. Most clients have a "System Proxy" toggle on the home screen or in settings — turning it on points your machine's HTTP/HTTPS proxy settings at the local port the client is listening on (commonly port 7890), and most browsers and system-proxy-aware software will automatically route through it.

Beyond the system proxy, clients also offer two lower-level operating modes — understanding the difference helps when troubleshooting later:

1. Rule mode: Traffic is matched line by line against the rules section of the config. Matched traffic goes to its corresponding group; anything unmatched falls back to a default policy. This is the most commonly used, low-maintenance mode for daily use.
2. Global mode: Rules are ignored entirely, and all traffic is routed through whichever single node is currently selected. Useful when you temporarily want everything to go through one specific line, and also handy for testing whether "a rule is misconfigured" by comparing behavior against this mode.
3. Direct mode: All traffic bypasses the proxy and uses your machine's raw network connection — typically used to temporarily disable the proxy's effect and check whether an issue is actually caused by the proxy itself.

If configuring proxy settings app-by-app isn't convenient on your device or OS, consider TUN mode instead: the client sets up a virtual network adapter and takes over the entire network layer on the device, so it no longer depends on whether an individual program recognizes the system proxy settings. This is especially useful for command-line tools and non-browser clients. Enabling TUN mode for the first time usually requires elevated system permissions (such as admin rights or a network extension authorization on certain platforms) — follow the client's prompts to grant them. Authorization failures are almost always due to incomplete permission grants, and running through the process again usually fixes it.

Verifying the proxy is actually working, in a browser

Once the system proxy or TUN mode is on, don't just assume "toggled on means it's working" — make it a habit to verify before relying on it. The most straightforward way is to open a browser and visit a page that shows your current outbound network info, then compare the results before and after enabling the proxy. If your reported location or line info changes when you toggle the proxy, that confirms traffic really is being routed through the node Clash selected, rather than going out through your machine's original network connection.

For a closer look, open the client's built-in log page or connections page:

• The connections page lists every network connection currently passing through Clash in real time, including the domain being accessed, the node in use, and the rule that matched. If you see a matching entry after loading a page, that confirms traffic is genuinely being handled by Clash.
• The log page can be filtered by level (Info, Warning, Error). If rule-match entries show up frequently while you browse, that's another indirect confirmation the proxy chain is working correctly.

If the connections page stays empty and no new log entries appear after loading a page, the system proxy most likely isn't actually active. Common causes include the browser using its own separate proxy settings (not following the system proxy) or the system proxy toggle not actually switching on — check your system's network settings to confirm the proxy address and port match what the client is listening on.

A more rigorous check using the command line

The graphical checks above are enough for everyday use, but if you want harder proof the proxy chain is working, command-line tools give you more definitive evidence. In a terminal, you can send a request through the proxy explicitly and inspect the response:

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

This command forces the request through the local proxy on port 7890. If it returns a normal response header instead of a timeout or connection refused, that confirms the local proxy port is open and forwarding external requests correctly. To further confirm you're going through the expected line, compare the response time and result of the same command without specifying a proxy — a clear difference between the two is solid confirmation the proxy chain is actually doing work, not just sitting there switched on.

Additionally, most clients built on the Clash Meta (mihomo) core expose a local API and control panel, typically listening on a separate port (commonly 9090). You can also query which node a group currently has selected directly from the command line:

curl http://127.0.0.1:9090/proxies/Auto

The returned JSON includes a now field indicating which node is actually active in that group right now — a more reliable source of truth than what's shown on screen, since it reflects the config layer directly. This is especially useful when an auto-testing group is switching nodes frequently, where checking the API is more reliable than staring at the UI.

The connection looks fine but browsing is still slow — what now

You've gone through the verification steps and confirmed the proxy is active, but some pages still load slowly. In that case, work through the following checklist instead of jumping straight to "the node must be bad":

1. Check whether the current group is an auto-testing group. If your network environment recently changed (say, a different Wi-Fi network), the group may not have re-tested for the optimal node yet — trigger a batch test manually.
2. Switch to global mode and test a single node's performance without rule matching in play, to rule out whether a specific rule is routing traffic into a poorly performing group.
3. Check the log page for a large number of unmatched-rule or parse-failure entries. Reversed rule order or a broken regex in the config can both cause traffic to route differently than expected.
4. If you're accessing resources outside mainland China, also consider whether the target site itself is under load — not every case of slowness is a proxy chain problem.

Working through these steps will usually pinpoint whether the issue lies with the node, the rules, or the destination site itself, without needing to re-import the subscription or swap nodes every time something feels slow.