Clash Getting Started Guide

Before You Begin: Client and Subscription

You’ll need an installed client that opens properly, plus a subscription link compatible with that client or a complete local configuration file. The client reads the configuration, applies rules, and establishes connections; installing the client alone does not provide proxy nodes. Get your subscription from your service provider or configuration maintainer. A regular webpage, account sign-in page, or payment page cannot be used as a subscription link.

If you haven’t installed a client yet, choose an installer for your operating system and processor architecture on the Clash client downloads page, then return here. When you launch it for the first time, make sure it opens to the main screen; don’t change port, DNS, or TUN settings yet. If another proxy tool or VPN is running on your device, disconnect it to avoid conflicts when routing traffic. On a work- or school-managed device, check the applicable network policies and installation permissions first.

A subscription link may contain credentials that grant access to a service. When copying it, check for stray spaces, line breaks, or punctuation added by a messaging app. Save it under a recognizable local name, and don’t post the full link in public forums. You don’t need to submit your subscription to any online tool for this guide. If the format causes problems, ask your provider for a configuration compatible with Clash or mihomo.

Step 1: Import a Subscription and Enable the Configuration

Import from a Link

Open “Configuration,” “Subscription,” or “Profiles” in the client’s sidebar or bottom navigation, then look for “New,” “Add,” or “Import.” If the interface offers both a local file and a remote link, choose “URL,” “Remote Configuration,” or the equivalent. Paste the complete subscription link into the URL field. If there’s a name field, enter a label that will help you identify it. Leave other settings at their defaults, click Download, Import, or Save, and wait for the client to finish fetching and parsing the configuration.

After import, a new entry should appear in the configuration list. It may also show an update time, traffic details, or a file name, depending on what the service provides. These details aren’t required and don’t by themselves confirm success. Select the configuration or choose “Enable” or “Use” from its menu, and make sure it’s marked as active. Then open the proxy groups and check that the expected nodes are listed. Adding a configuration doesn’t necessarily make it active automatically.

For a local YAML file, choose “Import from File” on the same page, open the configuration in the system file picker, then select and enable it. Don’t save a subscription URL as a text file and import it as if it were a complete YAML configuration—the contents are different. A file import generally uses the file’s contents at the time of import. Whether it updates later depends on remote resources in the configuration and the client’s features; it isn’t the same as a remote subscription.

If Import Fails, Troubleshoot Before Moving On

For a timeout, access-denied message, or parsing error, first check that the link is complete, the subscription is still valid, and your current network can reach the subscription service. If the client reports unsupported fields, the configuration format or core may be incompatible. If the downloaded content is a webpage, you may have used a sign-in page URL or received an error page from the server. Switching to a global mode won’t fix these issues: the core still needs a valid configuration to run.

Don’t repeatedly import the same link and end up with several indistinguishable configurations. Keep one entry, retry using its update feature, and check the specific error message. If your current network requires a proxy to update the subscription but the client has no usable nodes yet, ask your provider for an accessible subscription link or a suitable local configuration. For more on subscription formats and updates, visit the Help Center. Once nodes appear in the proxy groups, move on to choosing a mode.

Step 2: Choose a Rule Mode and Node

Return to the home or settings page and find “Operating Mode,” “Proxy Mode,” or “Mode.” For your first setup, choose “Rule” or “Rule Mode.” Rule mode uses the rules in your configuration to decide whether each request connects directly, goes through a proxy group, or is rejected. It doesn’t automatically make the right decision based on where a website is hosted; behavior depends on the rules and their order in your subscription. When you verify the setup, check which rule each request matched.

“Global” generally sends intercepted requests through a global policy. It’s useful for temporary comparison tests, but it doesn’t mean the device is routing traffic from every app. “Direct” generally sends intercepted requests straight to their destinations; it doesn’t turn off the client. For your first setup, stick with Rule mode. Constantly switching modes before confirming that the system proxy works makes it harder to identify the cause of a problem.

Next, open “Proxy” or “Policy Groups.” A configuration may include a main selection group, an automatic selection group, and several groups for different purposes. Find the main group referenced by your rules, expand it, and choose a node. If the selected item is another policy group, check the selection in that group too. Seeing one selected node doesn’t mean every website will use it; different rules may point to different groups.

If the client offers a latency test, run it for the current group and wait for the result. The reported time measures a request to a specific test target; it isn’t bandwidth and doesn’t guarantee that every website will be accessible. If a test times out, compare with another node, but don’t keep clicking the test button rapidly. Automatic selection groups choose nodes according to their configuration; manual selection groups require you to choose one. For easier troubleshooting, start with a responsive node in a group that allows manual selection.

Step 3: Connect and Route Your Traffic

Desktop: Run the Core and Enable the System Proxy

On the desktop client’s home screen, check that the core is running. Some clients start the core automatically; others require you to click “Start” or “Connect.” Then enable “System Proxy” on the home screen, in settings, or from the system tray menu. This usually directs browsers and apps that follow the system proxy settings to the client’s local listening port. Running the core and enabling the system proxy are separate steps: if only the core is running, your browser may still connect directly.

