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

1. Check Your Config, Core, and Traffic Entry Point

Successfully importing a subscription only means the client received and parsed the config. It does not mean your traffic is going through a node. A proxied request typically follows four steps: the app sends it to a local entry point, mihomo selects a policy based on its rules, the policy group picks a node, and the node connects to the destination. Troubleshoot each link in this chain instead of repeatedly updating the subscription.

This guide focuses on desktop clients that use the mihomo core. Button locations vary by client, so start by finding the Config, Proxies, Connections, and Logs sections, then check the system proxy or TUN status. Android usually routes traffic through VpnService, so desktop system proxy steps do not apply.

Four Checks Before You Test

1. Config is active: Seeing a subscription name is not enough; confirm it is the currently selected config. “Downloaded” and “active” are different states.
2. Core is running: Check that the logs do not repeatedly report config parsing errors, port conflicts, or process exits. If a protocol is unsupported, first confirm which core the client is using.
3. Use rule mode: For your first test, select Rule or rule and note the current policy group selection. Avoid changing rules and DNS at the same time.
4. Use just one traffic interception method: On desktop, close other proxy apps and VPNs, then test the system proxy by itself. Test TUN only if you need to route apps that ignore system proxy settings.

2. Choose a Node: Check the Active Policy Chain

Cards on the Proxies page may represent nodes or policy groups. A manual select group uses the option you choose; an automatic url-test group selects based on test results and tolerance; a fallback group typically picks an available option in config order. A region-labeled option alone does not prove that your traffic is using that exit.

For example, a rule may send a destination to a “Web” group, which then selects “Auto,” before the request reaches a node. Changing a different “Manual” group may not affect that request. Trace the policy chain in the connection details rather than relying on the highlighted card on the Proxies page.

Steps for Your First Node Selection

1. Open the client’s Proxies page and find the policy group used for your destination. If you are not sure which one it is, note the name of the main selection group first.
2. In a group that allows manual selection, choose a clearly named node that passes its test. Avoid switching multiple nested groups at once.
3. Retry the destination, then check the rule, policy group, and final node on the Connections page.
4. To try another node, change only that selection and repeat the same test, keeping the destination URL and network unchanged.

Region names are labels supplied by the service provider; they do not prove physical distance or the actual exit location. You can start with a geographically closer region as a candidate, but base your choice on connection success, repeated test results, and access to the services you need. An expired subscription, exhausted data allowance, or invalid server authentication can also make multiple nodes unavailable at once.

3. Latency Tests: What the Millisecond Reading Tells You

A typical client latency test asks the core to request a test URL through a specified node, then reports the time taken or a failure. It is usually not an ICMP ping or a download speed test. Whether the test includes connection setup, reuses a connection, or how it determines success depends on the core and config. Results from different test URLs or clients should not be compared directly.

Repeat Three Times with the Same Destination

Run a test about every 10 seconds and record three consecutive results. These are examples, not measurements from this site: Node A: 82, 88, and 85 ms; Node B: 48 ms, 760 ms, and timeout. For a first connection, Node A is the better choice for checking stability rather than ranking by Node B’s lowest reading alone. Test large-file throughput, video buffering, and gaming over UDP separately.

If every node times out, first check which test URL the client uses. If a probe site is unreachable, healthy nodes may still show as failed. In the client’s test settings, try another reputable HTTPS URL that returns a lightweight response for comparison. Do not replace your entire subscription just because a test failed.

4. Verify the System Proxy: Test the Local Port Directly

A desktop system proxy tells apps that follow system settings to use a local proxy, but it does not automatically cover every program. Command-line tools, browsers with their own proxy settings, some games, and UDP apps may use other routes. Check the HTTP or mixed port shown in the client, then test it explicitly to separate node issues from system proxy routing issues.

Check the Port and System Settings

• Windows 11: Go to Settings → Network & internet → Proxy and check the manual proxy address and port. If the client uses a setup script, check that setting too.
• macOS: Go to System Settings → Network → your current network connection → Details → Proxies, then check the web proxy or secure web proxy settings.
• Client: Check the local listening port. The example below uses 7890; run the command as written only if your actual HTTP or mixed port uses that value.

