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

1. Confirm the configuration is loaded—not just subscribed

Seeing a subscription in the list does not mean it is running. For your first connection, check three things: the configuration is selected, the proxy core has started successfully, and the configuration's proxy groups have loaded. Clash is an umbrella term for a configuration and proxy-core ecosystem. Clients such as Clash Verge Rev provide a graphical interface, while mihomo parses the configuration, establishes proxy connections, and applies rules. The buttons vary by client, but these three checks remain the same.

1. Open the client's Subscription or Profiles page, select the configuration you just imported, and make sure it is marked as active.
2. Open the Proxies page and check that it shows proxy groups and their available nodes—not just a subscription name.
3. Open the Logs page and make sure there are no recurring errors for configuration parsing, unsupported proxy types, or ports already in use.

If the subscription update succeeds but the Proxies page shows no nodes, first check whether the response is a configuration format supported by the client. A complete Clash YAML configuration is not the same as a list of Base64-encoded node links. A URL may also return a login page or an error instead of a configuration. Don't keep toggling the system proxy before the configuration has loaded.

2. Select the node that will actually handle the connection

On the Proxies page, first find the main proxy group used by your rules. It might be called Proxy, PROXY, or something else; group names are set by the configuration author, not standardized by the app. Selecting a node in a nested group does not guarantee that all traffic will use it: a parent group may point to another group, and a particular website may match a dedicated proxy group.

Use manual selection to simplify your first test

• In a group that allows manual selection, choose a specific node. If the option is another group, follow it to see which node it ultimately selects.
• Avoid DIRECT and REJECT for now. The former means a direct connection; the latter blocks the connection. Neither is a remote proxy node.
• Choose a route that your provider lists as available and whose location suits your needs. A region in the node name is only a label; verify the actual exit location later.
• For the initial test, run only one proxy client. Quit other VPN or proxy apps temporarily to prevent them from overriding the system proxy settings.

With a url-test group, clicking a node may only override the selection temporarily, depending on the client and configuration. To see which node is actually in use, check the proxy chain in the connections panel rather than relying on the selected icon beside a node.

3. What latency numbers tell you

Latency shown in a node list usually measures the time taken to reach a test URL through that node. It should not be read as an ICMP ping to the server. Results vary with your local network, proxy handshake, test URL, server load, and cache state. Numbers from different clients or test URLs may not be directly comparable.

The numbers in the table are examples, not measured rankings of real routes. Run three tests about five seconds apart and favor nodes that consistently complete the test with little variation. A node that returns 45 ms once and then times out twice may be less suitable for everyday use than one that returns around 100 ms all three times.

A successful latency test doesn't guarantee a website will work

A test URL may return only a tiny response, such as HTTP 204. This can verify a basic request path, but it does not measure video throughput, determine your account region, or confirm access to a particular website. Conversely, restrictions on the test URL can make the latency test fail even when some websites still load. In that case, check the destination and error type in the logs instead of relying on the color alone.

4. Enable the system proxy for a simple test

For your first test, enable the system proxy so a browser that follows the system settings sends requests through Clash. Don't enable TUN at the same time. TUN routes traffic through a virtual network interface and involves routing, DNS, and permissions; configure it later if needed, once the basic connection is confirmed. Mobile clients typically route traffic through the system VPN interface, so their setup differs from the desktop system proxy steps.

1. Find and enable the System Proxy toggle in your desktop client's main window, and make sure the proxy core is still running.
2. Open the client's port settings and note the HTTP or mixed port. This guide uses 7890 as an example; use the port shown in your client.
3. On macOS, check System Settings → Network → your current network service → Details → Proxies. On Windows 11, check Settings → Network & internet → Proxy.
4. If a browser extension has its own proxy settings, disable it or set it to follow the system settings, then open a new tab to test.

Rule mode is suited to everyday use: only requests matching proxy rules go through the proxy. To isolate the effect of rules, you can briefly switch to Global mode and explicitly select the test node in the global proxy group. Switch back to Rule mode after testing. Global mode only changes routing for traffic that has already reached the core; it does not automatically capture every app or route connections that bypass Clash into the core.

