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

1. Before You Connect: Check Your Configuration, Core, and Listening Port

For your first connection, follow this sequence: load a configuration → choose an outbound route → test a node → connect your browser → check the connection log. Successfully importing a subscription only confirms that the client has received a configuration. You still need to verify that a node works, the right rules match, and your application is using the proxy. Don’t enable the system proxy, TUN mode, and a browser proxy extension all at once; if something fails, it will be harder to identify the cause.

1. Check the active configuration. Open the client’s “Subscriptions” or “Profiles” page, select the configuration you just imported, and make sure it’s active—not merely listed. Page names vary between client versions.
2. Make sure the core is running. Open the “Logs” page and look for configuration parsing errors, port conflicts, or messages that the core has exited. An open client window doesn’t mean the core started successfully.
3. Note the local port. In Settings, look for “Port,” “Mixed Port,” or mixed-port. This guide uses 127.0.0.1:7890 as an example. If your client shows a different port, use it in the commands below.
4. Temporarily disable other proxy routes. Close other proxy clients and turn off browser proxy extensions so there’s just one clear connection path. Don’t disable your firewall or certificate checks to test the connection.

If you don’t see any nodes on the configuration page, go back to the import steps. Check that your subscription is valid, your plan hasn’t expired, and you imported a Clash YAML configuration rather than a node list in another format. Repeatedly clicking the latency test won’t restore a missing configuration.

2. Choose a Proxy Group: Select the Mode, Then a Node

A proxy group isn’t a node. It can contain multiple nodes or reference other proxy groups. In Rule mode, different destinations may match different groups, so choosing a node in one group doesn’t mean all traffic will use it.

Use Rule Mode for Your First Connection

Open the client’s “Proxies” page and set the mode to “Rule” (Rule). Find the proxy group used for regular proxied traffic, expand it, and select an actual node. Group names are set by the configuration author, so don’t assume a group’s purpose from its name alone. Check the rules and connection logs to confirm.

For example, a rule might send a website to a “Media” group. If you change only the “Default Proxy” group, that website’s outbound may not change at all. These group names are examples; use the names in your configuration. If the group contains an “Auto Select” subgroup, expand that too and note the final node.

New requests usually use the newly selected outbound, but existing long-lived connections may continue using the old one. Reload the page or open a new browser window to test. If you need to end a connection, close the relevant test connection rather than clearing all connections and interrupting downloads or calls.

3. Test Latency: Check Reachability, Not Download Speed

On the “Proxies” page, click the test button beside a node or proxy group. Wait for the test to finish before comparing results. A typical test has the core request a specified HTTP or HTTPS URL through the node and record the time taken. It isn’t a basic ICMP ping or a full bandwidth test.

How to Read the Test Results

• A result in milliseconds: The node completed the test request under the conditions of that run. Results depend on the test URL, handshake, network congestion, and caching.
• Timeout or failure: The test didn’t return a valid result before the deadline. The node may be unreachable, the test destination may be restricted, DNS may be failing, or the test settings may not suit your network.
• Low latency but slow websites: The test destination and the website you’re visiting may use different routes. A latency figure also can’t capture limited bandwidth, packet loss, or a slow website response.

For example, one node might show 82 ms, 91 ms, and 87 ms over three runs, while another shows 45 ms, a timeout, and 310 ms. The first node is generally the better choice for further connection checks. These are sample readings—not measurements from this site—and they don’t indicate download speed.

Compare Results Under the Same Test Conditions

If your client lets you choose a test URL, start with one already in the configuration and make sure it works on your network. A common connectivity check is https://www.gstatic.com/generate_204, which is expected to return HTTP 204, but it may not be reachable on every network. Don’t compare old and new results directly if you change the test URL.

For an initial check, wait about 10 seconds between runs and test three times. Avoid repeatedly testing large numbers of nodes. If just one node fails, try another first. If all nodes fail, check your subscription status, core logs, and local network. Reducing the test timeout only reports failures sooner; it won’t make a node faster.

4. Enable the System Proxy: Route Browser Requests Through the Client

Node tests are usually initiated directly by the core, so they can succeed even when the system proxy is off. To route a browser that follows system proxy settings through the client, you also need to enable “System Proxy” in the client. For your first test, leave TUN mode off to minimize the number of settings that can change.

