Choosing a Clash Proxy for Your First Connection: Test Latency and Verify Traffic Routing

First connection: Choose a stable proxy, then verify the traffic path

You don’t need to find the absolute lowest latency in the proxy list for your first connection. In the policy group used by your current rules, choose a proxy that passes repeated tests and can open the site you need. Then check the connection record to confirm the request actually used it. Finally, look up your public IP to see which exit address the site sees. These three checks together are more reliable than a single green latency reading.

This guide applies to common clients running the Clash or Clash Meta (mihomo) core. Labels and layouts vary between client apps, so the steps refer to sections such as Profiles, Proxies, Connections, and Logs rather than assuming a particular client’s switch locations. If your device already uses TUN or a corporate network configuration, note its current state first. Don’t delete routes or disable security software without checking what depends on them.

1. After importing a subscription, confirm the profile and policy group are active

An imported subscription doesn’t mean a proxy is in use

A subscription provides proxy nodes, rules, and other configuration. The client loads that configuration, and the core handles connections. Seeing nodes in a list only means their details were read. If an old profile is still active or your rules point to a different policy group, testing a node won’t change the route your browser uses.

1. Open Profiles and confirm the newly imported profile is active. Check when the subscription was last updated and look for errors such as a failed parse or download.
2. Open Proxies and set the mode to Rule. Global usually routes traffic through the global policy, while Direct bypasses proxies, so neither is a substitute for checking the proxy chain used by your rules.
3. Find the selection group referenced by the rule. If there are nested policy groups, follow the selected entries down until you reach the actual proxy node, rather than stopping at a group named “Auto Select.”
4. For initial troubleshooting, pin a proxy in a manually selectable select group. An automatic group may switch proxies after a health check, making it hard to compare tests that use the same exit.

For example, a rule may point to “Proxy Select,” while that group currently selects DIRECT. In that case, a different node showing 80 ms won’t make the rule use it. If the configuration has no manual selection group, don’t rewrite the entire subscription. Note which proxy the automatic group currently selects, then use connection details to identify the actual route.

Check the traffic capture controls and local listening port

Before testing in a browser, enable the client’s system proxy and confirm the browser uses the system proxy settings. Browser extensions, custom proxy settings, or another VPN can change the route. Terminal programs don’t necessarily use the system proxy; a later section shows how to test with an explicitly specified proxy.

The local address is usually 127.0.0.1, but use the port in your actual configuration. The snippet below only illustrates what the port settings mean; it isn’t a complete, working configuration and contains no proxy nodes or subscription details:

# Example configuration snippet: do not overwrite your subscription
mixed-port: 7890
allow-lan: false
mode: rule

mixed-port: 7890 means the listener accepts both HTTP and SOCKS proxy requests. Some configurations use separate port and socks-port settings. Don’t mistake the controller port for a proxy port, or change a working listener just because an example uses 7890.

2. What proxy latency measures—and how to compare it

A client’s proxy latency usually measures how long it takes to reach a specified test URL through that proxy. It isn’t the same as an ICMP ping or a download speed test. Results depend on the test URL, DNS, connection reuse, proxy load, and client implementation, so numbers from different clients aren’t directly comparable.

Some configurations use https://www.gstatic.com/generate_204 as the connectivity test URL. If that address is blocked or restricted on a route, a proxy may time out even when other sites work. Conversely, a successful test doesn’t guarantee access to a particular streaming site, work service, or game.

Use three rounds of testing instead of ranking proxies by one result

1. Start with two or three candidate proxies. Testing hundreds at once can create unnecessary load on your current network.
2. Use the same network and test URL. Run three rounds, about 10 seconds apart.
3. Record timeouts and latency fluctuations, then visit the same target site.

The following is an example of how to interpret results, not a test performed by this site: Proxy A returns 68 ms, 240 ms, and a timeout over three rounds; Proxy B returns 105, 112, and 109 ms. For a repeatable baseline on your first connection, start with B rather than choosing A based on its lowest reading. If both are stable, choose the one that meets the target service’s location requirements and works well in practice. A shorter geographic distance doesn’t guarantee a shorter route between networks.

3. Verify with a browser: a page loading doesn’t prove it used the proxy

Browser checks should use a real network request. A page that’s already open may come from the cache, and a Service Worker may serve some resources. Seeing a page on screen doesn’t prove the new configuration is active. In your browser’s Network panel, temporarily enable Disable cache, keep developer tools open, reload the page, and note the test time.

1. Choose a domain you actually need to access. Close unrelated tabs to reduce background requests.
2. In your browser settings, confirm that it uses the system proxy. If you have a proxy extension, note its current settings and temporarily disable it so it can’t override the system configuration.
3. Reload the target site. Check that the main document receives a response and look for proxy connection or certificate errors.
4. Immediately switch to the client’s Connections page and find the request by domain or timestamp.

A page loading in the browser is one part of the check; a page failing to load doesn’t necessarily mean the proxy is broken. If the request used the proxy chain and other sites work, investigate the target site, regional restrictions, account status, and DNS results separately.

4. Check rules, policy groups, and proxies in connection records and logs

Connections and Logs serve different purposes: Connections shows the request route, while Logs can help diagnose handshake failures, DNS resolution errors, refused connections, and similar issues. Fields vary by client, but look for at least the target domain or IP, the matched rule, and the final proxy chain.

