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

1. Before Connecting: Check the Config, Core, and Traffic Entry Point

Successfully importing a subscription only confirms that the client retrieved the config; it doesn't mean traffic has reached the mihomo core. Break the initial verification into four steps: confirm the config is loaded, identify the traffic entry point, choose a node in a proxy group, and check the actual outbound route for the target connection. Avoid changing DNS, TUN, and rules all at once, or it will be hard to tell which change caused a problem.

1. Check the active config. Open the client's Configuration or Profiles page and make sure the newly imported subscription is selected. A config that downloaded successfully but hasn't been activated won't replace the rules and nodes currently in use.
2. Check that the core is running. Look in the startup log for config parsing errors, port conflicts, or messages showing that the process exited. If YAML parsing fails, fix the config before trying different nodes.
3. Choose a rule mode. Start with Rule mode for the first connection. Global mode is useful for a temporary comparison; Direct mode isn't a good starting point for testing proxy nodes.
4. Note the actual port. Check the HTTP or mixed port in the client settings or active config. For example, mixed-port: 7890 means the entry point accepts both HTTP and SOCKS proxy connections. Use the value in your current config.

Choosing Between System Proxy and TUN

On desktop, start by testing browser requests through the system proxy; this is usually easier to troubleshoot. When the system proxy is enabled, only apps that honor the system proxy settings use that entry point. Some command-line tools, games, and apps with their own network settings won't follow it. TUN mode uses a virtual network interface to receive routed IP traffic. Its coverage also depends on routes, exclusions, and platform permissions, so enabling the toggle alone doesn't guarantee that every connection reaches the core.

For the first test, don't run two clients that both take over the system proxy or add proxy routes. Android and iOS commonly use the system VPN permission flow; confirm that permission is granted and the connection stays enabled. Desktop system proxy steps don't apply directly.

2. Choose a Proxy Group: Find the Node That Actually Handles Traffic

On the Proxy → Proxy Groups page, a card may represent a single node or another proxy group. A rule first selects a proxy group, and that group then determines the final node. Changing a node in a group that the target rule doesn't use won't affect that website.

Use a fixed node for the initial test

1. Find the proxy group referenced by the target website's rule. If you're not sure which rule applies, visit the site once and look it up in the connection records.
2. If the group supports manual selection, choose a specific node. This prevents automatic switching from making test results hard to compare.
3. If the selected member is a nested group such as “Auto,” open it and confirm the node actually in use; don't stop at the outer group name.
4. After switching nodes, establish a new test connection. Existing long-lived TCP connections, HTTP/2 connections, or QUIC sessions may not move to the new node immediately.

DIRECT means a direct connection, not a specially named proxy node. REJECT means the connection is blocked. If the target rule ultimately routes through either of these, a low latency reading won't make the request use a proxy as expected.

3. Latency Tests: Readings, Timeouts, and Throughput

The node latency shown in a client is usually more than a simple ICMP ping. mihomo's URL tests access a configured test URL through the node, so results depend on establishing the node connection, completing the protocol handshake, the test site's response, and local network conditions. The exact timing method also depends on how the client runs the test, so compare results only under the same conditions.

Compare results only under consistent test conditions

• Use the same URL: Check the url in the active config. A commonly used test URL is https://www.gstatic.com/generate_204. Results from different test targets aren't directly comparable.
• Use the same network: Run a test round on the same Wi-Fi or wired network; don't mix in results from a cellular connection.
• Test more than once: Run three consecutive tests and keep each result. For example, if one group returns 82, 91, and 86 ms while another returns 65, 460, and a timeout, the first is a better candidate for checking stability. These are example readings, not results measured by this site.
• Distinguish one-off tests from periodic probes: Clicking the test button gives a single result. A proxy group's health check runs on its own schedule, so the two results may update at different times.

The snippet below shows proxy group fields for reference only. It uses an existing PROXY group and isn't a complete, runnable config. interval: 300 is measured in seconds; tolerance: 50 is measured in milliseconds and helps avoid switching for minor latency changes. It isn't a request timeout.

proxy-groups:
  - name: AUTO
    type: url-test
    proxies:
      - PROXY
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

