How to Test Your First Clash Connection: Choose a Node, Check Latency, and Verify Proxy Traffic

What to verify on your first connection: traffic capture, rule matching, and exit IP

A successful subscription import only confirms that the client received the configuration. It doesn't prove that your browser, terminal, or games are using the proxy. A latency value beside a node only shows that one specific test request returned a result. To verify the full path, check the application entry point, rule decision, node connection, and destination response.

The client handles subscriptions, toggles, and the interface; cores such as Clash or Clash Meta (mihomo) listen on ports, match rules, and establish connections. Menu names and default ports vary by client. The steps below refer to common interface sections such as Configuration, Proxies, Connections, and Logs rather than assuming every client has the same layout.

1. Configuration loaded: The active configuration is enabled, and the core reports no parsing errors.
2. Traffic received: A new test request appears in the client's connection list or the core's logs.
3. Policy matches expectations: The matched rule points to a proxy group, and the final route includes the selected node.
4. Response can be checked: The destination responds, and you can compare the proxy exit IP with a direct-connection baseline.

After importing a subscription, check the active configuration and proxy group

Make sure the configuration is actually enabled

In the Configuration page, find the configuration you just imported and confirm it's selected, not merely listed. Then check the Logs page for YAML parsing errors, missing policy names, or port binding failures. Some clients keep using the last successfully loaded configuration when a subscription update fails, so check the update time and node list as well.

• No nodes listed: Check whether the subscription was fetched successfully before troubleshooting the system proxy.
• Policy name not found: Check that rule references, proxy groups, and node providers use matching names.
• Address already in use: Check whether another client is using the local proxy port.
• Nodes are listed but all fail: Check the subscription's validity, network reachability, and core protocol support.

Expand the proxy group until you reach a specific node

Open the Proxies page, select Rule mode, then find the group referenced by the relevant rule. For example, if a rule points to Web Proxy and that group uses Manual Select, expand Manual Select and choose a specific node. Selecting a node in an unrelated group won't change the route used by that rule.

The select type lets you choose manually; url-test usually selects automatically based on health checks; fallback chooses the first available option in order; and load-balance may assign different connections to different exits. For initial troubleshooting, use an existing manual selection group and pin one node to minimize interference from automatic switching.

If the group currently selects DIRECT, the corresponding connections go directly to their destinations. If it selects REJECT, those connections are blocked. A group named “Proxy” doesn't guarantee that a proxy node is selected; check the current selection.

Node latency tests: what the numbers mean

A node latency test on the Proxies page typically asks the core to request a specific URL through the node, then records how long the request takes. It's not an operating system ICMP ping or a download speed test. The test URL, timeout threshold, DNS status, TLS handshake, and connection reuse can all affect the result.

Retest under consistent conditions instead of relying on a single ranking

1. Use the same test URL and test 2–3 candidate nodes one at a time to avoid interference from running all tests concurrently.
2. Test each candidate node 3 times, about 5 seconds apart, and note the success rate and variation.
3. Keep the network environment the same. Don't switch between Wi-Fi, cellular, and wired connections during testing.
4. After choosing a node, visit the site or service you actually need and check the new connection and its response.

For example, one sample set might be 85 / 92 / 88 ms, while another is 48 ms / Timeout / 410 ms. The first is a better candidate for further stability testing. These figures are illustrative, not measurements from this site. Even a low-latency node can be affected by congestion at the exit, destination restrictions, or bandwidth limits, so latency alone doesn't guarantee download speeds.

Check where traffic enters: system proxy and explicit proxy tests

Start browser testing with the system proxy

Enable System Proxy in the client, then open a new page in a browser that follows the system proxy settings. Temporarily disable any separate browser proxy extension so it doesn't override the system settings. Open the client's Connections page, send a new request, and check for the expected domain, destination port, and policy chain.

The system proxy doesn't capture all system traffic. Some command-line tools, games, and apps ignore it. If the browser works but the terminal doesn't, that doesn't mean the node has failed; use the tool's own proxy options, or configure TUN if you need system-wide traffic capture.

Use curl with an explicit local port

The example below assumes the active configuration uses 7890 as its HTTP or mixed proxy port. Check the actual value in the client's port settings before running the command; don't replace your entire subscription just to match the example. A mixed port accepts HTTP and SOCKS proxy connections, while a dedicated SOCKS port can't be used directly with the HTTP proxy syntax below.

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com/