• Target: Confirm that the record matches the domain you just visited, not browser telemetry or another background app.
• Rule: Check the matched rule type and value, such as a domain rule, a rule set, or the final MATCH rule.
• Proxy chain: Confirm that the policy group ultimately selects your chosen proxy, not DIRECT, REJECT, or another automatic group.
• Traffic: Upload and download bytes can help confirm that data is flowing, but increasing byte counts don’t guarantee that the page loaded completely.

If the Connections page shows only active connections, a short request may disappear before you can inspect it. Open the page before reloading the site, or use connection history if your client supports it. You can temporarily set Logs to info to observe routing. If that isn’t enough, enable debug briefly and switch it back afterward to avoid accumulating excessive logs.

Follow the evidence; change one thing at a time

• No matching record: First check whether traffic is reaching the core, whether the browser is bypassing the proxy, and whether the request came from cache.
• Record shows DIRECT: Check rule order and the selected policy group. Rules are usually evaluated in order, so an earlier match may determine the route.
• Proxy selected, but connection failed: Use the error to distinguish an unreachable proxy server from authentication, TLS, or target connection timeouts.
• Old exit after switching proxies: Existing long-lived connections may continue using the old route. Close the target tab or only the relevant connection, then make a new request. Don’t clear every connection and interrupt unrelated work.

Before sharing screenshots or logs, hide subscription links, tokens, proxy server addresses, and personal network details. Subscription URLs often contain access credentials and shouldn’t be posted in public forums.

5. Cross-check with your public IP and an explicitly configured proxy

Your public IP is the address the lookup service sees as the source of your request. It can help distinguish your regular internet connection from a proxy exit, but IP geolocation databases may be out of date, and a single proxy may use multiple exit addresses. Check the connection record too; a city label alone doesn’t prove the route is faulty.

Set up a direct-versus-proxy comparison

If it’s safe to do so on your personal network, first note your public IP with the proxy off, TUN off, and no other VPN in control. Then enable the proxy and query the same service again. If TUN or another system-level tunnel is still active, requests that don’t use an HTTP proxy may still be routed through it, so they aren’t a valid direct-connection baseline.

The example below uses a local HTTP proxy at 127.0.0.1:7890. Run it as written only if that matches your actual port; these commands won’t change system settings. In Windows PowerShell, use curl.exe instead of curl to avoid environments where the latter resolves to a different command.

# Without curl's explicit proxy setting; this does not mean TUN is bypassed
curl --noproxy "*" --connect-timeout 10 --max-time 20 https://api.ipify.org

# Force the request through the specified HTTP proxy port to the same lookup service
curl --noproxy "" --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 https://api.ipify.org

--noproxy "" clears the proxy bypass list for this request, preventing an existing NO_PROXY setting from interfering. If the lookup service is unavailable, try another trusted public IP lookup service. A timeout from one service doesn’t mean the entire route has failed. A public IP lookup reveals your connection’s exit address to that service.

Verify a real HTTPS request and its response time

curl --noproxy "" --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 --output /dev/null --write-out "HTTP=%{http_code} total=%{time_total}s\n" https://example.com/

On macOS and Linux, use /dev/null as above; on Windows, use NUL and curl.exe. The example domain demonstrates the command syntax. When troubleshooting a service, replace it with the actual target address. HTTP 200 means that request received a successful response; it doesn’t mean every site is reachable. A 403 or 429 may also mean the request reached the site through the proxy, but was denied by the site’s policy.

time_total is the duration of the entire request, including response transfer, so it isn’t directly comparable to the client’s proxy latency test. If the explicit proxy command works but the browser doesn’t, check how the browser is routed and whether its rules differ. If the command can’t connect to 127.0.0.1:7890, first check that the core is running and the port is correct; don’t immediately switch remote proxies.

6. Common first-connection issues and what to check

Latency readings are available, but the target site won’t load

First confirm that the site used the proxy you tested. Then distinguish DNS errors, connection timeouts, and HTTP denials. A working route to the test server doesn’t guarantee a working route to every destination. If only one domain is affected, compare it with another proxy while keeping the browser, rules, and test time range the same.

The browser uses the proxy, but the terminal’s public IP is unchanged

A system proxy usually doesn’t capture traffic from every app. Many command-line tools need environment variables or their own proxy options. Start by verifying with the explicit --proxy setting above. Consider TUN only if you specifically need to route apps that don’t honor the system proxy. TUN can interact with routing, DNS, permissions, and other VPNs, so don’t add it as another variable during your first latency test.

Your public IP changed, but it’s not in the expected region

Check the proxy chain used by the lookup request, confirm that an automatic group or an old connection wasn’t involved, and see whether IPv4 and IPv6 take different routes. On a dual-stack network, test each address family with a lookup service that supports it. One location label isn’t enough to determine where all your traffic exits.

Every proxy times out

Troubleshoot in this order: can you access the internet locally → is the core running → is the subscription valid → can the test URL be reached → do the logs show DNS or authentication errors? If other devices on the same network have the same issue, look for a shared cause instead of repeatedly reinstalling the client.

You can define clear criteria for a successful first connection: the target site responds normally, connection details show the expected rule and proxy, and the IP lookup matches that proxy chain. Once all three check out, you can explore automatic routing, app-specific rules, or TUN coverage. That’s more useful for future troubleshooting than chasing the lowest latency number.