How to Choose a Clash Node on First Connection: Test Latency, Switch Nodes, and Verify the Proxy

Complete the connection path before comparing nodes

When using Clash or a Mihomo-based client for the first time, do not focus on the latency numbers in the node list yet. A complete connection involves at least four steps: the profile is loaded, a node is selected in the proxy group, system traffic is handed to the client, and the node can reach the target website. If any step is incomplete, you may see a node with a latency value while webpages still fail to load.

Follow a consistent order: import the subscription, update the profile, choose a proxy mode, enable the system proxy or TUN mode, then select a node in the proxy group. Labels vary slightly between graphical clients; the usual path is “Subscriptions” → “Update”, followed by “Proxies” → the target proxy group. If you only open the client without enabling the system proxy, browsers usually continue connecting directly over the existing network.

On the “Subscriptions” or “Profiles” page, confirm that the current Profile is enabled and run one manual update.
Open the “Proxies” page and set the mode to “Rule”; for a first test, avoid using “Direct” immediately.
Open “Settings” → “System Proxy” and confirm that the switch is enabled.
Return to “Proxies” → the main proxy group and select a node that can complete a latency test.
Check the external IP before and after enabling the proxy. Confirm that it changes, then test the actual website.

Manual selection, automatic testing, and failover

In a Clash configuration, node selection actually takes place inside a proxy group. A proxy group combines proxy nodes with selection logic. The most common types are select, url-test, fallback, and load-balance. Subscription providers may label them as “Node Selection”, “Auto Select”, “Failover”, or “Load Balancing”.

Proxy group type	Selection method	Best for	Keep in mind
`select`	The user manually selects one node	Initial troubleshooting, a fixed region, or a stable external IP	If the current node fails, you usually need to switch manually
`url-test`	Periodically test nodes and select one with lower latency	Everyday browsing with many available nodes	The test target’s route may differ from the route to the actual website
`fallback`	Select the first available node in configuration order	Primary and backup routes, or a preferred region	Prioritizes availability, not necessarily the lowest latency
`load-balance`	Distribute connections across multiple nodes according to policy	Sharing connections across multiple routes	The same service may see different external IPs

Use a manual proxy group for the first connection

Manual selection is best for the first test because it introduces fewer variables. Start by fixing one node in a select proxy group, then complete the external IP, webpage, and command-line tests. If the connection works, switch to an automatic testing group. That way, if automatic selection performs poorly, you can identify the testing logic as the source instead of suspecting the system proxy or subscription import.

Region, multiplier, and route labels in node names are for categorization only; they cannot replace real-world testing. “Hong Kong 01” is not necessarily faster than “Japan 02”, and “premium route” says nothing conclusive about the connection quality between your local network and the entry server. Shorter distance often helps reduce round-trip time, but carrier interconnection, peak-hour congestion, and node load can change the result.

Automatic testing measures the test target

url-test periodically requests the test address specified in the configuration, then compares the response times of candidate nodes. Here is a common Mihomo configuration snippet:

proxy-groups:
  - name: Auto Select
    type: url-test
    proxies:
      - Hong Kong 01
      - Japan 02
      - Singapore 01
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

interval: 300 means the nodes are retested roughly every 300 seconds; tolerance: 50 allows the current node to remain selected when the difference between candidates is small, reducing frequent switching. A test address that responds quickly only shows that the node is currently performing well for that target. It does not guarantee the same result for video, code repositories, or business services.

How to interpret latency numbers

The latency shown by a client is usually not a traditional ICMP ping. Most Clash graphical clients send an HTTP request through the proxy and measure the time required to establish the connection and receive a response. The result is affected by the local network, proxy entry point, node exit, DNS, TLS handshake, and test server status. Latency is therefore a filtering tool, not a bandwidth test.

Measured latency	Typical experience	Recommendation
30–80 ms	Pages usually respond quickly	A good candidate for initial testing, but still verify the external IP
80–180 ms	Generally suitable for everyday browsing	Common on cross-region routes; do not reject a node solely because the value has three digits
180–350 ms	Pages and interactions may feel sluggish	Run three consecutive tests and check for consistency
Above 350 ms	Noticeable stuttering is more likely	Try another node in the same region or change the entry route
Timeout	The test request did not finish within the time limit	Check the node status, update the subscription, and inspect the local network