In Windows PowerShell, use curl.exe to avoid an old alias changing how the arguments are interpreted. A 200 Connection established response only means the local proxy accepted the HTTPS tunnel request; check the destination's response or final error too. A destination response such as 301 or 403 doesn't mean the proxy connection failed.

If the local port supports SOCKS5, use the following command to send the destination hostname through the proxy for resolution, instead of having curl resolve it locally first:

curl --proxy socks5h://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com/

Verify the proxy using matched rules and the exit IP

Connection details are more reliable than a mode toggle

In the Connections page, filter by the test domain and check the destination, matched rule, and route. Fields vary between clients, but the key questions are the same: Did the request reach the core? Which rule determined the policy? Which outbound did the group ultimately use? A rising traffic counter alone may reflect background updates or another app's connections; it doesn't verify the request you tested.

• Domain rule matched: Confirm that the rule points to the expected proxy group.
• Fallback rule used: Check whether the final MATCH rule points to a proxy or a direct connection.
• Policy chain includes DIRECT: The request went directly to its destination, regardless of whether the system proxy is enabled.
• Old node still appears after switching: Existing connections may keep using their original route. Reconnect before checking again.

Rules are usually evaluated in order, and the first match determines how a request is handled. Don't check only the final fallback rule; an earlier domain rule, IP rule, or rule set may already match the request. For guidance on custom rules and keeping them after subscription updates, see the custom rules section in the user guide.

Establish a direct-connection baseline, then check the proxy exit IP

You can start by turning off TUN and the system proxy, and pausing other VPN or proxy tools. Then use the command below to look up your current public IPv4 address. This sends a request to a third-party IP lookup service, which can see the request's source. Use it only if you're comfortable with that.

curl -4 --noproxy "*" --connect-timeout 10 --max-time 20 https://api.ipify.org

Next, keep TUN off, start the local proxy, and run the lookup again with explicit proxy settings. Confirm that the lookup domain follows the rule for the selected node:

curl -4 --proxy http://127.0.0.1:7890 --noproxy "" --connect-timeout 10 --max-time 20 https://api.ipify.org

--noproxy "*" only tells curl to bypass application-level proxy settings; it can't bypass an active TUN or other transparent traffic interception. That's why it's important to disable those before establishing a baseline. If the two addresses differ and the second connection's route includes the selected node, that's strong evidence the proxy exit is working. If they match, check for a direct route under your rules, cached lookup results, or a shared exit between the proxy and your local network.

An IP geolocation database provides only an estimate, and it may be outdated. An IPv4 lookup doesn't show the route for IPv6 or all UDP traffic, and it can't prove on its own that DNS isn't leaking. Verify a specific app, address family, and protocol; don't generalize from one successful test to “all network traffic is proxied.”

TUN and common failures: troubleshoot by layer

Consider TUN when you need to capture traffic from apps that don't follow the system proxy. It routes traffic through a virtual network interface and typically involves service permissions, routing, and DNS handling. Turning on the switch only starts the enable process; also check that the virtual interface and routes are in place and that the target app creates a new connection. Clients based on mihomo can use different defaults, so don't assume they behave alike just because their interfaces look similar.

Increase log detail only temporarily

First reproduce the problem with the usual log level. If there's not enough information, temporarily switch to debug, note the failure time and destination domain, then restore the original level. Different errors point to different stages: connection refused usually indicates a local listener issue; DNS resolution failure points to DNS; handshake failure may involve node settings, certificates, or the server; investigate a timeout based on where it occurs.

Before sharing screenshots or logs, redact subscription links, credentials, control interface keys, and personal browsing records. Subscription URLs often contain access credentials, so don't post them in public comments for troubleshooting. For other common system issues, see Clash FAQs.

First-connection verification checklist

Once you've completed these steps, keep a repeatable test method instead of relying on a one-time latency ranking. After network, node, or rule updates, you can retest the same destination without reinstalling the client from scratch.

1. Record the active configuration, core name, and actual local proxy port.
2. Pin one working node and run at least 3 latency tests under the same conditions.
3. Send a request through the explicit proxy to confirm the local entry point works and the destination responds.
4. Check the rule, proxy group, and final node in connection details instead of relying on total traffic.
5. Compare the direct baseline with the proxy exit, and note whether the test used IPv4 or IPv6.
6. Restore automatic selection or enable TUN if needed, then retest the apps you actually use.

To verify that a proxy is working, follow the request: it must reach the core, match the right policy, and use the expected outbound. Latency helps compare candidate nodes, an exit lookup helps check the route, and connection logs tie the two together. None of these evidence types can replace the others.