After enabling the system proxy, test with a regular browser. If the browser has a separate proxy extension or a manually configured proxy, make sure it isn’t overriding the system settings. Support for system proxies varies across Linux desktop environments. Terminals, games, and some apps may also ignore system settings. For this first test, use a browser that follows the system proxy; don’t change every network setting just because one app isn’t routed.

If the system proxy toggle won’t stay enabled, check whether the client reports a local port listening error, lacks permissions, or another proxy program keeps changing the settings. Note the error before addressing the cause. If a port is in use, don’t terminate an unfamiliar system process. Instead, close the conflicting app or change the client’s port as described in its documentation, then make sure the system proxy points to that same port.

Mobile: Allow the VPN Connection

In the Android or iOS client, confirm the current configuration and policy groups, then tap “Connect” or the main toggle. The first time, the system may ask to add a VPN configuration or allow a VPN connection. Check that the prompt is for the app you’re using, then approve it. Return to the client and wait for the connection status to stabilize. A VPN icon in the status bar only indicates that the system tunnel is established; it doesn’t confirm that the remote node, DNS resolution, or rule routing is working.

If another VPN is already connected, disconnect it before testing; mobile operating systems generally don’t allow regular VPN apps to route traffic for the same user at the same time. On Android, if only some apps aren’t working, check whether per-app proxying is enabled and whether the browser is included. If the connection drops when the screen locks, check the system’s background and battery restrictions. You don’t need to disable every battery-saving feature before your first test.

TUN is another way to route traffic, useful for apps that don’t follow system proxy settings, but it also involves a virtual network interface, routing, and DNS. Don’t enable TUN alongside other methods for your first desktop connection. Once a regular browser works and you have a specific app that needs TUN, follow the systematic configuration guide to set it up step by step. After completing this step, keep the current mode and node unchanged and move on to verification.

Step 4: Verify Websites, Rules, and Your Public IP

First, open a website you know should work to confirm that your device has basic internet access. Then visit a website that should use a proxy under your current configuration. Start a fresh request for each test; refresh the page or open a new tab if needed to avoid seeing cached content. A website loading successfully only confirms that request worked. It doesn’t show which route it used or prove that all apps are being proxied.

Next, open the client’s “Connections,” “Active Connections,” or “Logs” page and refresh the test website. Find the matching domain or destination address, then check the matched rule, policy group, and final node. If you see DIRECT, the request was routed directly. If you see a proxy group and node chain, it was handled by that proxy policy. A webpage may request many resources, so check the main site and relevant requests rather than drawing conclusions from an arbitrary background connection.

If the connection list is empty, first check whether the page actually made a new request. Also confirm that your browser follows the system proxy, or that the mobile app is within the traffic-routing scope. If requests appear but keep timing out, the traffic is reaching the core; focus on the selected node, service status, DNS, or the destination website. Change only one thing at a time—for example, try another node with the same destination—so you can reproduce and isolate the issue.

To check your public IP, use a trusted IP lookup service and note the reported egress IP. In Rule mode, the lookup service is also subject to your rules. If it goes direct, seeing your local network’s public IP is expected and doesn’t mean the client is broken. Compare the lookup result with the policy shown for that request in the connection list. The service’s database may report an inaccurate location, so don’t treat geolocation as conclusive evidence.

Finish your first setup when all three checks pass: the target website loads, its new request appears in the client, and the request’s direct or proxy route matches your configuration. If the website still won’t load, troubleshoot in this order: configuration validity → node availability → traffic routing → DNS and rules. Visit the Help Center for your specific symptoms. Don’t reinstall the client or clear all settings as a first resort.

Daily Use: Update and Disconnect

When you start the client, make sure the expected configuration is still active, then check the connection status. Subscription updates are usually in the configuration entry’s menu. Click Update, wait for confirmation, and check whether the node list has changed. An update may reset some selections or preserve them, depending on the client. If access stops working afterward, check the main policy group first; there’s no need to reimport every configuration. Set automatic updates according to how often you use the service and its requirements—avoid intervals that are too frequent.

When you’re done on desktop, turn off the system proxy before exiting the client. Whether a normal exit restores proxy settings automatically depends on the client. If the browser can’t connect after an unexpected shutdown, check the system’s network settings to see whether they still point to a local proxy that’s no longer running. On mobile, disconnect from the client and, if needed, check the system VPN settings to confirm the tunnel has stopped. Closing a window alone doesn’t necessarily stop the background core or clear the proxy settings.

Once you’ve completed this guide, continue with the beginner-to-advanced guide to learn about rule-based routing, TUN, and routine maintenance. When reporting a problem, include the client name, operating system version, time of the error, and redacted error details. This makes it easier to diagnose than a message that only says “connected but not working.” Before sharing screenshots, hide subscription links, account details, and configuration names that could identify you.