Clash First Connection: Choose a Node, Test Latency, and Verify Your Proxy

1. Verify Your First Connection

Choose a node in a proxy group first, test that it can connect, then check where your application’s traffic actually exits. A client showing “Connected” usually means only that the core or VPN interface has started. A latency value next to a node only means the test request received a response. Neither status alone proves your browser is using the proxy.

This guide covers graphical clients that use the Clash or mihomo core. Menu names vary between clients, so look for pages such as Configuration, Proxies, Connections, and Logs. For your first test, use one browser, one destination website, and one manually selected node. Avoid changing several settings at once.

1. On the Configuration page, make sure the subscription is enabled—not merely downloaded to the list.
2. On the Proxies page, use Rule mode and find the proxy group that handles your destination website.
3. Test the nodes, then manually select one that responds.
4. Enable the system proxy, or turn on TUN if your apps require it.
5. Make a new web request, then check the exit IP, matched rule, and proxy chain.

2. Select the Active Node in a Proxy Group

After importing a subscription, the list may contain both nodes and proxy groups. A node contains server and protocol settings; a proxy group selects a node or points to another group. Selecting the top-level group may not complete the choice—you may need to follow the group references to identify the actual exit.

Manual Selection vs. Automatic Selection

For example, the top-level “Proxy” group may point to “Auto,” which then points to a node. The actual route is two proxy groups followed by one node. For initial troubleshooting, choose a node directly if the configuration offers manual selection; this reduces variables introduced by automatic switching. Group names are set by the subscription author, so a group called “Proxy” does not guarantee that a proxy node is selected.

Rule Mode or Global Mode?

• Use Rule mode for everyday traffic: The core evaluates rules in order, so requests may go through a proxy, connect directly, or be rejected.
• Use Global mode only for comparison: After switching temporarily, check which member GLOBAL actually selects. Global mode does not replace the system proxy or TUN as a way to route traffic into the core.
• Switch back to Rule mode after testing: Don’t route all local and mainland China services through the same exit just to make an IP lookup show a different address.

If a website connects directly in Rule mode but uses the proxy in Global mode, check the matched rule and proxy group selection first. Don’t reinstall the client right away.

3. Test Node Latency in Batches

On the Proxies page, look for a latency test or refresh button. Test the current group first, then choose a node that responds. Tests usually send a request through the node to a specified URL. Results depend on the test endpoint, DNS, connection setup, TLS, and the test implementation; they are not the same as an ICMP ping to the node’s server.

1. Make sure your local network is working and wait for the subscription’s nodes to finish loading.
2. Run a batch test for the current group and wait for it to finish. Avoid repeated clicks, which can create extra concurrent tests.
3. Choose a responsive node, wait about 10 seconds, and test it twice more. Check whether it repeatedly times out.
4. Test with the same destination webpage, then compare alternative nodes in nearby regions.

Here’s how to evaluate a set of illustrative results: Node A returns 82, 89, and 86 ms across three tests. Node B returns 45 ms, times out, then returns 310 ms. For a first connection, Node A is the better choice. Node B’s best result is lower, but its variation and timeout suggest it was less reliable in these tests. These are not live rankings of any service by this site.

Latency is not a measure of download speed. A low-latency node can still be affected by bandwidth, congestion, destination-site limits, or a shared exit. To verify your first connection, start by checking that a small HTTPS page loads reliably. There’s no need to run a high-volume speed test right away.

4. Route Traffic into the Core: System Proxy or TUN

Once a node is available, your apps still need to send their requests to the core. The system proxy works for browsers and apps that honor the system proxy settings. TUN routes traffic through a virtual network interface and supports more apps that don’t use the system proxy, but it still depends on routes, exclusions, and client settings.

Start by Testing Your Browser with the System Proxy

Enable “System Proxy” in the client. On Windows, check the settings under “Settings” → “Network & internet” → “Proxy.” On macOS, go to “System Settings” → “Network” → your current network service → “Details” → “Proxies.” Menu names vary by OS version; use the listening address and port shown in the client.

This YAML snippet is only to illustrate the fields; it is not a complete subscription. 7890 is an example port. If the client shows 7897, use 7897 in subsequent commands too. Client overrides may replace subscription values, so rely on the core’s running configuration and the actual listening port.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

• mixed-port: Accepts both HTTP and SOCKS proxy requests on the same port.
• allow-lan: false: Does not expose the proxy to your local network; you usually don’t need to enable this for testing on your own device.
• mode: rule: Rules determine the exit; this does not mean every request will use a node.
• log-level: info: Helps show routine connection details. The information displayed depends on the client and core.

Enable TUN Only If You Need It

If your browser works but a game or another app still connects directly, check whether the app supports proxies before trying TUN. Desktop clients often need service mode or administrator privileges; mobile clients generally need permission to use the system VPN. Avoid running multiple VPN clients that route traffic at the same time, as their default routes and DNS settings may conflict.

