10-minute quick start

Clash Setup: From Subscription Import to Connection Verification

This workflow covers the four things required for first-time use: prepare the configuration, choose a routing method, establish the system connection, and confirm that requests follow the expected path. Each step builds on the previous result, so working in order makes problems easier to isolate.

Download Clash Start setup
4 consecutive steps Mobile and desktop Basic setup path
QUICKSTART Setup path
  1. 01
    Import subscription Profiles / Configuration
  2. 02
    Choose a mode Rule / Routing
  3. 03
    Establish connection VPN / System proxy
  4. 04
    Verify results Connection / Routing / DNS
Work in order and avoid changing multiple settings at once

Before you begin

Confirm the client and configuration source

Prepare an installed Clash client and a subscription URL that is still valid, or a local YAML configuration file. Subscriptions are generated by the service provider; the client itself does not create node information.

Haven’t installed a client yet? Go directly to your platform:

Download for Windows Download for macOS Download for Android Download for iOS Download for Linux

Configuration entry point

Import the subscription and make it active

After opening the client, find the “Configuration,” “Subscription,” or “Profiles” page. Desktop clients usually place it in the left navigation, while mobile clients often put it in a home-screen card, side menu, or bottom navigation. On that page, look for “Import from URL,” “New subscription,” or a plus button. If the provider gives you a subscription address beginning with https://, use URL import. If you received a file with a .yaml or .yml extension, import it as a local file.

When pasting a subscription URL, copy it exactly from beginning to end. Do not include a period, spaces, or line breaks automatically added by a messaging app. You can enter a recognizable name such as “Daily setup”; this only changes how it appears in the client and does not alter the subscription. After confirmation, the client will request the remote configuration and save it locally. Do not enable the connection yet. Wait for the new configuration entry to appear, and check for an update time, update button, or policy group details.

A successful configuration download does not mean it is already active. Some clients switch to an imported profile automatically, while others keep the previous one active. Click the newly imported entry and confirm that it has a selected marker, highlighted border, or “Current” status. If an “Update” button is available, run one manual update: the expected result is a changed update time with no parsing error. If the client reports an invalid configuration format, check the subscription type with the provider instead of editing the YAML at random.

Completion checklist

  • The newly imported subscription appears in the configuration list and is selected.
  • The proxy page shows policy group names instead of a blank page.
  • A manual update finishes without a network error, authorization failure, or parsing error.

Once the active configuration is confirmed, move on to proxy mode and policy selection. This step determines which path different requests should take; it does not modify the subscription you just imported.

Routing method

Choose Rule mode and an available policy

Open “Mode,” “Mode settings,” or the running-mode control on the client home screen. Common options include Rule, Global, and Direct. For a first setup, choose “Rule” mode, usually shown as Rule in English interfaces. In this mode, the configuration decides whether requests use the proxy or connect directly based on domains, IPs, application processes, and fallback rules. Common sites do not all need to use the same node, and LAN traffic or explicitly direct requests can keep their original route.

“Global” mode sends most requests through one proxy policy. It can help determine briefly whether rules affect a target, but it is not ideal as the default troubleshooting method during first-time setup. “Direct” mode bypasses the proxy, so it will not produce the expected proxied result even after the connection is enabled. If your goal is simply to establish a basic connection, keep Rule mode and avoid changing DNS, sniffing, Fake-IP ranges, and rule sets at the same time. Change one factor at a time so you can identify the failing layer.

After choosing a mode, open “Proxy,” “Proxies,” or “Policy groups.” This is usually more than a simple node list: it contains several policy groups, some for manual selection, some for automatic selection, and some for specific sites. Find the group handling most of the traffic. It may be named “Node selection,” “Proxy,” “Proxy,” or a custom name supplied by the provider. Open that group and choose a clearly available node. If the configuration includes an automatic selection policy, you can choose it first and let the configuration determine the actual exit.

A test button beside a node is only a connectivity reference. A failed test may be caused by the current network, test URL, or protocol handshake, so one result cannot replace real browsing verification. A safer approach is to choose one node, note its name, and complete the connection. If a page still will not open, return here and test another node. This helps distinguish an unavailable node from a system proxy that is not intercepting requests.

First-time setup

Rule mode

Use the configuration rules to decide whether traffic is proxied or direct. This is suitable for everyday use and is the mode used in the rest of this tutorial.

Temporary diagnosis

Global mode

Send most requests through the current proxy policy. This can show whether rules affect a target, but it changes the route for overall traffic.

Bypass the proxy

Direct mode

Connect directly to the target. Use this when pausing the proxy path; it is not suitable for testing whether proxy nodes work.

At this point, the configuration and exit policy are set, but the operating system may not yet be sending application traffic to Clash. The next step is to establish the system-level connection. On mobile, this is usually done through the system VPN interface; on desktop, start with the system proxy.

System takeover

Enable the connection and confirm the system status

In the Android or iOS client, return to the home screen and tap the connection switch. The first time you enable it, the operating system usually displays a VPN configuration or connection request. This is the system entry point that lets the mobile device hand network traffic to the client. Read the prompt and approve it. If another VPN tool is already connected, the system may ask you to disconnect it first because most phones allow only one active VPN tunnel at a time.

After a successful connection, the client home screen should show “Connected,” “Running,” or an equivalent status, and the system status bar may display a VPN indicator. Keep the app in the foreground for a few seconds so the configuration can initialize. If the switch turns off immediately, check the client log or home-screen error and focus on whether the active configuration is valid, the app has VPN permission, and the selected node can connect. Do not tap the switch repeatedly; the previous connection may not have been released before the next request began.

