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

Before you start: make sure the configuration is loaded and the port is available

For a first connection, break the problem into three layers: whether the configuration loaded correctly, whether the node can establish a connection, and whether application traffic is actually entering Clash. Seeing “Running” on the client’s main screen is not enough. It usually only means the core process is active; it does not mean the nodes in the subscription are usable or that the browser is using the local proxy port.

After opening the client, go to the “Profiles” page and confirm that the subscription you just imported is selected. The profile should show an update time, file name, or subscription name. If the page reports a parse error, the profile is empty, or the core exits immediately after switching profiles, fix the import issue before testing nodes.

Check the local listening ports

Common configurations use HTTP port 7890 and SOCKS5 port 7891. Newer configurations may use mixed-port: 7890 to accept both HTTP and SOCKS5 traffic on one port. The exact values come from the configuration and client settings. There is no need to force a particular port, but the port entered in the system proxy settings must match the port Clash is actually listening on.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090

In graphical clients, the port is usually under “Settings” → “General” → “Port”. If 7890 is already occupied by another proxy program, the client may report bind failed, address already in use, or a startup failure. Quit the program using that port, or change Clash to 7892, then enable the system proxy again.

Step 1: Choose a suitable node in the proxy group

After importing a subscription, nodes usually do not appear directly on the home screen. They are listed in proxy groups on the “Proxies” page. Common group names include “Node Selection”, “Proxy”, and “Manual Selection”. First find the selector group that handles the main traffic exit, then choose a node from that group. Do not click randomly in an overview containing entries such as DIRECT and REJECT.

Start with the manual selection group

1. Go to “Proxies” → “Node Selection” and confirm that the current mode is “Rule”.
2. Expand the main proxy group and choose a node in a relatively nearby region with a clear, informative name.
3. If other proxy groups reference “Node Selection”, leave them pointing to that group; there is no need to configure each group separately.
4. Return to the home screen, confirm that the core is running, then enable “System Proxy”.

For the first test, manually pin one node. This makes it clear which exit is associated with the latency tests, IP lookup, and connection logs that follow. If you start with a url-test, automatic selection, or load-balancing group, the client may switch nodes during testing, making the results inconsistent.

Use node names only as filtering clues

Regions, multipliers, and dedicated-line labels in node names are defined by the subscription provider and do not represent real-time quality. Actual performance depends mainly on the network path from your device to the server, server load, protocol settings, and the destination website’s route. A nearby node usually has lower round-trip latency, but it is not guaranteed to deliver the highest download speed; a low-multiplier node is not necessarily more stable.

If a proxy group contains only DIRECT or the node list is completely empty, the problem is usually not that no node was selected. The subscription content may not have been converted successfully into a configuration supported by the current core. Return to the “Profiles” page to update the subscription, check the error log, and confirm that the mihomo core version used by the client supports the proxy protocols and fields in the configuration.

Step 2: Test latency and determine whether the node works

After choosing a node, click the latency-test button on the right side of the proxy group. Depending on the client, it may appear as a speed-test icon, a lightning-bolt icon, or “Test”. The test URL is usually a very small HTTP or HTTPS page. The client records how long it takes to establish the connection and receive a response, with the result shown in milliseconds.

How to interpret latency results

• 50–150 ms: Common for nearby nodes in good condition; web interactions are usually smooth.
• 150–300 ms: Still suitable for normal browsing and downloads, though real-time interactions may feel slower.
• 300–800 ms: May indicate a detour, congestion, or high node load; compare it with other nodes in the same region.
• Timeout: No valid response was received within the test period. Distinguish between an unreachable test URL, a failed node, and interference from the local network.

These ranges are troubleshooting references, not fixed pass thresholds. A result of 82 ms followed by 210 ms indicates an unstable route; three consecutive results of 86 ms, 91 ms, and 89 ms are more meaningful than a single low reading. For an initial shortlist, keep two or three nodes that succeed consistently with limited variation.

