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

1. Before connecting: Check that the profile is active and the core is running

Importing a subscription adds nodes and rules to the client, but it doesn’t mean your browser is using a proxy. A complete connection involves four steps: activate the profile, choose a policy, route app traffic through the core, and confirm that requests are sent through the expected node. Skip any step and you may find that a node has a latency reading but websites won’t load.

This guide uses the common desktop interface in Clash Verge Rev. Button labels and settings groups may vary slightly between versions, so refer to the interface in your installed version. Clash Verge Rev manages profiles and the UI, while mihomo is the core that handles proxy connections, DNS, and rule matching.

1. Open Profiles in the sidebar and check that your imported subscription appears and is selected as the active profile. A profile appearing in the list doesn’t mean it’s enabled.
2. Open Proxies and check that you can see policy groups and their nodes, rather than a blank page. Group names come from the subscription and may be called “Proxy”, “Select”, or something else.
3. Open Logs and check whether the latest profile load succeeded. If you see a YAML parsing error, a port binding failure, or repeated core exits, resolve those issues first.
4. Note the proxy listening address and port. The commands below use 127.0.0.1:7897 as an example; use the mixed port shown in the client settings instead of copying it as-is.

2. Choose a node in its policy group—not just by clicking a node name

Open Proxies and check the current mode. For your first connection, we recommend Rule mode: requests are routed according to the profile’s rules to DIRECT, a proxy policy group, or REJECT. Global mode routes requests that reach the core through the global policy, but doesn’t automatically capture traffic from every app. Direct mode isn’t suitable for checking your proxy exit either.

Find the policy group your rules actually use

A policy group sits between the rules and the nodes. Suppose a rule routes a domain to “Select”, but that group currently points to DIRECT. Even if you’ve chosen an overseas node in another group, this request may still go direct. Expand the group handling traffic for your target site, then select a specific node within it.

• select: Manual selection. A good choice for your first check: once you select a node, you have a consistent test target.
• url-test: Automatically selects a node based on health checks. The current node may change as test results come in, so don’t assume the selection you saw earlier is permanent.
• fallback: Usually selects an available node based on the order in the profile; it doesn’t necessarily pick the node with the lowest latency.

If a group contains other policy groups, keep expanding until you can confirm the node in use. Country labels, multipliers, and usage notes in node names are supplied by the provider; they don’t verify the actual exit location. For a first test, choose a healthy, standard node in a suitable location, then compare its latency with others.

3. Test latency: Check reachability first, then consistency

Click the latency test button next to a policy group or node. The client usually sends a request to a test URL through the selected node and displays the response time; exactly what it measures depends on the core and test implementation. It’s not a simple ICMP ping, doesn’t measure download speed, and can’t prove that every website is reachable.

Control variables and run three tests

1. Pause large downloads and speed tests first so they don’t saturate your local bandwidth and skew the results.
2. Test the same group three times, about 5–10 seconds apart, and see whether any candidate nodes repeatedly time out.
3. Choose nodes that complete the test consistently before comparing latency. Don’t decide based on a single lowest reading.

For example, node A returns 86, 92, and 89 ms across three tests, while node B returns 45 ms, times out, then returns 410 ms. For a first connection, node A is the better choice. These figures are examples of how to interpret results, not measurements from this guide. Consistency is a better indicator of short-term availability than one unusually low latency reading.

If a test times out, first identify what failed

timeout means the test didn’t finish within the time limit; it doesn’t necessarily mean the subscription is invalid. DNS resolution for the test URL may fail, the node may be unreachable, or the test site may refuse the request. If every node times out, check your local network, subscription status, and logs before cycling through dozens of nodes.

If your profile uses https://www.gstatic.com/generate_204 as the test URL, the expected response is HTTP 204: the request succeeds with no response body. Reachability of this URL is just one data point. Even if latency looks good, verify the connection with your target website next.

4. Enable the system proxy to route browser requests through the core

After choosing a node, open Settings and turn on System Proxy. If settings are grouped, you’ll usually find it under Network. Don’t confuse Allow LAN with the system proxy switch: it lets other devices connect to your local proxy port and isn’t needed for your first connection from this device.

The system proxy points your operating system’s proxy settings to a local listening port. On Windows, check Settings → Network & Internet → Proxy. On macOS, go to System Settings → Network → your current connection → Details → Proxies. Make sure the address and port match what the client is actually listening on.

• Browsers such as Chrome and Edge usually use the system proxy, but extensions, launch options, or enterprise policies may override this behavior.
• Firefox has its own proxy settings. If it isn’t following the system settings, go to Settings → General → Network Settings and select Use system proxy settings.
• Command-line tools and some games may not use the system proxy. A working browser connection doesn’t mean every app is routed through the proxy.