Do not assume a node is stable because it recorded 65 ms once. A more reliable approach is to test it three to five times at 10-second intervals. For example, 72, 75, 79, and 74 ms indicate small variation; another node returning 48, 210, 93, and a timeout may be much less reliable in practice despite its lower minimum. For video and downloads, also watch sustained throughput. For remote terminals and interactive webpages, give more weight to latency and jitter.

What to check when every latency test times out

Confirm that the computer itself can access ordinary websites directly, ruling out a disconnected Wi-Fi connection or gateway failure.
Go to “Subscriptions” → “Update” and fetch the profile again to avoid using expired node information.
Check the system clock and time zone. A large time difference can cause TLS certificate verification to fail.
Temporarily disable TUN and test with only the system proxy enabled, avoiding interference between multiple traffic-capture methods.
Confirm that the local mixed port is not occupied by another program; 7890 is a common value.
Check the client logs, focusing on timeout, connection refused, and network unreachable.

Why does the external IP not change immediately after switching nodes?

After selecting a new node in a proxy group, new connections will usually use it, but existing connections may continue reusing the old channel. Browser HTTP/2 and HTTP/3 persistent connections, segmented download tasks, and long-lived connections in messaging apps can all keep the old exit active briefly. As a result, refreshing the same page immediately after switching may not show a changed external IP.

Follow these steps to establish new connections

Open “Proxies” → the main proxy group and confirm that the selection marker has moved to the new node.
Close the webpage tab under test and wait 5 to 10 seconds.
Open a new private window to avoid interference from page caches and existing connections.
Check the external IP again and compare it with the address from before the switch.
If it still has not changed, restart the browser. If necessary, close old connections from the client’s connections page.

Also check whether rule mode has assigned the test website to the expected proxy group. Rule mode matches domains, IPs, processes, or rule sets from top to bottom. If the external IP lookup domain matches DIRECT, the page will still show your local public IP even when the main proxy group has a proxy selected. During troubleshooting, find the domain in the client logs or connections list and verify the matched rule, proxy group, and actual node.

You can briefly switch to Global mode for comparison. In Global mode, traffic is generally sent uniformly through the specified proxy node. If Global mode changes the external IP but Rule mode does not, the issue is likely in rule matching or proxy-group references. Switch back to Rule mode after testing so that local-network traffic and services in mainland China that should connect directly do not unnecessarily use the proxy.

Verify the proxy with an external IP lookup

The clearest method is to disable the system proxy first, visit a public IP lookup service, and record the current external address. Then enable the system proxy and refresh the lookup. If the results differ and the post-proxy region roughly matches the selected node, browser traffic is going through the proxy. Do not rely only on the country or city shown on the page; the IP address itself is a better basis for comparison.

Turn off Clash’s “System Proxy” switch, open an IP lookup page, and record one or more IPv4 or IPv6 addresses.
Turn “System Proxy” back on and fix one node in the proxy group.
Open a new private browser window and check the external IP again.
Switch to a node in another region, close the lookup tab, and open it again to confirm that the address changes a second time.
Return to the client’s “Connections” page and check whether the lookup domain went through the intended proxy group.

If IPv4 has changed but IPv6 still shows an address from your local carrier, check whether the client is handling IPv6 and whether the lookup service prefers IPv6. IPv6 behavior varies by operating system, TUN configuration, and network environment. Testing IPv4 alone does not prove that all IPv6 traffic follows the same path.

Test direct and proxied connections separately from the command line

Command-line tests bypass browser extensions, caches, and persistent connections, making it easier to confirm whether the local proxy port works. The examples below assume that Mihomo’s mixed port is 127.0.0.1:7890. A mixed port accepts both HTTP and SOCKS connections; if the client uses another port, follow the value shown under “Settings” → “Port Settings”.

Windows PowerShell

