Clash First Connection Guide

Establish a connection you can verify

For your first connection, keep the setup simple: enable your configuration, switch to Rule mode, select a node manually, turn on the system proxy, and load a webpage. Don’t run multiple proxy clients at once or start by changing DNS, TUN, and rules. Change one thing at a time so you can pinpoint where a problem occurs.

1. Import your subscription from the Configuration or Profiles page, then select it. A successful import doesn’t mean it’s enabled. Go back to the proxy page and confirm that the proxy groups are visible.
2. Switch the operating mode to Rule. For your first test, keep the rules included with your subscription; don’t add custom routing rules yet.
3. Choose a specific node in the relevant proxy group and run a latency test. Make sure the selection isn’t DIRECT or REJECT.
4. On desktop, enable System Proxy, then visit a website in your browser and check the request on the Connections page.

Select the actual outbound route in a proxy group

Open Proxies and find the group used by the rules that apply to your traffic; don’t just click the first node you see. A subscription may include groups such as Node Selection, Auto Select, or Overseas Services. These names are set by the configuration author, not by the client. A group can also point to another group, so follow the selection chain to identify the final node.

How to choose among three common group types

For example, if a website matches Overseas Services, that group selects Node Selection, and Node Selection has Singapore A selected, then Singapore A is the final outbound node. Changing an unrelated group won’t change the route for that website. A region in a node’s name is only a label; verify the actual outbound address by making a request.

• DIRECT means the request connects directly without using a proxy node. It’s appropriate for local traffic and direct-routing rules, but it doesn’t prove that the proxy connection works.
• REJECT means the request is blocked. A connection failure is expected if you select it by mistake.
• If you have many nodes, start with two nearby options marked as healthy by your provider. When troubleshooting for the first time, don’t cycle through a dozen nodes.

What a latency test can tell you

Click the test or latency button next to a proxy group and wait for the test to finish. A typical URL latency test sends a request to a specified HTTP or HTTPS address through the node and records how long the probe takes. It isn’t a standard ICMP ping or a download speed test. The test URL, connection reuse, DNS, and node load can all affect the result.

Use three test runs to check consistency

Select a candidate node and run three tests against the same URL, leaving about five seconds between runs. Record the results, then test another node. These figures illustrate how to assess results; they aren’t measurements or speed guarantees for any node on this site.

Automatic probes often use an address that returns 204, such as https://www.gstatic.com/generate_204. But reaching that address doesn’t mean video, sign-in, or file downloads will work. Conversely, a network may block the probe URL, causing a usable node to time out. Check access to real websites too; don’t rely on one number.

Enable the system proxy and confirm requests reach the core

On Windows or macOS, start by using the client’s System Proxy switch to test browser traffic. It typically points the system proxy settings to a local listening port, but it doesn’t force every app to use the proxy. Browser extensions, app-specific proxy settings, and some command-line tools may ignore the system proxy.

Check the port, then send an explicit proxy request

On the Settings page, look for Port, Mixed Port, or Mixed Port. 7890 is a common example, not a fixed value for every client. The fields below show what the configuration means. Use them to check your active settings; don’t overwrite your subscription file with them:

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

Once you’ve confirmed that the active mixed port is 7890, run this command in Windows PowerShell. On macOS or Linux, replace curl.exe with curl. If your port is different, change the number in the command.

curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 --head https://example.com/

• This command explicitly uses the local HTTP proxy, making it useful for checking whether an app is reading the system proxy settings. The mixed port accepts HTTP proxy requests.
• If you see Failed to connect and the address is 127.0.0.1, first check that the core is running and that the port is correct.
• If you receive an HTTP response from the destination server, the request completed at least that part of the connection. Even a 403 shouldn’t be treated as a local port failure.
• If an explicit proxy request works but your browser doesn’t, check the system proxy switch, the browser’s own proxy settings, and extensions before changing subscriptions.

Requests that reach the core still follow the active rules; a direct-routing rule may send them via DIRECT. So a successful command only confirms that the local proxy endpoint works. Check the connection record to see whether the request used your selected node. For more on listening endpoints, see Port settings in the setup guide.

Check the rules and node in the connection records

Open Connections, filter by domain, then refresh a website you want to test. For your first check, use a regular site that you know should go through the proxy, rather than relying on an existing long-lived chat connection. If connection records disappear too quickly, open Logs as well and watch new requests at the info level.

Check at least four details for each request

1. Destination domain or address: Make sure the record is for the site you just opened, not a background update or another browser tab.
2. Matched rule: Check whether a domain rule, IP rule, or final fallback rule was applied. Rules are generally evaluated from top to bottom, and the first match determines what happens next.
3. Proxy group chain: Follow the group names to the final node. If the result is DIRECT, that request did not go through a proxy node.
4. Traffic changes: Upload and download counters should change when you refresh. A connection entry by itself, with no response traffic, doesn’t prove the page loaded successfully.

If the page shows an unexpected outbound IP, visit a trusted IP lookup service in the same browser and check the route for that request at the same time. The lookup site may also be affected by your rules and could connect directly. Its result only shows the outbound IP for that request, not whether every app uses the same route.

After switching nodes, make a new request to test the connection. Existing TCP connections or the browser’s connection pool may keep using the old route. Some clients offer a Close Connections option; this interrupts active transfers, so don’t use it during a download or call. For more on rule matching, see How rule-based routing works.

Choosing between System Proxy and TUN

Once the browser works through the system proxy, consider whether you need TUN mode. TUN uses a virtual network interface to capture traffic that matches its routing rules. It’s useful for apps that don’t read system proxy settings, but requires the client to configure permissions, routes, and DNS. It doesn’t speed up nodes or restore an inactive subscription.

• Desktop browser traffic: Start with the system proxy to avoid adding permission and routing variables.
• Games and standalone network apps: First check whether the app supports proxies. Enable TUN only if you need it to capture traffic, and check for service-mode or administrator permission prompts.
• Android clients: These typically use system VPN permission to create a traffic-capture connection. Don’t follow the desktop system proxy steps. Other VPN apps may compete for the same connection.

After enabling TUN, check the connection records again. Some issues affect only UDP or domain resolution, so a working webpage doesn’t prove that every protocol is working. Avoid running another VPN while troubleshooting for the first time. If you rely on a work VPN, check your organization’s network requirements and routing policies first.

Diagnose first-connection problems by symptom

When an error occurs, note the time, destination domain, current mode, node name, and exact error message. Before sharing logs, remove subscription URLs, tokens, passwords, and personal browsing records. Subscription URLs often contain access credentials; don’t post them publicly or hand them to an online conversion service.

How to tell your first connection is working

The configuration is enabled, a candidate node responds to a probe, requests reach the core, the expected proxy group matches the rules, the final route includes your selected node, and the destination page loads successfully. These checks are more meaningful than a Connected status on the home screen. Afterward, configure auto-select, subscription updates, or app-specific routing as needed, using the same verification steps for each change.