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

Confirm Your Subscription Is Loaded Before Connecting

When using Clash for the first time, split the process into four separate checks: the configuration works, a node works, the correct policy group is selected, and system traffic is connected. A client showing “Running” only means the core process has started; it does not mean your browser is accessing the internet through the proxy.

Check the Configuration Name and Update Time

The steps below use the common interface of Clash Verge Rev 2.4.x with mihomo 1.19.x as an example. Button names may vary slightly between clients, but the Configuration, Proxy, Connections, and Settings pages generally serve the same purposes.

1. Open the “Subscription” or “Configuration” page and confirm that the configuration you just imported appears in the list.
2. Click the configuration card to make it the active configuration. Downloading it locally is not enough; if it is not selected, the core will not use its nodes or rules.
3. Check the update time. If it shows a date from several weeks ago, run “Update Subscription” once.
4. Open the “Proxy” page and confirm that policy groups and node names are visible instead of an empty list.

Start the Core and Check for Errors

Go to “Settings” → “Clash Settings” or “Settings” → “Core Settings” and confirm that mihomo is selected. After a successful start, the logs usually show configuration loading, listening ports, and rule initialization. Common local values are HTTP port 7890, SOCKS5 port 7891, or the combined setting mixed-port: 7890.

If the log shows address already in use, another program is using the port. A YAML parsing error indicates a configuration format problem. Do not continue testing nodes until the core is running reliably.

Choose a Node in the Correct Policy Group

Clash’s “Proxy” page often shows both nodes and policy groups. A node is a specific route; a policy group decides which route handles a category of traffic. During a first connection, the common mistake is not failing to choose a node, but choosing one in a group that does not handle the traffic being tested.

Identify the Policy Group Type First

Open a group named “Node Selection,” “Manual Selection,” or PROXY, then choose a node with a clearly labeled region, such as “Japan 01” or “Singapore 02.” Next, check whether the page’s top-level or main policy group references that group. If the main group is still set to DIRECT, lighting up a node card will not change your exit IP.

Use Rule Mode for the First Test

Find the proxy mode under “Settings” → “System Settings” or on the client home page, then choose “Rule.” Rule mode matches traffic from top to bottom according to the configuration: local networks and common mainland China addresses usually connect directly, destinations requiring a proxy go to a policy group, and MATCH handles anything unmatched.

• Rule mode: Best for everyday use and for verifying that subscription routing works correctly.
• Global mode: Sends most traffic through the global policy group and is useful for briefly ruling out rule-related problems.
• Direct mode: Bypasses the proxy. If selected by mistake, an IP check will continue to show your local exit.

When Testing Latency, Check Delay, Timeouts, and Stability

Latency tests in the client are usually not ICMP ping tests. Clash accesses a test URL through the selected node and records the time needed to establish a connection, negotiate TLS, or receive a response. This is closer to proxy reachability, but it is not the same as download speed.

Run One Comparable Batch Test

1. Open the “Proxy” page and find the policy group currently in use.
2. Click the speed-test button in the group’s upper-right corner, wait for all nodes to finish, and avoid clicking repeatedly.
3. Record the latency, the number of timed-out nodes, and how each node’s results change across three consecutive tests.
4. Manually choose a node with reasonable latency and limited variation, then test it in a browser.

For example, Node A returns 86, 91, and 89 ms across three tests, while Node B returns 52, 420, and 77 ms. Although Node B has the lower minimum, Node A is usually the better choice for a first connection test. Stability is more useful than one unusually low latency result.

Why a Normal Latency Result Can Still Mean Slow Browsing

Latency reflects the response time of a short request only. Available bandwidth, peak-hour congestion, destination-side throttling, packet loss, and device performance all affect the real experience. A 65 ms node may have limited throughput, while a 150 ms node may transfer large files more consistently.

Also check whether the test address is reachable. mihomo configurations often use https://www.gstatic.com/generate_204 for health checks. If the test address itself is blocked on your current network, every node may time out; that does not necessarily mean all proxy routes have failed.

Enable the System Proxy and Send Browser Traffic through Clash

After choosing a node, you still need to send application traffic to Clash’s local listening port. Standard browsers can usually connect through the system proxy. Games, command-line tools, store apps, and some UDP-based software may ignore it and require TUN mode or their own proxy settings.

Checking the System Proxy on Windows and macOS

Open “System Proxy” on the client home page. In Windows 11, go to “Settings” → “Network & internet” → “Proxy” to check the manual proxy status. The common address is 127.0.0.1 with port 7890. If the client uses another mixed-port, the port in system settings must match it.

On macOS, go to “System Settings” → “Network” → “Wi-Fi” → “Details” → “Proxies” and check Web Proxy and Secure Web Proxy. The client usually writes these settings automatically; avoid using another proxy tool to edit them while the client is running.