After enabling TUN, start a new test connection. Existing TCP connections may continue using the old route, so simply refreshing a page that reuses a connection may not reflect the new settings.

5. Verify with Your Exit IP and Connection Logs

A reliable check needs two kinds of evidence: the source address seen by an IP lookup service and the actual proxy chain recorded by the core. The lookup shows where that request exited; the connection record explains why the core chose that route.

Record a Direct-Connection Baseline, Then Compare

1. Temporarily turn off the system proxy and TUN, look up your public IP over your regular network, and note the time, address, and ISP.
2. Restore your proxy settings and select the node that passed the test.
3. Run the lookup again while opening the client’s Connections page and searching for the lookup service’s domain.
4. Check the matched rule, destination address, and proxy chain. Make sure the final member is not DIRECT.

The IP lookup site itself may be routed directly by your rules. If the address doesn’t change, check the logs first. If it changes but there’s no matching request in the logs, check whether a browser extension or another VPN is handling the traffic. IP geolocation databases can be out of date, so the displayed country or city is only a supporting clue.

Use curl to Rule Out Browser Settings

The commands below use 7890 as the local HTTP mixed port and query the exit IPv4 address with api.ipify.org. On Windows, use curl.exe in PowerShell; on macOS and Linux, run the same options with curl.

# Windows: bypass the application-level proxy
curl.exe -4 --noproxy "*" --max-time 15 https://api.ipify.org

# Windows: explicitly use the local HTTP proxy
curl.exe -4 --proxy http://127.0.0.1:7890 --noproxy "" --max-time 15 https://api.ipify.org

--noproxy "*" only bypasses curl’s application-level proxy; it does not bypass TUN or an upstream VPN. Turn off those traffic-routing interfaces before checking your direct-connection baseline. The second command explicitly uses the local port, but the core still applies its rules, so it does not “force traffic through a remote node.” Check the matched rule and final exit for this request too.

How to Read a Successful Connection

Start filtering on the Connections page, then run the command again. A short request may finish quickly; if the connection list only shows active connections, check the Logs page instead. Look for these fields rather than expecting a particular log format:

• Destination: The domain should match the service you just accessed; the port is usually 443.
• Rule: This may be a domain rule, a rule set, or the final MATCH rule. Note which one actually matched.
• Proxy chain: Confirm the request went through the expected proxy group and ended at the selected node.
• Result: The request returned an address without repeated authentication, handshake, or connection timeout errors.

6. Troubleshoot First-Connection Problems

The Node Shows Latency, but the Browser Can’t Open Websites

First, test with curl using an explicit proxy. If the command works but the browser doesn’t, check whether the browser uses its own proxy extension, ignores system proxy settings, or needs existing connections to be restarted. If the command can’t connect to 127.0.0.1:7890, check the listening port and core status first—the request hasn’t reached the remote node yet.

The Exit IP Hasn’t Changed, but Websites Load

Check whether the lookup domain matched DIRECT, then confirm the proxy group’s final selection. If needed, temporarily switch to Global mode for comparison and check the member selected by GLOBAL. Restore the original mode after testing. A corporate network, upstream VPN, or shared exit service can also make IP comparisons less obvious; the proxy chain is more useful than geolocation alone.

All Nodes Time Out

• Check the subscription’s expiration date, account traffic allowance, and whether the node list has been updated.
• Check your device’s clock. A significant time error can cause TLS certificate validation to fail.
• Compare with another network, such as switching from home Wi-Fi to a mobile hotspot.
• Check the logs for DNS resolution, authentication, or handshake errors before changing DNS settings.

Only Some Apps Use the Proxy

This usually points to the traffic entry method, not a need to retest every node. Check whether the app uses the system proxy, whether it uses UDP or QUIC, and whether its traffic is included in the TUN routes. A successful HTTP proxy command proves only that this HTTP proxy route works; it does not prove that all UDP traffic is being routed too.

When reporting an issue, include the client name, core version, OS version, listening port, time of the test, and error type. Before sharing screenshots, hide subscription URLs, authentication details, and personal network addresses. Don’t post your full configuration in a public discussion.

7. First-Connection Checklist

Once these checks are complete, you can return to everyday use. If you only change nodes later, you generally won’t need to change the system proxy, DNS, or TUN settings again.

• The current configuration is enabled, the core is running, and the listening port matches the one shown in the client.
• The target proxy group points to an available node, and repeated tests don’t keep timing out.
• Traffic from your browser or target app is reaching the core.
• The exit IP lookup and connection logs corroborate each other, confirming that the target request used the expected node.
• If you temporarily used Global mode for testing, you’ve switched back. No other VPN or proxy is interfering.

Verify proxy behavior for a specific app, destination, and request. Keeping the scope that precise helps distinguish three separate issues: node reachability, rule selection, and traffic routing.