1. Enable “System Proxy” in the client and make sure the switch stays on without reverting or showing an error.
2. In Windows 11, go to “Settings” → “Network & internet” → “Proxy.” Check the “Manual proxy setup” section; if needed, click “Edit” to verify the address and port.
3. The local proxy address is usually 127.0.0.1. The port should match the HTTP or mixed port provided by the client. Don’t enter your subscription URL as the proxy server address.
4. In a browser window without custom proxy rules, visit a test website while watching the client’s “Connections” page for new requests.

If you use PAC, Windows may show an automatic configuration script instead of a manual proxy server. Don’t add a second set of manual proxy settings while troubleshooting. Start with one method, confirm it works, and then change settings if needed.

TUN mode can help route traffic from apps that don’t follow system proxy settings. It usually requires extra permissions and involves a virtual network adapter, routing, and DNS configuration. Whether it captures a particular app depends on your configuration. If the system proxy works for your browser test, there’s no need to enable TUN just to see a “Connected” status.

5. Check the Browser and Connection Logs: Verify the Rule and Outbound

To confirm the proxy is working, both of these must be true: the target app’s request reaches the client, and that request uses the expected outbound. A page loading in your browser doesn’t tell you whether it connected directly or through a proxy. A successful latency test doesn’t prove that your browser is using the client either.

Find the Same Request on the Connections Page

1. Open the client’s “Connections” page and filter by domain, or watch for new entries.
2. Visit a clearly identifiable HTTPS website in your browser and note the time and domain. The test page should be publicly accessible and shouldn’t require an account.
3. Check the connection’s destination domain, matched rule, policy chain, and upload/download activity. Field names vary between clients.
4. If the policy chain ends in DIRECT, the request reached the client but was routed directly. It used the selected proxy outbound only if the chain ends at that node.

Some short-lived connections may disappear before you switch to the client. Open the Connections page before refreshing your browser, or look for a rule-matching entry from the same time on the “Logs” page. With the log level set to info, connection details are usually available, but the exact content depends on the core and client. The absence of a particular message doesn’t necessarily mean something is wrong.

For an additional check, use a reputable public IP lookup site. Compare your outbound IP address and network provider before and after connecting. Don’t rely on the country or region label alone: IP databases may be out of date, and rules may route a site directly. Cross-check the lookup result against the connection log.

6. Verify from the Command Line: Separate Local Listener Issues from Remote Failures

If browser behavior is unclear, explicitly specify the HTTP proxy in Windows PowerShell or Terminal. This bypasses the browser’s proxy selection logic, but doesn’t prove that the system proxy switch is working. First make sure the example port matches your settings.

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

-I requests response headers. --connect-timeout 10 limits the connection phase to 10 seconds, while --max-time 20 limits the entire request to 20 seconds. If your terminal has a NO_PROXY environment variable, check whether the test domain is listed as an exception. Also check whether the connection appears in the client.

• Can’t connect to the local port: Check that the core is running, the port is correct, and the port supports HTTP proxying.
• You see HTTP 200 Connection established: This only means the proxy tunnel was established. Check the subsequent TLS handshake and destination response before deciding that the entire request succeeded.
• You receive response headers from the destination: The explicitly proxied request completed an HTTP exchange. Even if the destination returns 403, distinguish a website denying access from a complete connection failure.
• You see a certificate error: Check the system time, certificate trust, and network environment. Don’t use certificate-check bypasses as a long-term fix.

To check whether a port is listening, run this command in Windows Terminal:

netstat -ano | findstr ":7890"

Look for an entry with port 7890 in the local address column and status LISTENING. This filter may show other related entries, so check each column. To identify the PID, find the matching process under “Details” in Task Manager. A listening port only proves that a process has claimed it; confirm that the process belongs to the current client’s core.

7. Common Results and Wrapping Up Your First Connection

Once your first connection is working, keep a reproducible setup: Rule mode, a confirmed working node, the actual listening port, and a test request you can find on the Connections page. If you temporarily switched to Global mode, switch back to Rule mode. If you raised the log level, restore your usual setting.

Turn off the system proxy before closing the client to avoid leaving Windows pointed at a local port that’s no longer listening. If your browser can’t connect after the client exits, check Windows proxy settings for leftover entries. When you later enable startup or TUN mode, change one setting at a time, then repeat the browser and connection log checks.

A green status or a low latency number alone doesn’t prove that a connection works. The full chain should be: the app’s request reaches the client, the expected rule matches, the final node is clear, and the destination responds. For more basic steps, see the User Guide. If you encounter a specific error, continue troubleshooting by symptom in the Help Center.