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

Confirm that the configuration is active before connecting

Successfully importing a subscription only means that the client has obtained the configuration file; it does not mean that a proxy connection has been established. Before your first connection, confirm that the configuration, core, mode, and system integration settings are aligned. Menu labels vary slightly between clients. A common path is 「Profiles」 → 「Subscriptions」 to select the profile you just imported, followed by 「Settings」 → 「Preferences」 to confirm that the core is running.

Clients using the mihomo core usually show the running status, core version, and controller port. If the main screen still says “Not started” or the logs show no new entries, start the core before testing nodes again. The latency button relies on the core; when it is not running, every node may appear to time out.

Four checks for your first connection

1. Profile selected: Only the file marked as the active profile participates in rule matching. After updating a subscription, make sure the client is not still using an older local profile.
2. Mode is clear: For a first connection, use 「Rule」 mode. It follows the rules in the configuration to decide whether traffic goes direct or through the proxy, making it easier to inspect the actual match on the connections page.
3. Proxy integration enabled: Desktop browsers usually require 「System Proxy」 to be enabled. To capture applications that do not read the system proxy, use TUN mode instead.
4. No port conflicts: Common configurations use HTTP or mixed-port 7890; the SOCKS port is often 7891. The current profile and the client's settings page are authoritative.

If System Proxy and TUN are enabled at the same time, test results may combine two interception paths. For initial troubleshooting, enable only one: verify the browser with System Proxy first, then test TUN if needed. This prevents a working TUN route from being mistaken for a working system proxy, or a browser-specific proxy setting from being misdiagnosed as a node failure.

Step 1: Choose the right node in a policy group

Clash configurations usually do not point rules directly at a specific node. Instead, rules reference a policy group, which then selects a node or another policy group. Common names include 「Node Select」, 「Proxy」, 「Manual Select」, 「Auto Select」, and 「Fallback」. Names are defined by the subscription provider, so configurations vary.

Find the policy group ultimately referenced by the rules

Open the 「Proxies」 page to see the available groups. A group marked select requires manual selection; url-test picks automatically based on test results; fallback prefers an available node; and load-balance distributes connections across multiple nodes according to its strategy. For a first connection, start with a manual selection group because its behavior is easier to control.

Do not select a node only inside a regional group; also check that the parent group actually references that regional group. For example, if 「Node Select」 currently points to 「Auto Select」 and you switch among lines in 「Hong Kong Nodes」, the final exit may still be determined by 「Auto Select」. Policy groups can be nested, so follow the selected indicators from the top level all the way down.

What kind of node should you choose first?

• Start with a geographically nearby node that delivers stable latency. Do not focus only on the smallest number in the list.
• Run three consecutive tests. Results of 68 ms, 71 ms, and 74 ms are usually more stable than 42 ms, 190 ms, and a timeout.
• Temporarily avoid lines explicitly marked with multipliers, experimental labels, or rate limits. Establish a repeatable baseline first.
• If several protocol nodes are available in the same region, start with the standard line recommended by the subscription, then compare real throughput and stability.

Node names are only labels supplied by the configuration provider; they do not independently prove a physical location or link quality. Judge the result using latency, connection logs, exit address, and actual access behavior. For services that require a persistent session, switching nodes frequently can also change the exit address, so reconnect and verify again after each switch.

Step 2: Test latency and read the results correctly

A latency test in the client is not an ICMP ping in the traditional sense. Clash or mihomo usually asks the specified node to request a test URL and records the time needed to establish the proxy connection and receive a response. Common test endpoints return HTTP 204, such as https://www.gstatic.com/generate_204 or https://cp.cloudflare.com/generate_204. The exact URL is determined by the configuration or client settings.

What the latency numbers mean

These ranges are for initial screening only. A 55 ms node may download slowly because of bandwidth congestion, while a 180 ms node may remain stable during sustained transfers. Latency mainly reflects short-connection response time; it is not the same as download speed, packet loss, or peak-hour capacity.

Avoid clicking repeatedly during batch tests. Testing dozens of nodes at once creates many connections immediately, and the router, DNS service, or remote servers may apply rate limits. Wait for the current batch to finish, then leave 10–20 seconds before running a second round. Three rounds of data are more useful than a single minimum value.

If every node times out, check the test path first

1. Open 「Logs」 and check whether a connection attempt appears after you start the latency test. If there are no logs at all, the core is usually not running or the interface is not connected to the controller port.
2. Check whether the local machine can resolve the test endpoint directly. A DNS failure can make a batch of otherwise healthy nodes appear to time out.
3. Replace the test URL with another reliable 204 endpoint and test again. An unreachable test site does not mean that every node has failed.
4. Make sure the local clock is accurate. TLS connections may fail during the handshake when the system time is significantly wrong.
5. Check the logs for timeout, connection refused, and network is unreachable, then handle the timeout, refused port, or unreachable route accordingly.

Step 3: Verify that traffic is actually using the proxy

Do not verify a proxy only by checking whether the system-proxy switch changed color or whether a latency number appears beside the node. A reliable check combines the exit address, Clash connection records, and the matched rule. When all three align, you can confirm that the request used the expected node.

Method 1: Compare direct and proxied exit addresses

1. Turn off System Proxy and TUN, visit a service that displays your public IP, and record the direct exit address.
2. Turn System Proxy back on and manually select the node you just tested.
3. Use a new private-browsing window to check the public IP again, avoiding cached page results.
4. Compare the two addresses, then find the request for the corresponding domain on Clash's 「Connections」 page.

