First-Time Clash Connection Guide

Make sure the subscription configuration is active

A successful subscription import, visible proxy nodes, and working proxy traffic are three different things. The subscription provides nodes, proxy groups, and rules; the client still needs to load the configuration and route app connections through its core. Check these in order when connecting for the first time, rather than repeatedly changing subscriptions as soon as a page fails to load.

1. Open the client’s “Profiles” or configuration page, find the subscription you just imported, and make sure it is selected, in use, or active.
2. Check the result of the most recent update. If parsing, downloading, or loading the configuration failed, resolve that error first. Nodes still shown in the list may be from an older configuration.
3. Open the “Proxies” page and make sure you can see proxy groups and the nodes in them—not just DIRECT and REJECT.
4. Check the “Logs” page to make sure the core isn’t repeatedly restarting and there are no errors about a port conflict or unsupported protocol fields.

This guide uses common desktop client interfaces as examples. “Configuration → select subscription,” “Proxies → Rule,” “Connections,” and “Logs” describe where to find these features; names and locations may vary by client. Clients using the Clash Meta (mihomo) core can support more protocols and configuration fields, but only if the active core can successfully parse the subscription.

Switch to Rule mode and choose the actual egress node

Start with Rule mode for your first connection

On the “Proxies” page, find the mode selector and choose “Rule.” Rule mode evaluates connections against the rules in the configuration, in order; the first matching rule determines the proxy or proxy group to use. “Global” generally routes connections that reach the core through the global proxy group, while “Direct” connects to the destination without a proxy. Global mode does not take over traffic from every app—apps must still send their traffic to the core first.

For your first connection, avoid changing the mode, rules, and DNS settings all at once. Start with the rules provided by your subscription, then run a repeatable access test before adjusting routing for specific sites. If your configuration provides nodes but not the rules you need, check which configuration template the client is using rather than assuming all subscriptions route traffic the same way.

Expand the proxy group and confirm which node is actually selected

1. Find the main proxy group used for routed traffic. It may be named “Proxy,” “Node Selection,” or something specific to your subscription.
2. Expand the proxy group and select a specific node. Don’t choose DIRECT as a proxy node—it connects directly.
3. If the selected option is a subgroup such as “Auto Select,” check which node that subgroup is actually using.
4. If a rule assigns a separate proxy group to a particular service, check that group’s selection too. Changing the main proxy group may not affect it.

For example, the main proxy group might use node A, while a video service rule points to another group that uses node B. Traffic to the video service will still go through B. A region in a node’s name is only a label; use connection records and an IP lookup to verify the actual public egress.

Test latency to check basic connectivity

Click “Test Latency” or “Speed Test” beside a node or proxy group and wait for the test to finish. These tests typically send a request to a specified test URL through each candidate proxy and record how long it takes. They don’t continuously download a file to measure bandwidth. The test URL, timeout, and whether connections are reused can all affect the result.

The numbers in this table are examples to explain the results, not measurements taken by this site. Run the test two or three times, a few seconds apart. Treat an occasional timeout differently from repeated timeouts on every attempt. If only one node fails, try another. If all nodes fail at once, check your local network, system clock, subscription status, and core logs first.

Enable the system proxy to route browser traffic through the core

On Windows and macOS, start by testing with the system proxy rather than enabling TUN right away. Turn it on under “Settings → System Proxy” or with the “System Proxy” toggle on the home screen, then check the active listening port under “Settings → Ports.” A common mixed-port example is 7890, but subscriptions, client defaults, and custom settings can change it—use the value shown in your client.

• Windows: Open “Settings → Network & internet → Proxy” and make sure the proxy settings match the client. A common manual proxy setup uses address 127.0.0.1 and port 7890. If the client uses an automatic configuration script, check those script settings instead; the manual proxy toggle alone won’t tell you whether it’s configured correctly.
• macOS: Open “System Settings → Network → your active network service → Details → Proxies” and check that the HTTP, HTTPS, or SOCKS proxy entries managed by the client use the expected ports.
• Browser: Start with a browser that follows the system proxy settings. In Firefox, go to “Settings → General → Network Settings → Settings” and select “Use system proxy settings.” Proxy extensions or custom browser proxy settings may override the system configuration.