Close Potentially Conflicting Network Tools First

• Quit other proxy clients using 7890, 7891, or the same control port.
• Pause proxy extensions configured separately in the browser to prevent requests from being sent to another address.
• Make sure the system clock is accurate. A large time discrepancy can cause HTTPS certificate validation to fail.
• For the initial verification, temporarily disable custom DNS or proxy-chain settings inside the application to reduce variables.

Verify the Proxy with Your Exit IP

Being able to open a webpage does not prove that the request used the proxy. The most direct check is to query your public IP before and after enabling Clash, then compare the address, ISP, and region. Run both tests in the same browser and network environment.

Browser Verification Steps

1. Temporarily disable the client’s “System Proxy,” open an IP lookup page, and record the first two segments of your original public IP and its region.
2. Enable the system proxy again, confirm the mode is “Rule” or “Global,” and select the node that passed the earlier test.
3. Open a new private window and visit two different IP lookup pages.
4. If both pages show the proxy node’s region and the IP differs from the original exit, the browser proxy is most likely working.
5. Return to Clash’s “Connections” page, refresh the lookup page, and check for the corresponding domain, destination address, policy group, and node name.

For example, the exit IP is 203.0.113.24 with the proxy off and changes to 198.51.100.76 after it is enabled. If the connection log also shows the request matching PROXY and being sent through “Singapore 02,” browser traffic has entered Clash. These addresses are provided only to illustrate the verification method.

Compare Direct and Proxied Requests from the Command Line

Windows 11, macOS, and common Linux distributions usually include curl. If your local mixed port is 7890, run these commands separately:

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

The first command uses the current system and terminal environment, while the second explicitly specifies Clash’s HTTP proxy. Different IP results show that the local proxy port can forward requests. If the browser still shows the original IP, check the system proxy or the browser’s own settings instead of repeatedly changing nodes.

Check the Connection Log as Well

Open the client’s “Connections” page. A normal request usually shows the hostname, source address, upload and download totals, matched rule, policy chain, and final node. Click a connection to confirm whether it used DIRECT, REJECT, or a proxy node.

If the IP lookup request matches DIRECT, switch to Global mode temporarily for comparison. If the exit changes in Global mode, the node and system proxy work, so the issue is in the rules or policy group. If there is still no connection record in Global mode, traffic is not entering the current Clash instance at all.

Enable TUN Mode Only When the System Proxy Fails

TUN mode lets mihomo create a virtual network interface and receive traffic at the network layer. It is useful for programs that ignore the system proxy and for more UDP scenarios. You do not need to enable everything during the first connection: verify the regular system proxy first, then enable TUN as needed for specific applications.

TUN Enablement Order

1. Go to “Settings” → “Clash Settings” → “TUN Mode.”
2. Follow the client’s instructions to install or enable service mode. On Windows, administrator permission is usually required for the initial installation.
3. After enabling TUN, wait for the virtual interface to appear, then open an IP lookup page.
4. Check “Connections” and “Logs” to confirm that requests from the target application are recorded.
5. If the network becomes unstable, disable TUN first, confirm that the system network recovers, then inspect DNS and routing settings.

mihomo TUN commonly works with DNS hijacking, auto-route, and strict-route settings. Different clients package these options as toggles. For first-time users, avoid changing the interface name, MTU, routing table, and DNS listen port together when the configuration source is unfamiliar.

How to Tell Whether DNS Is the Problem

If you can reach a specific IP but cannot open the site by domain name, or the logs repeatedly show DNS resolution failures, DNS may be the issue. In Fake-IP mode, the DNS module first returns a mapped address, then the core matches rules using the original domain. A mapped address in the 198.18.0.0/16 range does not mean the target website is actually hosted on that subnet.

Run the client’s DNS cleanup function once, or restart the core, then test again. On Windows, you can also run ipconfig /flushdns in a terminal to clear the system cache. If only one domain fails, inspect its matched rule and DNS response in the connection log instead of switching all traffic to Global mode immediately.

Quick Diagnostic Table for a Failed First Connection

Minimum Verification Standard for a Working Connection

• The current configuration is selected, and the update completed without a format error.
• The mihomo core is running steadily and the local listening port is established.
• At least one node passes three consecutive tests without timing out, with acceptable latency variation.
• The policy group actually handling traffic has selected this node, not DIRECT.
• The browser request appears on the “Connections” page and shows the final node used.
• The results from two independent IP lookup pages differ from the result with the proxy disabled.

Once these six checks pass, the first connection is complete. You can then move on to advanced settings such as automatic speed tests, finer policy groups, rule changes, automatic subscription updates, and persistent TUN mode. Change one variable at a time, and verify each result with the connection log and exit IP.