First-Time Clash Setup: Choose a Node, Test Latency, and Verify Proxy Traffic

The key takeaway: seeing a latency number doesn’t mean your apps are using the proxy

For your first check, follow this order: confirm the configuration is enabled, choose an available node, turn on the system proxy, then check a new request in the connection log. Check your exit IP last. Don’t enable TUN, change DNS, edit rules, and switch nodes all at once—if the site starts working, you won’t know which change fixed it.

Clash is a common name for a family of clients and cores. Clients using the mihomo core may have different interfaces and features, but there are three things to check: subscriptions provide nodes and rules, proxy groups determine which node is selected, and the traffic entry point determines whether app requests reach the core. A successful subscription import only confirms that the configuration was accepted; it doesn’t mean all three parts are connected.

1. Confirm that the configuration is enabled. Don’t just check that its name appears in the subscription list; make sure the imported configuration is the one currently running.
2. Set the operating mode to Rule mode. Keep the existing rules for your first check instead of forcing all traffic through the proxy.
3. Choose a node in the proxy group your rules actually use. Rules may point to different groups, such as “Proxy” or “Streaming.” Changing a group that isn’t referenced won’t affect traffic.
4. Turn on the system proxy and make a new request. Keep the connection panel open to see where the request goes after it reaches the core.

What latency tests measure: use the same URL before comparing nodes

The millisecond figure in a node list usually measures how long the core takes to request a specific URL through that node. It’s not necessarily an ICMP ping, and it isn’t a download speed test. The result may include connection setup, proxy protocol negotiation, TLS negotiation, and time waiting for an HTTP response. The exact timing depends on the core and test implementation.

For a fair comparison, keep test conditions the same

Check the client’s latency test settings or the url-test proxy group in your configuration. A common test target is a URL that returns HTTP 204, such as https://www.gstatic.com/generate_204. Test URLs differ in network location and reachability, so a result of 80 ms on one URL can’t be directly ranked against 120 ms on another.

• Use a consistent test URL: Compare results using the same URL; don’t switch to a different site midway.
• Run three rounds: For example, test three times at 10-second intervals and note each result. This is a way to observe results manually, not a recommendation to change the core’s interval settings.
• Pause bandwidth-heavy tasks: Downloads, cloud sync, and system updates use local bandwidth and can affect results.
• Note your network conditions: The same node may perform very differently on home Wi-Fi, a mobile hotspot, or an office network.

These hypothetical examples illustrate how to interpret results; they are not measured rankings of any service by this site. Three tests can help narrow down your options, but they can’t establish long-term packet loss rates or guarantee performance during peak hours.

A timeout doesn’t necessarily mean the node is completely unusable

A blocked test URL, DNS failure, expired node credentials, or a local network outage can all cause a timeout. If every node times out, check your network and the test URL first. If only one node keeps failing, compare it with another. If the test succeeds but a particular site won’t load, test that site directly—a 204 response doesn’t prove that every site is reachable.

Choose a node for your needs: assess latency, reliability, and exit region separately

Start with nodes that respond consistently across repeated tests, then narrow down your options based on what you’ll use them for. Regions, multipliers, and labels such as “premium route” in node names come from the provider; they don’t verify the exit location or prove connection quality. A low latency reading in the client especially doesn’t guarantee regional access or account eligibility on a particular site.

• Web browsing and online documents: Check whether pages load quickly the first time and whether ongoing use produces errors. A consistently moderate latency is often more useful than occasional fast results interrupted by frequent timeouts.
• Video streaming and file transfers: Check actual buffering and sustained throughput. A short request test can’t measure long-term transfer performance. Before testing downloads, check your data allowance and billing terms.
• Video calls and real-time communications: Also check jitter, packet loss, UDP support, and whether the app’s traffic enters the proxy. A successful HTTP test alone doesn’t prove that voice traffic will work.
• Services that require a specific region: Check the exit region, site rules, and the service’s own terms. The country shown by an IP database may not match the location the site detects.

For your first check, select one node manually

url-test automatically selects a route based on test results, while a fallback group typically selects an available node in the configured order. A manual selection group lets you choose the node yourself. Automatic switching can send consecutive requests through different exits. To get repeatable results, temporarily pin the relevant group to one node if your configuration allows it, then restore the automatic strategy when you’re done.

Also check whether proxy groups are nested. For example, “Proxy” may select “Auto,” which in turn points to a specific node. The outer group you see in the interface isn’t necessarily the final exit. Follow the group chain in the connection details to confirm where traffic goes.

Check 1: Find the domain and proxy route in the connection panel

The connection panel provides the clearest evidence. Open the client page labeled “Connections” or “Connection,” then visit the site in your browser while keeping the panel visible. Menu names vary by client; look for the active connection list showing destinations, traffic, and rules—not the node latency list.

1. Pause other downloads and search the connection list for the target domain.
2. Open a new page or an incognito window and make a real network request. A page served from cache may not create a new connection.
3. Open the new entry and check its destination domain or IP, matched rule, proxy group chain, and upload and download byte counts.
4. Confirm that the proxy group chain ends at the expected node, not DIRECT or REJECT.

