Clash Setup Guide:
Subscriptions, Modes, and Connection Tests
Start with an existing subscription and complete these four steps to connect for the first time. Check the config, enable traffic routing, then use the connection log to see where traffic goes.
Before You Start: Get the Client and a Working Config Ready
In the Clash ecosystem, the graphical client displays configs, policy groups, and connection logs. The core parses the config and handles traffic. Installing a client isn't enough: you also need a valid config. A subscription URL retrieves a config; it doesn't establish a connection. And opening the client doesn't mean your system traffic is going through the core. This guide separates each step so you can pinpoint where something goes wrong.
If you haven't installed a client yet, go to the client downloads page and choose one for your operating system and processor architecture. If you're unsure which client to use, start with the client comparison guide. Already have a client? Continue with it; you don't need to switch just to follow this guide. Have a subscription URL you're authorized to use from a trusted source, or a working YAML config file. This site provides config guidance and client downloads; it doesn't issue subscriptions or provide proxy service accounts.
For your first setup, keep your current network available and temporarily quit other proxy or VPN tools. This prevents two apps from changing system proxy settings, routes, or DNS at the same time. Note your current proxy settings first. If your device is managed by your employer or school, don't override its network policies. Follow the steps in order. For the initial test, there's no need to enable TUN, rewrite DNS, or add custom rules.
1. Import a Subscription and Activate the Config
Import from a Subscription URL
Open the client and go to the Config or Subscription page. Look for “Add,” “Import,” or “Import from URL.” Paste the complete subscription URL into the address field and enter any name that helps you recognize it. Check for extra spaces, line breaks, or punctuation added by a messaging app at either end, then click Download or Save. Subscription URLs often contain access credentials. Don't post a full URL publicly or show its query parameters in a screenshot.
After submitting, the client will usually show a download in progress, then add a config card or entry. Check the result first: a successful download only means the content was retrieved; you still need to confirm that the current core can parse it. Select the config and click “Use,” “Activate,” or the equivalent. If it activated automatically, make sure it's marked as the current config. Then open the Proxy page and check that policy groups and available outbounds appear. Once that's done, you can choose a mode.
If the download fails, determine whether the URL couldn't be accessed or the config couldn't be parsed. For access problems, check your network, whether the URL has expired, and whether the provider requires additional authentication. For parsing problems, check that the subscription is in Clash YAML format supported by your client and doesn't use incompatible fields. Being able to open a webpage in your browser doesn't mean the URL returns a config. A login page, error page, or regular sharing page isn't a usable config, even if it can be downloaded.
Import from a Local File
If you already have a config file, choose “Import from File” or drag the file into the client if supported. Select the .yaml or .yml file. On mobile, you may need to save it to the system Files app first, then share it with the client. Activate the config after importing and confirm that its proxy groups appear. Changing the file extension alone won't convert its format; the contents must still be valid YAML with fields supported by the current core.
For your first import, leave the config unchanged; don't rush to edit ports, rules, or DNS. If you need to edit it later, use the client's override or merge feature where possible, and keep an original copy because subscription updates may replace remote config content. For YAML indentation, field structure, and merge behavior, see the config.yaml reference. This step is complete when the config is selected, loads without errors, and shows usable policy groups on the Proxy page—not just when a subscription name appears.
2. Choose a Proxy Mode and Outbound
Once the config is active, return to the client's home or settings page and find the mode selector. For your first setup, choose “Rule,” corresponding to the rule value. Rule mode checks connections against the config's rules in order and decides whether to send them to a policy group, connect directly, or handle them another way. So it's normal for some sites to use a proxy while others connect directly. One site's behavior doesn't tell you whether the whole client is working.
| Mode | How it works | Recommended for first-time use |
|---|---|---|
rule Rule | Selects a policy based on the rules, in order | The recommended starting point for everyday use and this guide |
global Global | Sends all connections that reach the core to the global policy | Useful for targeted comparison tests |
direct Direct | Connects directly to the destination for connections that reach the core | Useful for checking whether the proxy outbound affects access |
Once you've chosen a mode, open the Proxy or Policy Groups page. Find the group the config actually uses for proxy traffic and choose an available outbound for it. Group names come from the config; they might not be called “Proxy” or “Node Selection.” If a group contains other policy groups, follow the chain until you find the final outbound. If the current selection is DIRECT, that group connects directly. Switching to rule mode won't change it to a proxy outbound automatically.
Some configs include automatic selection, failover, or load-balancing groups, so you don't need to choose an outbound manually. Confirm that the group has candidates and its health checks aren't all failing. The client's connection test can help you compare options, but a successful test only means its test target is reachable; it doesn't guarantee that every site or app will work. Keep your selection unchanged as you continue so you can compare results without switching outbounds repeatedly.
Keep “Global mode” separate from “routing all apps through the core.” Mode only determines how traffic already in the core is handled; it doesn't route apps that bypass the proxy into the core. So switching to global isn't a substitute for the system proxy or TUN. See the rule syntax reference for rule order, policy name references, and the MATCH fallback rule. For your first connection, use the subscription's existing rules.
3. Connect and Grant System Permissions
Desktop: Start with the System Proxy
On the desktop client's home page, confirm the core is running. If there's a separate start button, click it first, then turn on “System Proxy.” The status may appear as “Running,” “Connected,” or an enabled system proxy toggle, depending on the client. System Proxy points your operating system's proxy settings to the client's local listener, so apps that follow those settings send requests to the core.
For your first test, enable only the system proxy and leave TUN off. Open a new browser tab and visit a regular webpage, then check the connection log as described in the next section. If the system asks to let the client access the network, review the prompt in the context of your network. If a port is already in use or the core fails to start, fix that error instead of repeatedly toggling the system proxy. Use the port configured in your client; you don't need to copy a fixed number from another guide.
Browsers usually follow the system proxy, but command-line tools, games, and apps with their own proxy settings may not. If only one app isn't working, check whether it has a separate proxy option before assuming the subscription is broken. Command-line proxy environment variables may also differ from system settings. This guide starts by testing the browser; once the config and outbound work, you can set up other apps as needed.
Android and iOS: Allow the VPN Connection
After selecting a config and mode in the mobile client, tap Connect on the home page. Android usually shows a system VPN connection request; iOS may ask to add a VPN configuration and authenticate with the system. Check which app is requesting access, approve it, then return to the client and check the connection status. Prompt wording varies by OS version. The important part is granting system permission—not just tapping the client's button.
A VPN icon in the phone's status bar means the system connection is established, but it doesn't confirm that the remote outbound, DNS, and rules are all working. Continue with the verification steps below. If another VPN is already running, decide which connection to keep before switching. If Android disconnects often when the screen is locked, check background activity and battery restrictions. These settings aren't usually needed for a first connection; change them only if background disconnections actually occur.
Enable TUN Only If You Need to Route More Apps
TUN uses a virtual network interface and routing settings to capture traffic from apps that don't follow the system proxy. It can be used alongside rule mode: TUN determines how traffic enters the core, while rule mode determines how traffic is routed once it gets there. Enable TUN separately only after confirming that the browser path works and you need to capture additional traffic. Follow the client's prompts to install a service or grant the required permissions.
If enabling TUN prevents access, turn it off and return to the last working setup to see whether the new traffic-capture method caused the issue. Don't change routes, DNS, and policy groups at the same time. auto-route, stack, and DNS capture vary by platform and core; see the config reference for the full options. Once this step is complete, you should have a clear path for traffic to enter the core. Next, check whether requests are handled as expected.
4. Verify Rule Matches and the Actual Outbound
Check the Connection Log with a New Request
Keep the current config, mode, and outbound unchanged. Open the client's “Connections” page, then visit a test site you're authorized to access in a new browser tab. Check a new connection first; an existing long-lived connection may continue using its previous policy. The client list usually shows the destination domain or address, matched rule, policy chain, and actual outbound. Short-lived requests may disappear quickly, so check the logs as well.
First, confirm that the destination matches the site you just visited. Then check whether the policy chain ends at a proxy outbound or DIRECT. If a direct rule matched, your public IP may stay the same even with the system proxy on. That's the result of rule-based routing, not a failed connection toggle. If you expected the request to use a proxy but can't find it at all, check whether the app follows the system proxy, whether the current config is active, and whether another tool has overridden the proxy settings.
If the connection appears in the log but access fails, narrow the investigation to that connection: check whether the log shows a DNS resolution error, a timeout, or a remote rejection. Try another available outbound in the same policy group, then make a new request. Change one thing at a time and note the results. Don't dismiss every issue as “no network,” and don't reinstall the client as a first step. The error time and destination domain can help pinpoint the cause.
Use Public IP Comparisons as a Secondary Check
For another data point, use a trusted public IP lookup site to compare direct and proxied traffic on the same network. Before comparing, confirm that the lookup site matched the expected policy. If the rules send it direct, an unchanged IP doesn't mean other traffic isn't using the proxy. Results may show IPv4 and IPv6 separately, so compare the same address type and interpret it alongside the client's connection log.
Likewise, opening a webpage doesn't prove that every app on the device is using the proxy. A thorough first test confirms that the core is running, the active config is valid, the request appears in the connection log, the matched policy is expected, and the webpage loads. If one app still has trouble, check its own proxy and network settings instead of starting over with a config that's already been verified.
Finish Testing and Restore Your Network
When you're done on desktop, turn off System Proxy in the client first. If TUN is enabled, turn that off too, then exit the app. Force-quitting the process may leave the system proxy pointing to a local port with no listener, preventing your browser from connecting. If that happens, open your operating system's network settings, check whether the manual proxy is still enabled, and restore the settings you noted before starting.
On mobile, tap Disconnect in the client and confirm that the system VPN has ended. If you've enabled system options such as auto-connect, always-on VPN, or blocking connections without a VPN, check that they still suit your needs. Next time, you usually only need to confirm that the config is still valid and the outbound is available before connecting; there's no need to import the same subscription again.
When reporting an issue, include your operating system, client name, the step where the problem occurred, and a redacted error excerpt. Hide full subscription URLs, credentials, and private browsing history. For config field changes, consult the relevant section of the config.yaml reference. To repeat the setup, start with importing a subscription and check each step in turn instead of resetting everything at once.