Normal latency does not mean every website will open

A latency test validates only the request path from your device to the node and then to the test URL. It does not test every destination website or measure large-file throughput. A node with 95 ms latency may still fail to reach a particular site because the rule selects DIRECT, the destination restricts access, DNS results are abnormal, or the node uses a different exit network.

Conversely, a Timeout does not necessarily mean the node has completely failed. The test URL may be restricted by the destination network, or the client’s timeout may be too short. Check the test URL and timeout value under “Settings” → “Latency Test”. A common timeout is 5000 ms. If all nodes produce results after changing the test URL, the original URL is the more likely problem—not the entire subscription.

If every node times out, check the local network first

If a dozen or more nodes all time out at the same time, changing nodes one by one is unlikely to help. Switch to another network, such as a phone hotspot instead of home Wi-Fi, and test again. If the hotspot works, the issue may be the router, broadband connection, or local network filtering. If both networks fail, check the subscription update time, system clock, core logs, and node protocol settings.

An incorrect computer clock can also cause a TLS handshake to fail. On Windows, go to “Settings” → “Time & language” → “Date & time”, enable automatic time setting, and sync immediately. On macOS, go to “System Settings” → “General” → “Date & Time” and confirm that automatic time setting is enabled. Restart the core after syncing instead of merely refreshing the proxy page.

Step 3: Confirm that traffic is actually using the proxy

Seeing latency for a node is only the beginning; you must also verify traffic routing. The most reliable check has three parts: System Proxy or TUN is enabled, the exit IP differs from the direct connection, and the Clash connection panel shows the requests just generated. Only when all three are true can you link “the node works” with “the application is using the proxy”.

Record the direct-connection exit IP first

1. Temporarily disable Clash “System Proxy” and “TUN Mode”.
2. Open a trusted IP lookup page in your browser and record your current public IP and region.
3. Close the page, restart Clash, and keep the node you selected earlier.
4. Open the lookup page again and compare the public IP, network provider, and region.

If the proxy exit IP differs from the direct IP and the region roughly matches the node’s exit location, the browser request has probably gone through the proxy. However, an IP lookup confirms only the exit used by that request; it does not prove that every application and protocol has been captured. Some browsers may also cache the page, so use a private window or force-refresh it before testing.

Verify the request path in the connection panel

Open the client’s “Connections” page, then visit a website that you have not opened before in the browser. The connection list should show a new domain, destination address, matched rule, proxy group, and actual node. A typical entry looks like this:

Host: example.com
Network: TCP
Rule: DomainSuffix
Chain: Node Selection → HK-01
Upload: 3.2 KB
Download: 18.7 KB

Chain or Chains indicates which node the proxy group ultimately selected. If the path shows “Node Selection → HK-01”, the request went through that node; if it shows DIRECT, the request connected directly according to the rules. DIRECT is normal in Rule mode: local-network addresses, sites in mainland China, or domains explicitly configured for direct access may be intended to bypass the proxy.

If the connection panel shows no new requests at all, the application is usually not using Clash. Check “Settings” → “System Proxy”, and verify that the system proxy address is 127.0.0.1 and its port matches Clash’s HTTP or mixed port. If the browser has a proxy extension installed, make sure it is not overriding the system settings or pointing to another port.

System Proxy and TUN coverage

System Proxy mainly affects applications that follow the operating system’s proxy settings, such as common browsers and some desktop software. Certain games, command-line programs, store apps, and UDP traffic do not automatically read the system proxy. To capture this traffic, enable TUN under “Settings” → “Network” → “TUN Mode”.

TUN creates a virtual network interface and passes more IP-layer traffic to mihomo. The first activation may require administrator privileges; Windows may also install or enable related network components. After enabling it, check the “Connections” panel again and confirm that connections from the target process appear. Do not also point the system proxy at another program by mistake, or HTTP requests and TUN traffic may produce two different sets of results.

Three common mistakes: it looks connected, but the real problem remains