If the request matches DIRECT, it reached the core, but the rule sent it out directly. That’s different from the browser bypassing Clash entirely. For the first case, check rule order and proxy group targets. For the second, check the system proxy, browser extensions, the app’s own proxy settings, or TUN routing.

A webpage doesn’t necessarily use just one connection. The main document, images, sign-in API, and video may use different domains and match different rules. Finding only the main site’s domain won’t explain why a video won’t play; check the request for the resource that failed.

Check 2: Use logs to distinguish traffic entry, rules, and upstream errors

The connection panel shows where traffic goes; logs show what happens along the way. Reproduce the issue once with the log level set to info. If that doesn’t provide enough detail, switch to debug briefly. Restore your usual level afterward to keep excess entries from obscuring useful clues.

Log formats vary between core versions, so don’t expect to find an exact matching English message. Instead, note when you performed the action, the target domain, and the selected node. Reproduce the issue once, then filter the logs for that time. Before sharing a screenshot, hide subscription URLs, credentials, node server addresses, and unrelated domains you visited.

If neither the logs nor the connection list shows the request, first make sure you’re looking at the currently running core, then check how the app connects to it. Repeatedly editing subscription rules won’t usually help when traffic hasn’t reached the core.

Check 3: Compare your exit IP, but don’t rely on the lookup page alone

An IP lookup tells you which exit was used to reach that lookup service. It doesn’t prove that every app uses the same node or that every protocol is being intercepted. In Rule mode, the lookup site may connect directly while your target site uses the proxy. Check the IP result alongside the connection entry for that lookup request.

Use an explicit proxy command to rule out browser settings

The example below uses Windows curl.exe to send a request directly to the local 7890 port. On macOS and Linux, the command is usually curl with the same options. The port must provide an HTTP or mixed proxy; don’t use a SOCKS-only port here.

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

The first command explicitly uses the HTTP proxy; the second tells curl not to use an application-level proxy. Both commands use a 10-second connection timeout and a 20-second total timeout. The third-party lookup service will see the exit IP for this request; there’s no need to publish the output.

• Explicit proxy works, but the browser doesn’t: The route used by the command works. Check the browser’s proxy settings, extensions, and rules for the relevant domains.
• Connection refused: First check that the client is running and the port is correct. The request may not have reached the node selection stage.
• The exit IPs differ: The requests used different exits. Check the connection panel to confirm the proxy request’s actual route.
• The exit IPs match: Don’t assume the test failed. The lookup domain may be set to connect directly, TUN or another VPN may be active, or both requests may share the same public exit.

An explicit connection to the local port will continue through a proxy node only if the rules send the lookup domain through the proxy. Reaching the local proxy port and using a remote exit are two separate things to verify.

Browser works, but other apps don’t: check TUN and per-app proxy settings

The system proxy doesn’t force every program to use a proxy. Some command-line tools use environment variables, some apps have their own HTTP or SOCKS settings, and others ignore the system proxy. If the browser works but another app has no connection entries, first check whether it supports proxy settings, then decide whether to enable TUN.

TUN extends traffic interception; it doesn’t reduce latency

TUN uses a virtual network interface and routing to send more traffic to the core. Whether it works also depends on administrator permissions, service status, route configuration, and DNS interception. It won’t make a node faster, nor does it automatically turn Rule mode into Global mode. After traffic enters TUN, rules may still send it out directly.

1. Save your current settings first. Enable TUN alone; don’t change DNS mode or subscription contents at the same time.
2. Check whether the client reports that the virtual interface was created successfully and that permissions and services are set up correctly.
3. Restart the target app or close its existing connections, make a new request, and check the connection panel.
4. If TUN conflicts with a company VPN or another tunnel tool, restore your original settings and test each one separately. Don’t delete system routes blindly.

UDP apps also need UDP forwarding support from the node protocol, server, and local configuration. Even if an app’s connection appears in TUN, HTTP latency figures alone can’t tell you how games or calls will perform. Use the app’s own network stats to check packet loss and jitter, and compare them with results when the proxy is off.

For setup steps and key terms, see Getting Started and the proxy mode section of the user guide. If your connection is already stable, there’s no need to change several settings at once just to chase a lower test result.

First connection checklist

Passing these five checks matters more than seeing a very low millisecond figure in a screenshot. Note your network, target domain, node name, actual exit, and test time so you can repeat the same checks if a problem comes up later.

• Configuration: The expected subscription is running, with its nodes and rules loaded.
• Node: It responds consistently to the same test URL, and the actual site you need works too.
• Traffic entry: A new request from your browser or target app appears in the connection panel.
• Route: The request matches the expected rule, and the proxy group chain ends at the selected node—not an unintended direct connection.
• Exit: The IP lookup result matches the route shown for that request. Check other apps separately.

If a check fails, troubleshoot at that layer: no connection means check the traffic entry; a connection going direct means check the rules; a selected node that still fails means check the upstream route. Change one variable at a time—it’s usually easier to find the cause than by repeatedly flipping every switch.