With a load-balancing policy group, different connections may use different exits, so every lookup may not return the same address. With one manually selected node, the exit should usually remain relatively stable. If the public IP does not change, do not immediately assume failure: the current rule may set the lookup service to DIRECT. Check the outbound policy in the connection record first.

Method 2: Specify the proxy port explicitly in a terminal

Terminal programs usually do not automatically read the desktop system proxy. Use curl with an explicit local proxy to test “whether the terminal inherits system settings” separately from “whether the Clash port is working.” The commands below assume HTTP or mixed-port is 7890:

curl --proxy http://127.0.0.1:7890 https://api.ipify.org

In Windows PowerShell, use curl.exe to avoid older environments interpreting curl as another command:

curl.exe --proxy http://127.0.0.1:7890 https://api.ipify.org

If the configuration exposes a separate SOCKS5 port 7891, you can also resolve domain names through the proxy:

curl --proxy socks5h://127.0.0.1:7891 https://api.ipify.org

The h in socks5h means that hostname resolution is delegated to the SOCKS proxy. If the command returns a connection-refused error, check the actual listening port first instead of immediately switching nodes. Some newer configurations enable only mixed-port, so a separate socks-port may not exist.

Method 3: Inspect connection details and the rule chain

Open the client's 「Connections」 page, then refresh the target webpage. Request details usually show the destination host, source address, upload and download traffic, matched rule, and final policy chain. For example, a record might show:

example.com
Rule: DomainSuffix
Policy chain: Node Select → Hong Kong Nodes → HK-01
Network: TCP
Status: Active

DIRECT means the request was sent directly according to the rules; a specific node name means proxy egress; REJECT means the rule actively blocked it. If the target request is absent from the connection list, the traffic may not have entered Clash. Focus troubleshooting on the browser proxy, an in-app proxy, TUN routing, or the local firewall.

Recognize false connectivity: latency works, but the proxy does not

The most common sign of false connectivity is normal node latency and a running client, while the target application still uses a direct connection. The cause is usually the policy-group selection, rule matching, or application coverage—not the node itself. Check the following in order; it is more effective than repeatedly updating the subscription.

The top-level policy group did not select the node just tested

You may have selected HK-01 in the 「Hong Kong Nodes」 group, while the rules actually reference 「Node Select」, which still points to 「Auto Select」. HK-01 can pass latency tests without carrying application traffic. Return to the top-level group and follow the current selection down each level until the final node name matches your expectation.

The target domain is set to direct by the rules

Rule mode matches rules in order. DOMAIN-SUFFIX, GEOSITE, GEOIP, and the fallback MATCH can all change the exit. If the connection record shows DIRECT, the system proxy itself may already be working; the rules simply chose a direct route. Switch briefly to Global mode for comparison, then return to Rule mode and inspect rule order.

The browser or application bypasses the system proxy

Some browsers allow extensions or enterprise policies to define a separate proxy. Developer tools, game launchers, containers, and terminal programs may also open connections directly. System Proxy generally affects only applications that actively read the operating system's proxy settings. Configure such applications with a local HTTP/SOCKS address, or enable TUN after confirming system compatibility.

TUN is enabled, but routing or permissions are not ready

TUN mode uses a virtual network interface to capture a broader range of traffic. Windows, macOS, and Linux may require administrator privileges or a system extension. After enabling it, check the TUN status, virtual interface, and logs; an enabled switch alone does not prove that routes were written successfully. If the logs report interface-creation failure or insufficient permissions, fix permissions before testing nodes.

Existing connections were not rebuilt after switching nodes

Switching nodes does not force every existing TCP, QUIC, or long-lived connection to migrate immediately. Browser tabs, video clients, and messaging apps may continue using old connections. After switching, close the relevant connection and reload the page; if necessary, quit and reopen the application. Use a new private window when testing webpages to reduce interference from caches, Service Workers, and persistent connections.

IPv4 and IPv6 took different paths

A domain may return both A and AAAA records. If the application chooses IPv6 while the current proxy or TUN route covers only IPv4, some requests may go direct and others through the proxy. The connections page and logs can show which address family each request used. Do not infer the path of all traffic from a single public-IP page.

Build a repeatable first-connection checklist

After completing one successful connection, standardize the troubleshooting steps. Following the same order after updating a subscription, changing networks, or switching clients makes it easier to distinguish configuration, node, and application-integration issues.

1. Select the current subscription profile and confirm that mihomo or another compatible core is running.
2. Stay in Rule mode and enable only System Proxy; do not enable TUN at the same time.
3. Select a specific node in the top-level manual policy group.
4. Test three times at 10–20-second intervals, recording latency and any timeouts.
5. Open the target page while watching 「Connections」 and 「Logs」 for the corresponding request.
6. Check the matched rule, policy chain, and final node name.
7. Compare the direct and proxied exit addresses, then explicitly use 127.0.0.1:7890 in a terminal for an independent check.
8. After the basic path works, enable Auto Select, Fallback, or TUN.

Choosing a node, testing latency, and verifying the proxy are three separate steps. Node selection answers “who should be used,” latency testing answers “can the probe pass,” and the exit address plus connection record answer “where did the actual traffic go.” Keeping these steps separate prevents one green latency number from being mistaken for a complete connection result.