Low Latency Doesn't Always Mean Fast Downloads

The completion time for a short request and sustained transfer throughput are different metrics. A node showing 70 ms may still download slowly because of limited exit bandwidth, congestion, or server throttling. A node showing 160 ms may deliver a steadier long transfer. For the first connection, confirm that websites load, then test video, file transfers, or responsiveness based on how you plan to use the connection. Don't choose a node for long-term use based only on the lowest number in the list.

4. Verify Proxy Routing: Check the Entry Point, Rule, and Exit

The most reliable verification goes beyond checking whether the connection toggle is on. Build an evidence trail for the same request: traffic enters the core, matches the expected rule, and exits through the expected node. Opening a website only proves that some route is available. If the site works over a direct connection, that alone doesn't prove the proxy is working.

Test the Local Entry Point with an Explicit Proxy

Assuming you've confirmed the mixed port is 7890, run the command below to rule out whether the app follows the system proxy. In Windows PowerShell, use curl.exe to avoid a same-name alias in some environments interfering with argument parsing. On macOS and Linux, use curl instead.

curl.exe --noproxy "" --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 https://api.ipify.org

--noproxy "" clears this command's proxy bypass list. The command only confirms that the explicitly specified entry point works; it doesn't confirm that the system proxy is configured correctly or force the rules to select a proxy node. If the rule sends this IP lookup service DIRECT, the result may still show your local network's public IP.

Trace the Same Request in the Connection Records

1. Open the client's Connections page and filter by the target domain, such as api.ipify.org.
2. Make a new request and check the target domain or IP, matched rule, proxy chain, and final node. Short-lived connections may disappear quickly, so check the history or logs as well.
3. Confirm the route isn't DIRECT and that the final node matches your manual selection. If a nested group is shown, check which member it actually selected.
4. If there are no records at all, check the port, app proxy settings, and TUN routes first; don't assume the remote node is at fault.

The info log level is usually enough to inspect routine connections and rule matches. If you need to investigate further, temporarily enable debug, then restore the previous level when you're done. Clients may reformat logs differently; focus on the target, rule, and outbound route rather than expecting identical text.

Compare the Exit IP

First, record the direct result from the same IP lookup service in a test setup where direct access is allowed. Then repeat the lookup through a confirmed proxy rule. Different results, together with a connection record showing the expected node, provide stronger evidence. IP geolocation databases can be out of date, and a city in the node name may not match the city shown in the database.

If both results are the same, first check whether the lookup request matched a direct rule. Then check whether the proxy exit happens to share your current network's public IP address. On dual-stack networks, test IPv4 and IPv6 separately; an IPv4 lookup doesn't prove that IPv6 traffic is also routed through the proxy. Don't disable IPv6 just to make a test page show a particular result. Check the client's IPv6, DNS, and routing settings first.

5. Common Issues: Narrow Down the Cause

If the issue only appears when TUN is enabled, check administrator or system extension permissions, the virtual network adapter, routes, and DNS interception. Don't replace the entire subscription with a copied snippet containing auto-route or dns-hijack. These settings depend on the platform, core version, and how the client manages the config; an incorrect override may also be replaced at the next subscription update.

When reporting an issue to the maintainer, include your operating system, client version, mihomo core version, current mode, entry port, target domain, and redacted error details. Hide subscription URLs, authentication parameters, and controller API keys. Connection logs may also contain browsing activity, so don't publish the entire file unredacted.

6. First Connection: Pass Criteria

• The current Profile is active, the core stays running, and the logs show no config loading errors.
• Traffic from the test app reaches the core, and the corresponding target appears on the Connections page.
• The target matches the expected rule, and the final outbound in the proxy chain matches your selection.
• Run multiple latency probes under the same conditions and confirm availability with the actual target.
• The exit IP check and connection records corroborate each other, with IPv4 and IPv6 verification clearly distinguished.

After these checks pass, restore automatic group selection or move on to TUN use cases. Change one setting at a time and establish a new test connection; this usually makes problems easier to find than repeatedly refreshing subscriptions, switching nodes, or reinstalling the client. For basic steps, see the user guide; for terminology, check the concept quick reference.