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

1. After importing your subscription, make sure the configuration is enabled

A successful subscription import only means the client received the configuration. To route browser traffic through the proxy, you also need to enable the configuration, choose a proxy group node, and route traffic into the client. For your first connection, start by testing the system proxy with your browser and leave TUN mode off. This makes it easier to pinpoint problems without two routing methods interfering with each other.

Depending on the client, the configuration page may be called “Config,” “Subscriptions,” or “Profiles.” Open the relevant page and check all four items below—don’t rely on an “Update successful” message alone.

1. Active configuration: The imported profile is selected or enabled, not just saved in the list.
2. Last updated: Run an update and check for authentication failures, download timeouts, or parsing errors.
3. Core status: Clash or mihomo is running, with no configuration load failures, port conflicts, or similar errors in the logs.
4. Proxy group contents: Nodes or loaded proxy providers are visible; the group isn’t empty or limited to DIRECT.

If the configuration reports unsupported fields, first check which core the subscription requires. Clash and mihomo don’t support exactly the same configuration features. Toggling the system proxy won’t fix syntax or protocol compatibility issues; get the core to load the configuration successfully first.

2. Choose a node in a proxy group and test its latency

Open the client’s “Proxies” page and find the default proxy group. Group names are defined by the subscription; yours might be “Node Selection” or something else. First check which group the rules ultimately use, then choose a node in that group. If groups are nested, follow the chain until you identify the final egress node.

What latency tests can tell you

A client’s latency test typically sends a request to a specified test URL through the node; it isn’t a simple ICMP ping. Results depend on the test address, timeout settings, DNS, and current network conditions. Use the test to find nodes that are reachable right now—not to estimate download speeds or guarantee access to every website.

• Test two or three nodes first, using the same test address and timeout settings where possible.
• Run each test three times to check consistency instead of choosing a node based on one unusually low result.
• Check that regular web browsing works before testing large downloads to avoid unnecessary data use.

For example, one node might return 85, 92, and 88 ms, while another returns 45 ms, times out, and then returns 310 ms. The first node has a higher best latency but is more consistent, making it a better candidate for your initial connection test. These figures illustrate how to assess results; they aren’t measurements from a specific node.

Handling timeouts and automatic selection

If one node times out, try another in the same group. If every node times out, check your local network, subscription status, system clock, and core logs. The test URL itself may also be unreachable, so verify with the actual website you want to visit.

With a url-test group, the current egress node is determined by test results. A fallback group typically selects a node based on availability and configuration order, while a load-balance group may route different connections through different nodes. For a repeatable first check, temporarily pin a node in a manual selection group, then restore automatic selection when you’re done.

3. Use rule mode and enable the system proxy

For your first desktop test, use rule mode. It matches requests against rules from top to bottom, sending them to a proxy group or matching DIRECT or REJECT. The system proxy routes requests from apps that honor the system proxy settings to the client’s local listening port. These serve different purposes, so check each one separately.

“Global mode” doesn’t mean all system traffic is captured. Connections that never reach the core won’t be proxied just because you switched to global mode. Browser proxy extensions, app-specific proxy settings, and the system proxy can also override one another. Disable any additional proxy extensions while troubleshooting.

Check the local address and listening port

Look for the HTTP or mixed port in the client settings. A common example is 127.0.0.1:7890, but use the value from your current configuration. mixed-port accepts both HTTP and SOCKS proxy requests; external-controller is a control interface, not a browser proxy port.

• Windows 11: Go to Settings → Network & internet → Proxy → Manual proxy setup and check the address and port set by the client. For your first test, use the system proxy toggle in the client.
• macOS: Go to System Settings → Network → your current network service → Details → Proxies, and check which proxy settings are active. Menu names may vary slightly by macOS version.

You don’t need to enable LAN access or expose the controller interface just to connect from the local machine. If the listening port is already in use, close the other proxy app using it, then restart your client.

4. Use connection logs to verify the rule and node in use

With the system proxy enabled, open the client’s “Connections” page, then open a new browser tab and visit the site you want to check. Look for the request you just made rather than relying on a change in total traffic. Some short-lived connections disappear quickly, so check the log page as well.

1. Check the destination: Does the domain or destination address match the site you just visited?
2. Check the matched rule: Was it a domain rule, rule set, regional rule, or the final MATCH rule?
3. Check the policy chain: Does it show DIRECT, or the expected proxy group and its final node?
4. Check the traffic: Was data sent and received? Are connection failures or timeouts recurring?

If the request matches DIRECT, it reached the core but was routed directly. That doesn’t mean the system proxy failed. If there’s no connection record at all, check whether the app honors the system proxy, whether the page came from cache, and whether the client hides some connections. A mihomo configuration may also set a log level or suppress certain records, so don’t draw conclusions from one empty page alone.