5. Cross-check your exit IP against the connections panel

An exit IP check needs a point of comparison. Seeing an unfamiliar address alone does not prove the request went through the selected node. Seeing your usual address does not necessarily mean the proxy failed—the check site's domain may be set to bypass the proxy by a rule. For a reliable check, record the mode, destination domain, matched rule, and proxy chain.

Run a comparison in this order

1. On a network where direct testing is allowed, turn off the system proxy and make sure TUN and other VPNs are not routing traffic. Use the same IP lookup service to record your baseline address. Skip this step if you already have a baseline.
2. Enable the system proxy, briefly switch to Global mode, select a node, and run the lookup again. In your browser, visit https://api.ipify.org to see your public IPv4 address.
3. Immediately open the client's Connections page and search for api.ipify.org. Check the destination, rule, proxy chain, and traffic counters. Short requests can finish quickly, so open the panel beforehand and check its closed-connection history.
4. Switch back to Rule mode and run the lookup again. If the result changes, check whether the domain matched DIRECT or was routed to a different proxy group.

The strongest evidence that the proxy is working is that the lookup request appears in the connections panel, its proxy chain includes the expected node, and the service returns the public IP for that route. A different address from your baseline is a useful signal, but not the only one; multiple nodes may share an exit IP. IP databases can have outdated country, city, and provider data, so don't judge a route by the city label alone.

Keep IPv4 and IPv6 separate. An IPv4 lookup says nothing about how IPv6 traffic is routed. Different lookup sites may use different address families and show different addresses. To verify IPv6, test a target that supports it, then compare the connection logs with the client's traffic-capture scope and DNS settings.

6. Use the command line to diagnose local port issues

If the browser result is unclear, use curl to connect explicitly to the local HTTP or mixed proxy port. This bypasses browser extensions and system proxy settings. 127.0.0.1:7890 below is only an example; if the client shows 7897 as the mixed port, replace the port in the command with 7897. Don't use a SOCKS-only port as an HTTP proxy.

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

In Windows PowerShell, use curl.exe with the same arguments to avoid command alias differences in some older environments. This command explicitly targets the local proxy, but requests are still subject to the current rule mode after entering the core. To rule out a direct connection caused by the rules, combine this with the temporary Global mode test above and check the connections panel.

• Failed to connect: First check that the core is running and that the local listening address and port are correct. Focus on whether the request is reaching the local proxy.
• Times out after about 20 seconds: The request did not complete within this time limit. Check the core logs for remote connection, DNS, or TLS errors.
• Returns an IP, but the browser still fails: Check browser-specific proxy settings, extensions, and existing connections first. At least the local proxy port can handle this command-line request.

Don't disable certificate verification as a routine fix. If you see a certificate time error, check the operating system's date, time zone, and automatic time sync first. If only one website fails, investigate that site's certificate and the route rather than lowering security settings for the entire browser.

7. Troubleshoot common results

Change one variable at a time. For example, keep the node fixed and switch between Rule and Global modes. Then keep the mode fixed and try another node. If you change DNS, TUN, the port, and the node all at once, even a successful connection won't tell you which change fixed the problem.

8. What to record after your first connection

After the test succeeds, switch back to the Rule mode you plan to use, then visit one website that should connect directly and one that should use the proxy. Check the connection logs for both. A direct request should show DIRECT, while the proxied request should show the expected proxy chain. This confirms that routing matches your configuration; being able to open both websites is not enough to prove the rules are correct.

• Record the client name, core name, active configuration name, and local listening port.
• Note the test domain, mode, final node, exit IP, and test time for future comparison.
• If you need TUN, enable it separately, repeat the website and exit IP checks, and look for conflicts with existing VPNs or virtual network adapters.
• If something goes wrong later, reproduce this simple test path first, then troubleshoot app-specific settings.

The goal of a first-connection check isn't to find the lowest latency; it's to establish a repeatable chain of evidence: the configuration is loaded, the node connects, the request reaches the core, the rules route it correctly, and the destination responds. Check each step separately and you can use the same approach when changing subscriptions or clients.