The local proxy address is usually 127.0.0.1. If your config exposes only a SOCKS port, do not use the HTTP proxy command below as-is. Select the correct protocol or use a mixed port provided by the client. You do not need to enable “Allow LAN” to test from your own machine.

# macOS / Linux: explicitly use the local HTTP or mixed port
curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 --verbose --output /dev/null https://example.com/

# Windows PowerShell: use curl.exe to avoid command alias differences in older environments
curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 --verbose --output NUL https://example.com/

--connect-timeout 10 limits the time spent establishing a connection, while --max-time 20 limits the entire request. The example destination is only for a connectivity check; it cannot tell you whether every site you use is reachable. --proxy only specifies the entry point into the core. Whether the request goes through a remote node still depends on the current mode and rules.

• Connection to the local port is refused: Check that the core is running, the port is correct, and the port supports HTTP proxy connections.
• CONNECT 200 appears: The proxy accepted the tunnel request. Check the TLS handshake and final HTTP response too; this line alone does not confirm the site loaded successfully.
• Explicit proxy works, but the browser does not: Check the system proxy, browser extensions, browser-specific proxy settings, and existing connections before changing your subscription.

5. Connections Panel: Confirm the Rule and Final Exit

A page loading in your browser does not prove it went through a remote proxy. It may have matched DIRECT, or its traffic may never have reached the core. A useful check needs three pieces of evidence: a new request in the Connections panel, the expected rule match, and a policy chain that ends at the expected node.

Trace One Request, Not Overall Traffic

1. Open the Connections page, note the current time, then open a new browser window and visit the destination you want to check.
2. Filter connections by the destination domain. If the connection is brief, open the logs first; some clients do not retain closed connections.
3. Expand the details and check the destination domain or IP, matched rule, policy chain, and bytes sent and received. Whether the process name appears depends on the platform and permissions; it is not required evidence.
4. If the connection shows DIRECT, first check whether that matches your rules. In rule mode, local services and some websites going direct is normal.
5. After switching nodes, close the old tab or end the corresponding connection, then send a new request. Existing long-lived TCP connections usually do not move to another route automatically when you change policies.

An IP lookup can provide supporting evidence: use the same lookup service to compare direct access with the expected proxy route, and confirm in the Connections panel that the lookup matched the proxy policy. Do not compare region labels from two different websites; database differences and IPv4/IPv6 can lead to misleading results. Even a changed exit IP proves only the route used for that lookup, not that every app is being routed through the proxy.

6. TUN and Common Issues: Change One Variable at a Time

Consider TUN if an explicit proxy test succeeds but a program still never appears in the Connections panel. TUN routes traffic through a virtual network interface and related routes, making it useful for apps that ignore system proxy settings. It still uses the core’s rules and policy groups; it does not mean every request will go through a remote node. Enabling it may require administrator privileges, service mode, or driver support. Follow the client’s prompts.

Use Global Mode for a Brief Comparison, Then Restore Rule Mode

If the destination fails in rule mode, briefly switch to Global mode, explicitly select the same working node in the GLOBAL group, and establish a new connection. If Global mode works but rule mode does not, focus on the rule matched by that destination and its policy. If both fail, keep checking the node and destination service. Global mode is only a diagnostic comparison; it will not route apps that never reach the core.

Do not switch nodes, change DNS, enable TUN, and update rules all at once; you will not know which change affected the result. For each step, record the time, destination, mode, entry port, node, and error message to make the issue easier to reproduce. Log messages such as timeout, connection refused, and authentication errors point to different parts of the connection. Troubleshoot the specific error instead of treating them all as “network unavailable.”

7. How to Tell Your First Connection Is Working

• The current config is active, the mihomo core is running, and the local proxy port accepts connections.
• The candidate node passes repeated tests to the same destination without persistent timeouts.
• A new request from the actual app appears in the Connections panel and matches the expected rule.
• Requests that need a proxy reach the expected node; requests meant to go direct follow the expected DIRECT route.
• The service you need works. Switch back to rule mode and verify again instead of relying only on a Global mode test.

These five checks establish an evidence chain from the local entry point to the final exit. If a connection drops later, follow the same sequence to find what changed before adjusting settings. For complete steps on importing subscriptions and routing system traffic, see Getting Started. For config concepts and options, see the full documentation.