If you have another proxy, VPN, or network debugging tool running, disable its traffic routing before this test. Don’t turn off the system firewall to troubleshoot. If pages stop loading after you quit the client, first check whether the system proxy is still pointing to a local port that is no longer listening.

Android and TUN work differently

Android clients typically route traffic through system VPN authorization. The first time you connect, approve the system permission prompt; this is different from setting an HTTP proxy on desktop. Per-app proxy settings and bypass lists can also determine whether your test browser is routed. Desktop TUN uses a virtual network adapter, routes, and additional permissions, so test it after confirming a basic connection. It can route traffic from apps that don’t follow the system proxy.

Use connection records to verify rules and nodes

Open “Connections” in the client, then visit a new HTTPS page in your browser. Use a newly opened tab if possible; cached pages, existing long-lived connections, and background requests can make the results harder to interpret. Note the time and find the matching domain or destination address in the connection list.

1. Check the destination: Make sure the record matches the site you just visited, not a latency test request generated by the client.
2. Check the rule: Look at the matching rule type and value, such as DOMAIN-SUFFIX or the final fallback MATCH. The details shown depend on the client.
3. Check the proxy chain: Confirm the connection uses the expected proxy group and ends at a specific proxy node—not DIRECT or REJECT.
4. Check the connection status: See whether data is being transferred or the connection immediately errors or closes, then check whether the page loads successfully.

If there’s no matching record in the connection list, check the browser’s proxy settings, bypass list, and port before changing nodes. If the connection matches DIRECT, it reached the core but a rule routed it directly. If it matches REJECT, find the rule that blocked it.

If you need more detail, temporarily set the log level to info; if that’s not enough, switch to debug briefly, reproduce the issue once, then restore the previous level. Logs may include visited domains, so remove personal information before sharing them. Logs may show IP addresses instead of domain names depending on IP rules, domain rules, and DNS mapping; an IP in the log alone doesn’t prove there’s a DNS problem.

Check your public IP to confirm the egress

In the same test browser, open a public IP lookup service—for example, enter https://api.ipify.org in the address bar. First check the rule and proxy chain for this request in the client, then read the address returned by the page. The result only confirms your proxy egress if this request actually used the intended proxy.

• Expected egress: The lookup request uses the selected node, returns its public IP, and the destination page loads. This confirms that the browser test traffic is being routed through the proxy.
• Still showing your local IP: First check whether the lookup request matched a direct rule. Rule mode allows some sites to connect directly, so one unchanged IP lookup doesn’t mean the entire proxy setup has failed.
• IP region differs from the node name: IP geolocation databases may be out of date, and services can use different ingress and egress locations. A region label doesn’t prove routing to a specific city.

To establish a direct-connection baseline, note the current settings, temporarily turn off this client’s system proxy and TUN, and make sure no other VPN is routing traffic before running the lookup again. Restore your settings afterward. Don’t access services that require a proxy while routing is disabled, and don’t compare results from different browsers alone—they may use different proxy settings.

Optional: Test the local proxy port from the command line

The following example works in Windows Command Prompt or PowerShell and assumes the active HTTP or mixed listening port is 7890. Replace it if your port is different. Don’t use this HTTP proxy option with a SOCKS-only port.

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

On macOS and Linux, replace curl.exe with curl. This command explicitly uses the local proxy and clears proxy bypass settings for this request, so it doesn’t rely on the browser’s system proxy configuration. If it works but the browser doesn’t, check the browser first. If it can’t connect to 127.0.0.1:7890, check the port, core status, and listening address. Don’t add an option to skip certificate verification to hide a TLS error.

First connection results and what to check next

After confirming your first connection, save a short record of the configuration name, Rule mode setting, selected main proxy group, active port, and time of a successful page load. When you later change rules or enable TUN, change just one thing at a time and retest the same site to see which change made a difference.

A complete check should confirm three things: the app’s request reaches the core, a rule routes it to the expected node, and the destination request succeeds. A green toggle, latency result, or IP lookup alone can’t verify the entire connection path. To review your setup, see the Getting Started guide for subscription and system proxy instructions. For subscription update issues, see the Help Center’s subscription update guide.