Clash Setup Guide
Import a subscription and verify your connection

Step 1: Import a Subscription and Activate the Configuration

Open the client and go to “Subscriptions,” “Configurations,” or “Configuration Management” from the sidebar or bottom navigation. Look for “New,” “Add subscription,” or “Import from URL,” then choose the remote subscription option. Paste the copied URL into the address field and check that it has no extra spaces, line breaks, or punctuation added by a messaging app. You can give the subscription a recognizable local name; it only appears in the list and doesn’t affect the connection.

You need a subscription link that returns configuration data, not the provider’s home page, login page, or payment page. Some providers offer separate formats for general use, Clash, and other clients; choose the one explicitly compatible with your client core. Don’t submit your subscription URL to an untrusted online converter. Its parameters may be tied to your account or plan, so hide the full URL in screenshots before sharing them.

After you tap “Save,” “Import,” or “Download,” wait for the client to fetch and parse the configuration. When it succeeds, the new entry should appear in the configuration list; some clients also show an update time or configuration name. Then tap “Use” or “Activate,” or select it with the radio button to make it the active configuration. An entry appearing in the list doesn’t mean it’s active—make sure the active configuration indicator points to the new entry.

Next, open the Proxies page and check that proxy groups and selectable nodes appear. Multiple groups are normal; for example, a top-level group, an automatic selection group, and policy groups organized by use case. If the page is still empty, return to the configuration list to confirm activation, then check for error messages. Don’t keep adding the same URL just because the import button gave no obvious feedback; duplicate entries are difficult to tell apart.

If you only have a local YAML file, choose “Import file,” open it from the system file picker, and set it as the active configuration. A local file may still reference remote rule sets or other resources, so successful import doesn’t guarantee those resources have finished loading. Check the configuration status for ongoing parse or resource-loading errors before choosing a mode.

For “Invalid format” or “Parse failed” errors, first check the subscription format and compatibility with the client core. For timeouts or fetch failures, retry on a working network and confirm the subscription hasn’t expired. Don’t start by changing a lot of advanced network settings. If your provider requires an existing proxy connection to update the subscription, you’ll need another working connection first; that’s different from fetching a subscription directly for the first time.

Subscriptions are usually updated from the menu for the existing entry; you don’t need to create a new one each time. Updating a remote configuration may overwrite manual edits, so keep the provider’s rules unchanged while getting started. If you need persistent custom rules, read the Protocol and Core Technical Reference to check which override methods your client supports. For now, note the name of the active configuration and continue.

Step 2: Choose a Rule Mode and Proxy Node

Return to the client’s Home or Proxies page and find “Mode,” “Outbound mode,” or a similar option. Common choices are Rule, Global, and Direct. For your first setup, choose Rule mode: connections are checked against the configuration’s rules in order, and matching traffic is handled by the specified policy. This lets you test the subscription’s routing setup without forcing every app to use the same outbound route.

Rule mode does not mean “proxy all traffic.” A connection may match a proxy group, connect directly using DIRECT, or be blocked by REJECT. So if a site still connects directly, that doesn’t automatically mean the client isn’t working. Check the connection log to see which rule it matched. Leave the rule order unchanged for now.

Once you’ve chosen a mode, open the proxy group list and find the top-level group actually used by the configuration. It might be named “Select node,” “Proxy,” or something chosen by the provider; there’s no universal naming scheme across clients. Expand the group and select a node, making sure a selection indicator appears. If you selected another proxy group, expand that one too and check its final node or selection method.

With an “Auto select” group, the client usually chooses a node based on the test method in the configuration. With a manual selection group, you need to pick one yourself. For easier first-time troubleshooting, choose one known-working node and avoid switching back and forth. Don’t change a group for an unrelated use case; the group actually referenced by the target traffic may still be using its previous selection.

If the client has a latency test, run it once to see whether any candidate nodes return a result. Latency tests are only a screening aid; they can’t guarantee that sign-ins, downloads, or real-time traffic will work. Results also depend on the test address, node load, and your local network. If no nodes return a result, note which ones failed rather than immediately changing every DNS setting. Verify actual requests in Step 4 to confirm whether a node works.

Use Global mode briefly as a comparison: if a target behaves unexpectedly in Rule mode, switch to Global, select the relevant global proxy group, and visit the same target to see whether the result changes. Switch back to Rule mode when you’re done. Direct mode sends connections handled by the core straight out. Whichever mode you choose, app traffic still needs to reach the client; you’ll configure the system proxy or authorize a mobile connection in the next step.

If you’re unsure how automatic selection, failover, and manual selection differ, use the entry provided by the subscription; there’s no need to create a proxy group. See the FAQ for common questions, or the Protocol Guide for protocol differences, core support, and configuration compatibility. The goal here is to settle on a mode and a clear outbound route, not to optimize everything.

Step 3: Start the Connection and Grant Platform Permissions

Return to the Home page and confirm the core is running normally. If the client has a separate “Start” or “Run” button, start the core before enabling traffic interception. A running core, an enabled system proxy, and enabled TUN are separate states: the core can run without receiving app requests, and the system proxy setting may remain after the core stops. Check each state separately instead of relying on the tray icon.