5. Check the Connections view: See which rule matched and which node handled the request

Keep the client’s Connections view open, then load a new page in your browser. Don’t rely on a static page that’s already loaded. Close the tab and revisit the site, or use a new private window to reduce interference from cached content and existing connections. Private browsing doesn’t change your proxy settings.

Filter the connection list by the target domain and expand the connection details. Depending on the version, fields may be labeled “Rule”, “Matched Rule”, “Chain”, or “Proxy Chain”. Check these three items.

A DIRECT result for a site in mainland China isn’t necessarily a problem; rules can intentionally route some traffic directly. But if the site you’re testing should use a proxy and the connection shows DIRECT, check the matched rule and policy group selection instead of just toggling the system proxy again.

If no new record appears in the Connections view, first check whether the browser is actually using the local proxy and whether the list has any filters applied. Short-lived requests may disappear quickly, so open the view before refreshing the target page and check the logs as well. Don’t assume the node is unavailable just because the list is briefly empty.

6. Compare exit IPs to confirm that traffic is using the proxy

Once the connection chain shows the selected node, visit an IP lookup service and note your public exit IP. First, turn off the system proxy and make sure TUN is off, then look up your IP again to establish a direct-connection baseline. Restore the system proxy and run a new lookup in a fresh page. Use the same lookup service for both checks where possible; different databases may report different locations.

The IP lookup site is also subject to your rules. If it matches DIRECT, seeing your local exit IP is expected and doesn’t mean other sites aren’t using the proxy. Check the connection record for the IP lookup request too. The IP’s reported location is only a clue; whether the address changed and whether the connection used the intended node matter more.

Use an explicit proxy command to isolate browser settings

If the browser results are unclear, compare your IPv4 exit using the two commands below. In Windows PowerShell, use curl.exe to run the executable; on macOS and Linux, use curl. Replace the example port 7897 with the client’s actual mixed port.

# Windows: Query the direct-connection baseline without curl proxy settings
curl.exe -4 --noproxy "*" --max-time 15 https://api.ipify.org

# Windows: Connect explicitly through the local HTTP proxy
curl.exe -4 --proxy http://127.0.0.1:7897 --noproxy "" --max-time 15 https://api.ipify.org

# macOS / Linux
curl -4 --noproxy "*" --max-time 15 https://api.ipify.org
curl -4 --proxy http://127.0.0.1:7897 --noproxy "" --max-time 15 https://api.ipify.org

--max-time 15 sets a 15-second total time limit for each request. -4 uses IPv4 for both checks, so differences between IPv4 and IPv6 addresses aren’t mistaken for proxy effects. The empty --noproxy in the proxy command clears any bypass list in the environment. However, an explicit proxy still follows the core’s routing mode and rules; it doesn’t force every destination through the selected node.

For a direct-connection baseline, TUN and any other VPNs must also be off. --noproxy bypasses only curl’s proxy settings; it can’t bypass system-level traffic routing. If the command can’t connect to 127.0.0.1, check the listening port and core status first. If the explicit proxy works but the browser doesn’t, focus on browser settings or extensions.

7. Verify your first connection, then test TUN separately

A reliable check needs three pieces of evidence that agree: the node test completes, the target request’s connection chain points to the expected node, and the IP lookup matches that route. A page loading or a green latency result alone isn’t enough.

• Latency looks good, but pages won’t load: Check the system proxy, the actual listening port, and the rule matched by the target domain in the Connections view.
• Pages load, but the exit IP hasn’t changed: Check whether the IP lookup request matched DIRECT, then see whether the browser is bypassing the proxy.
• The exit IP changed, but one site still fails: Check that site’s connections and logs, and consider node exit restrictions, DNS results, or the site’s own access policies.
• The browser works, but other apps don’t: Check whether those apps support the system proxy. If needed, consider routing them with TUN.

TUN mode uses a virtual network interface to route more IP traffic. It’s useful for apps that don’t use the system proxy, but it isn’t the same feature. Enabling it may require service mode or administrator privileges, and its routes may conflict with another VPN. Keep the working profile and node, change only the routing method, then check the connection chain for the target app again.

Finally, note the current profile name, policy group selection, and mixed port for future reference. If you need help, share the client and operating system versions, redacted error logs, and connection results. Don’t share subscription URLs, node passwords, or access tokens. Once you’ve completed these checks, you can confirm that the request entered the core and was sent through the expected proxy node.