Mistake 1: Looking only at the home-screen switch

“Running” on the home screen only means that the core started successfully. A complete status check includes at least: the configuration loaded successfully, latency tests returned results, System Proxy or TUN is enabled, and the connection panel shows requests. If any item is missing, the client may be running while webpages still connect directly or fail to load.

Mistake 2: Assuming the lowest latency means the highest speed

A latency test transfers very little data and mainly reflects response time. Download speed also depends on server bandwidth, route congestion, node load, per-connection limits, and the destination site’s performance. When two nodes measure 70 ms and 110 ms, the latter may still provide more consistent download throughput. For everyday use, watch webpage responsiveness, sustained connection stability, and actual transfer speed together.

Mistake 3: Assuming the node has failed because the exit IP did not change

In Rule mode, an IP lookup site may be configured as DIRECT, so it still shows your local exit. First open the “Connections” page and see which rule matched that domain. If the record shows DIRECT, temporarily switch to Global mode and test again. If the exit changes in Global mode, the node itself works; adjust the rules or select the correct proxy group.

Another possibility is that the browser has secure DNS, a standalone proxy extension, or an enterprise policy enabled. These can change DNS resolution or the proxy path. During troubleshooting, disable extra extensions, keep System Proxy as the only entry point, and inspect the connection panel. DNS resolution and the webpage’s TCP connection are separate stages; the location of the DNS server alone cannot prove whether all traffic is proxied.

A fixed troubleshooting order for first-connection failures

When webpages will not open, every latency test times out, or the exit IP does not change, a fixed sequence is faster than changing settings at random. Change only one variable at a time and send a new request after each change.

1. Configuration: Confirm that the subscription is selected, the update produced no parse errors, and the node list is not empty.
2. Core: Confirm that the status is Running and that the logs contain no port-conflict, invalid-field, or permission errors.
3. Node: Test one fixed node three times, then compare it with another node in the same region.
4. Ports: Verify that the mixed, HTTP, and SOCKS5 ports match the system proxy settings.
5. Application entry point: Test the browser through System Proxy first; consider TUN only for applications that do not read system proxy settings.
6. Rules: In the connection panel, check whether the request matched DIRECT, REJECT, or a proxy group.
7. Network: Retest through a phone hotspot to distinguish client configuration issues from problems on the current local network.
8. Logs: Use specific messages such as timeout, connection refused, and TLS handshake to identify the failing stage.

For example, normal node latency, a direct-looking IP result, and no connection-panel record point first to an inactive system proxy—not a node problem. If the connection panel has a record whose path points to the selected node but the request shows timeout, continue checking the node and destination network. If the record clearly shows REJECT, inspect the rules instead of changing ports.

Recommended everyday settings after verification

Once the connection works, keep the mode set to Rule so the configuration can choose DIRECT or a proxy based on domains, IPs, and rule sets. You can keep the main proxy group pinned to a stable node or switch to a url-test automatic-selection group. Before using an automatic group, confirm that every node in it can connect independently; automatic testing can choose only among usable nodes and cannot repair a broken configuration.

• For System Proxy users, keep the local listening address at 127.0.0.1. Turn off Allow LAN when you do not need to share the proxy over your local network.
• Enable TUN only when you need games, command-line tools, or software that does not read system proxy settings, and confirm that the connection panel recognizes its traffic.
• If node names change after a subscription update, check again that the manual proxy group still points to a valid node.
• When a webpage behaves unexpectedly, check the connection record and matched rule first instead of deleting the entire configuration.
• Keep one backup node that has passed three latency tests and a real browsing check for quick comparison.

The key to a first connection is not turning on every switch. Build a clear verification chain: select one specific node, use a latency test to confirm basic connectivity, then verify the request path through the exit IP and connection panel. Once these three steps are complete, you can tell whether later slowdowns, a single inaccessible website, or an application bypassing the proxy is caused by the node, the rules, or the traffic entry point.