On Windows and macOS, desktop clients usually start with “System Proxy,” “System Proxy,” or “Set as System Proxy.” Once enabled, browsers and desktop apps that follow the system proxy settings send HTTP and HTTPS requests to the local port listened to by Clash. Some clients offer the switch from a menu-bar or tray icon, and the first change to system settings may require permission. After enabling it, check that the menu item remains selected instead of immediately switching back off.

Linux desktop environments do not all support system proxies in the same way. With a graphical client, enable its system proxy first, then check whether the desktop environment’s network proxy settings were updated. Terminal programs may also require proxy environment variables in the current shell. For basic verification, start with a browser because it is usually easier to confirm that the system proxy is being used. Servers, routers, and transparent proxy setups are outside this quick workflow; see the advanced configuration handbook for TUN, routing, and external control.

TUN mode can take over traffic from applications that ignore the system proxy, but it involves a virtual network interface, administrator permissions, routing tables, and DNS coordination. There is no need to enable it at the start. First verify browsing through the system proxy; enable TUN only when the browser works but a specific app still connects directly, following the client’s instructions. This keeps basic connection issues separate from virtual-interface permission problems.

Check by platform

  • Android / iOS: The client shows Connected, the system status area displays a VPN indicator, and the connection switch stays on.
  • Windows / macOS: The system proxy remains enabled, and the browser has not separately specified another proxy extension or fixed port.
  • Linux: The desktop proxy settings or the current app’s proxy environment points to the client, and no other program is using the local listening port.

Do not change more settings immediately after connecting. Keep the current mode and node unchanged and go straight to verification. Test both a target that requires a proxy and one expected to connect directly; testing only one page can miss rule or DNS problems.

Confirm the result

Verify proxying, direct access, and rules

Open a new browser tab and visit a target that normally cannot be reached directly on your current network but should be accessible through the selected node. A new tab reduces interference from existing connections and cache. If the page loads reliably, refresh it once and open a secondary page to confirm the result was not served from cache. Then visit a site that should normally connect directly according to the configuration, and check that sign-in, images, and API requests work normally.

Return to Clash’s connection, log, or request-history page and inspect the entries generated by your visit. Normally, a record shows the target domain, the matched rule, and the policy used. The level of detail varies by client, but recent connections should be visible at minimum. If the target page opened but the log contains no corresponding request, the browser may not be going through the current client: on desktop, recheck the system proxy; on mobile, confirm that the VPN is still active.

If a page requiring a proxy still will not open, switch to another node in the same configuration and try again. If it works afterward, the problem is likely with the original node or its connection path. If several nodes fail, continue by checking the subscription, system proxy, and DNS. If the target opens but many sites that should connect directly are unusually slow, check whether Global mode was selected by mistake and whether the main policy group points to an unsuitable exit.

DNS issues often appear as domains failing to open while direct connections to known IPs or some applications still work. In a basic setup, avoid copying random DNS snippets from elsewhere: Fake-IP, fallback resolution, rule providers, and TUN must match the full configuration. First disconnect and reconnect to ensure the configuration was loaded completely. If the issue persists, note the failing domain and log message, then read the DNS and Fake-IP section in the terminology guide, or adjust settings step by step in the DNS chapter of the advanced configuration handbook.

Check A

Proxied target is reachable

Confirm that the selected policy and node can establish a real connection, not merely that the client switch is enabled.

Check B

Direct target works normally

Confirm that Rule mode is not mistakenly sending every request through one exit and is not disrupting LAN access.

Check C

Matching entries appear in the log

Confirm that requests are reaching Clash and that the matched rule and final policy are visible.

Quick troubleshooting

Follow a fixed rollback order when the connection fails

Do not reinstall the client, change DNS, switch modes, and alter ports at the same time. Check each layer along the request path to determine whether the problem is in the configuration, node, system takeover, or name resolution.

01

Check the configuration

Return to the configuration page and run a manual update. If the update fails or policy groups are empty, resolve the subscription URL, validity period, or configuration format issue first.

02

Switch nodes

Keep Rule mode and the connection method unchanged. Replace only the node in the main policy group, then revisit the same target page for comparison.

03

Check system takeover

On mobile, confirm the VPN status. On desktop, confirm that the system proxy is still enabled and close other tools that modify system proxy settings.

04

Check DNS and conflicts

Only after the first three checks pass, investigate DNS errors, port conflicts, TUN permissions, and security-software interference. Avoid expanding the scope too early.

The subscription is imported—why is the proxy page still empty?

First confirm that the new configuration is selected as the active one rather than merely saved in the list. Then run a manual update and look for parsing errors. If the configuration contains only basic port settings and no proxies or policy groups, the proxy page will have no selectable items.

The client says it is connected—why is nothing changing in the browser?

On desktop, check whether the system proxy is actually enabled and whether the browser uses a separate proxy extension. On mobile, check that the system VPN indicator is still present. Then inspect the Clash log for browser requests; no entries usually mean traffic has not reached the client.

What if a site uses the wrong policy in Rule mode?

Find the domain in the log and identify the rule it actually matched. Determine whether the cause is rule order, rule-set content, or domain resolution. Temporarily switching to Global mode is useful only for comparison and does not fix the rule itself. Continue in the advanced configuration handbook for custom rules and rule-set management.

When should TUN mode be enabled?

Consider TUN when the browser works through the system proxy but certain applications that ignore system proxy settings still connect directly. Before enabling it, confirm that the client has the required permissions and understand how the virtual interface, routing, and DNS settings interact.

Next steps

Configuration options beyond basic connectivity

Policy group orchestration, rule-set subscriptions, DNS optimization, TUN, Fake-IP, domain sniffing, and merging multiple subscriptions are advanced topics. For precise adjustments, open the systematic handbook and go to the relevant chapter.

View advanced configuration Read the terminology guide