Desktop: Test Your Browser with the System Proxy First

Find “System proxy” in Settings or on the Home page and enable it. This toggle usually points the operating system’s proxy address to the local port where the client is listening, so browsers and apps that follow system settings send requests through the client. Keep the default listening port and don’t enable LAN access without a reason. Then reopen your browser and test a page. If it reuses an old connection, close the relevant tab and try again.

Some browser extensions and apps have their own proxy settings, which can override the system proxy. For the first test, use a browser without a separate proxy configured and disable extensions that also intercept network traffic. If the client reports that a port is already in use, check whether another proxy client is running. Don’t keep changing ports without updating the app’s proxy settings too; requests may otherwise go to the old port even though the core is running.

The system proxy doesn’t route every program. Some games, command-line tools, and apps that open their own connections may ignore system settings. That’s a limitation of this interception method, not necessarily a problem with the subscription. Test your browser first; consider TUN only if you need to cover those apps. Don’t enable the system proxy, TUN, and another VPN tool at the same time before confirming that a basic connection works.

Mobile: Tap Connect and Approve the VPN Prompt

Tap the Connect button on the Home page. The first time you start the client, the system may ask to add a VPN configuration or allow a VPN connection. Confirm the request comes from the client you just installed, then approve it. Some devices also require system authentication. Once you return to the client, wait for the connection status to show that it’s running and check whether the system displays a VPN indicator. This means the system connection mechanism is enabled; test a real request to confirm the remote node works.

If you’re told another VPN connection is active, disconnect that tool before starting this client again. Mobile operating systems and device management policies may limit simultaneous VPN connections, so turning on multiple connection switches isn’t a troubleshooting method. If the connection drops soon after the app goes to the background, first test in the foreground, then check battery management and background activity restrictions. There’s no need to change every battery-saving setting right away.

TUN: Enable It Only After the Basic Connection Works

If you need TUN, find the option in the client’s settings and follow the prompts to install a service, grant administrator privileges, or approve a network extension. Requirements vary by platform; not every client needs to run permanently as an administrator. TUN involves a virtual network interface and control of routing and DNS. See the Protocol and Core Technical Reference for details. You can complete this setup using only the system proxy or the default mobile connection method.

Step 4: Verify the Connection and Routing Rules

Open a site that should use the proxy according to your current configuration, then go to the client’s “Connections,” “Active connections,” or “Logs” page. Reload the site and look for a record matching the domain you just visited. If the client only shows warnings by default, temporarily switch to an informational log level and try again; restore the original setting afterward. The page name may vary, but the goal is the same: find evidence that the client handled the request.

First, check whether a request appears in the log. If there’s no matching record, go back to Step 3 and check the system proxy, mobile connection status, or the app’s own proxy settings before switching nodes. Existing long-lived connections may keep using the old route, so close the tab or restart the test app and make a fresh request. Simply switching modes and refreshing may not be enough to rule out an old connection.

Once a record appears, check the matched rule and final policy. For example, a domain expected to use the proxy should match a rule in the configuration and enter the proxy group you selected. The final node should match your choice in Step 2. A request expected to connect directly showing DIRECT is normal. If the record shows a blocking policy, check whether it matched a blocking rule in the configuration; don’t mistake that for a network timeout.

Next, test a site expected to connect directly and make sure it still opens, then check its outbound policy. Testing both paths lets you distinguish “the client can forward connections” from “routing rules behave as expected.” A site that shows your apparent exit IP only reflects the route used for that site’s request; it can’t prove that other apps, domains, or protocols use the same path.

If the request reaches the expected proxy group but the page still fails, switch to another node in that group and repeat the same test. Keep other settings unchanged to see whether the problem is limited to one node. If every candidate fails, check that the subscription is valid and your local network is working, then look for connection timeouts or protocol compatibility errors in the log. Don’t change the network, mode, DNS, and node all at once and then guess what fixed it.

If Global mode works but Rule mode doesn’t behave as expected, compare the matched rules in the logs and check the active configuration, rule target, and proxy group selection. If the browser works but a particular app doesn’t, first check whether that app follows the system proxy and needs another interception method. For subscription failures, DNS issues, LAN access, or disconnections after sleep, see the FAQ and Troubleshooting Guide. You don’t need to work through every case during your first setup.

After verification, switch back to Rule mode, keep the proxy group selection you confirmed works, and restore the original log level if you changed it. If you want the client to start automatically, check the meanings of “Start client on startup” and “Connect on startup” separately; they’re usually different options. Check the running state after your next restart too—a client window being open doesn’t necessarily mean traffic interception is active.

When you’re done, turn off the system proxy or exit the client normally on desktop. On mobile, tap Disconnect to end the connection. If the client crashes and your device can’t access the internet, check whether the system still has a local proxy configured or another VPN connection active before deleting the subscription. Keep the configuration you verified; if problems come up later, revisit these four steps in order: configuration, mode, interception, and request log.