If the request appears but uses the wrong node, check for nested proxy groups, load balancing, or a client that restored your previous selection. Pinning one node temporarily is easier to troubleshoot than changing rules, DNS, and TUN settings all at once.

5. Compare public IPs to confirm the proxy is working

Connection logs show how a request was routed; your public IP shows which address external services can see. Checking both gives you a more reliable answer. First, with the system proxy and TUN off, note your direct-connection IP. Then enable the system proxy, pin a node, and check again using the same IP lookup service. Make sure no other VPN is running, or your direct-connection baseline may already be going through another tunnel.

In rule mode, the IP lookup service itself may be set to bypass the proxy. If your public IP doesn’t change, check the matched rule for that request. To rule out routing rules, you can briefly switch to global mode and set the global selector to your chosen node. Return to rule mode after the test.

Use the command line to distinguish a local proxy from system proxy routing

The examples below use mixed port 7890. The first command explicitly bypasses the proxy; the second explicitly connects through the local HTTP proxy. Before running them, turn off TUN and make sure no other VPN is routing traffic. Replace the port with the one your client actually listens on. The lookup service will receive the request and its source address.

# macOS / Linux: direct request
curl --noproxy "*" --max-time 15 https://api.ipify.org

# macOS / Linux: request through the local proxy
curl --noproxy "" --proxy http://127.0.0.1:7890 --max-time 15 https://api.ipify.org

In Windows PowerShell, use curl.exe explicitly to avoid environments where curl maps to a different command. Before testing through the proxy, you can temporarily clear the current terminal’s NO_PROXY environment variable, then run:

Remove-Item Env:NO_PROXY -ErrorAction SilentlyContinue
curl.exe --proxy http://127.0.0.1:7890 --max-time 15 https://api.ipify.org

A successful explicit proxy request confirms that the local port and that request path are working, but it doesn’t prove the system proxy is configured correctly. Go back to your browser and check the logs to confirm its requests are reaching the core.

Geolocation databases can lag behind changes, and a node name doesn’t guarantee the actual egress city. IPv4 and IPv6 results may also differ. Don’t rely on a flag icon alone; note the test time, address type, matched policy, and egress address. Even if the IP is the same, check the rules and policy chain before mistaking a shared egress or different address family for a connection failure.

6. Check TUN if your browser works but other apps don’t

The system proxy doesn’t transparently capture all traffic. Some games, command-line tools, and apps with their own network stacks don’t read it, and a standard HTTP system proxy alone won’t route UDP traffic. Check whether the app supports its own HTTP or SOCKS proxy first, then decide whether to use the client’s TUN mode.

TUN uses a virtual network interface and routing settings to send matching traffic to the core. Desktop clients may require administrator privileges, service mode, or network extension approval; Android clients typically use the system VPN interface. Permissions and menu options depend on the client and operating system, so don’t assume steps from one platform apply to another.

• Verify that the system proxy works before testing TUN on its own. This avoids troubleshooting node availability and routing problems at the same time.
• Check for conflicts with other VPNs, virtual machine networks, or corporate network policies.
• After enabling TUN, check the target app’s connection records again. “TUN is running” alone doesn’t prove that traffic is being proxied.
• If you can’t reach devices on your local network, check route exclusions and direct rules instead of disabling the firewall.

If IP addresses are reachable but domain names won’t resolve, check the DNS configuration and core resolution logs. DNS behavior with the system proxy, DNS interception in TUN mode, and fake-IP mapping are different things. Don’t copy an entire DNS configuration as a first step. Keep the working configuration and identify exactly which domain or DNS request is failing.

7. Common connection problems and what to check first

Change one variable at a time: node, mode, port, or routing method. Record what happens before and after each change to identify what fixed the problem. If you see a certificate error, first check the system clock and the website’s certificate details. Don’t bypass TLS verification to test your first connection.

8. Final checklist for your first connection

• The current subscription is enabled, and the core isn’t reporting persistent errors.
• You know the default proxy group and final node—not just the latency result.
• The system proxy address and listening port match.
• The destination request appears in the connection log and matches the expected policy.
• The public IP agrees with the log; direct and proxied rules have been distinguished.
• Restore rule mode for everyday use and undo temporary test changes.
• Turn off the system proxy before exiting the client, or make sure the client restores the system settings correctly.

Once these checks pass, you’ve verified the full path from subscription import to real-world access. If a particular site or app has problems later, start by checking its rules, DNS, and connection records—you don’t need to reinstall the client. For basic setup, see the system proxy setup guide. For targeted troubleshooting, see the connection troubleshooting guide.