On Windows 10 or Windows 11, first confirm the actual curl.exe executable to prevent older PowerShell versions from interpreting curl as another command. Run the direct and proxied requests separately:

curl.exe --noproxy "*" https://api.ipify.org
curl.exe -x http://127.0.0.1:7890 https://api.ipify.org

macOS and Linux

curl --noproxy "*" https://api.ipify.org
curl -x http://127.0.0.1:7890 https://api.ipify.org

The first command explicitly bypasses the proxy and returns the public exit address of the local network; the second sends the request to the Clash mixed port. If the commands return different addresses and the second request also appears in the client’s connection log, the HTTP proxy path is working. If the second command cannot connect to 127.0.0.1:7890, check that the client is running, the port is correct, and the listening address allows local access.

You can also test SOCKS5 and let the proxy resolve the domain name:

curl --socks5-hostname 127.0.0.1:7890 https://api.ipify.org

--socks5-hostname differs from plain --socks5 in one important way: the former sends domain resolution to the SOCKS proxy, which helps rule out the effect of local DNS results. If the HTTP proxy works but the SOCKS request fails, check whether the port is a mixed port, an HTTP port, or a dedicated SOCKS port.

Check whether the local port is listening

On Windows, run:

netstat -ano | findstr :7890

On macOS, run:

lsof -nP -iTCP:7890 -sTCP:LISTEN

On Linux, run:

ss -lntp | grep 7890

Seeing 127.0.0.1:7890 or 0.0.0.0:7890 in a listening state means that a program is accepting connections on the port, but it does not by itself prove that the node works. Combine this with proxy request results and client logs. If the listening process is not the current Clash client, there may be a port conflict. Close the conflicting program or update the client port and system proxy settings consistently.

What to do when the browser works but other apps do not

Browser access does not mean that every program reads the system proxy. Some games, command-line tools, store apps, and software with its own network stack ignore HTTP proxy settings. First check whether the application provides its own proxy options. If it does, enter the HTTP proxy as 127.0.0.1:7890, or use the same mixed port for a SOCKS5 proxy.

If the application has no proxy settings, consider TUN mode. A common path is “Settings” → “Mihomo” or “Core Settings” → “TUN Mode”. Initial activation may require administrator privileges and create a virtual network adapter. After enabling it, retest the external IP and the target application. Also check that local devices, printers, and corporate intranet services can still connect directly according to the rules.

What to verify in TUN mode

The client logs show new connections generated by the target application.
The connection record shows the correct rule and proxy group, rather than unexpectedly matching DIRECT.
DNS requests complete normally without repeated resolution timeouts.
After the system proxy is disabled, the target application can still connect according to the rules in TUN mode.
After exiting the client, network access recovers normally, with no abnormal leftover default route or DNS settings.

Do not repeatedly switch the system proxy, TUN, Global mode, and multiple nodes at the same time. Change one variable at a time and record the result. For example, fix “Japan 02” and enable only the system proxy; once command-line proxy access works, enable TUN; finally restore Rule mode. This order quickly identifies whether the problem lies with the node, port, rules, or traffic-capture layer.

First-connection stability checklist

After selecting a node with relatively low latency, run another round of continuous tests. Open three different types of websites and keep them open for 5 minutes; download a public test file of about 50 MB and watch whether the speed remains consistent; switch pages twice and review the client’s connection records. A node that passes a brief latency test but starts timing out repeatedly after a few minutes often indicates node load, route jitter, or an unstable local network.

The Profile is updated, and the configuration update time shown by the client is as expected.
The main proxy group clearly selects one node rather than accidentally selecting DIRECT.
Three consecutive latency tests show no major swings or frequent timeouts.
At least one of the system proxy or TUN mode is enabled and matches the test target.
The external IP differs before and after proxying, and the connection log shows the target node name.
Common websites match the expected proxy group in Rule mode.
The system network recovers normally after the client is closed.

The final choice does not need to be the lowest number in the list. A node that stays around 110 ms and works consistently is usually better for everyday work than one fluctuating between 45 and 400 ms. Prioritize availability and stability first, then adjust the proxy group based on video performance, webpage response, or specific regional requirements.