Clash Setup Guide

Step 1: Import a Subscription

Import a working configuration into the client before connecting. The client reads the configuration, selects a proxy, and routes traffic; installing the app alone doesn’t provide a proxy service. Before you begin, get a Clash-compatible subscription URL from your provider or a working local YAML configuration. Subscription URLs are usually tied to your account, so keep them in a trusted client. Don’t post them in public forums, include them in screenshots, or paste them into unfamiliar online converters.

Add a Configuration from a Subscription URL

Open the client and go to Config, Subscriptions, or Profiles. Look for Add, Import, or a plus button. Choose the option to import from a URL, then paste the full subscription URL. If the interface includes a name field, enter a label you’ll recognize, such as “Daily config.” This label is for local reference only and won’t change the proxies or rules in the subscription. Before saving, check for leading or trailing spaces and make sure you haven’t pasted your provider’s account page URL by mistake.

After you click Download or Save, wait for the new entry to appear in the configuration list. You’ll usually see an update time or configuration name, with no parsing error. Then click the entry or its Enable button to make it active. Some clients save an imported file without switching to it automatically. This step is complete only when you see a Current indicator or the proxy page shows the expected groups. Don’t enable multiple traffic-routing options yet; first confirm that the client has loaded the configuration.

Importing Local Files and Fixing Import Errors

If you have a .yaml or .yml file, choose Import File on the same page, select it in the file picker, then activate the configuration. On mobile, you may be able to share the file with the client from the system share menu; available options vary by client. Unlike a remote subscription, a local file usually won’t update automatically. You’ll need to import it again later or maintain it using the client’s editing or override features.

For “Invalid format” or “Parse failed” errors, first check that the subscription provides a Clash configuration supported by your client—not a webpage, a single protocol link, or a Base64-encoded list of proxies. If the request times out, check whether the subscription service is reachable on your current network. Don’t change DNS, TUN, and ports all at once to fix a download error. A usable configuration needs to provide a working proxy and the relevant policy groups. Providers structure their configurations differently, so the file extension alone doesn’t confirm compatibility.

When you’re done, return to the proxy page and confirm that proxy groups or selectable proxies appear before moving on. Some clients keep the previous working configuration when an update fails, so it may not contain the latest subscription data. For format detection and update settings, see Importing Subscription URLs and Common Formats. If no proxy groups appear after import, check FAQ: Installation and Configuration.

Step 2: Choose a Proxy Mode

Rule mode is a good choice for your first setup. It uses the rules in your configuration to decide which connections go direct and which use a proxy group, making it suitable for everyday use. On the client’s home, dashboard, or proxy page, find the Mode selector and choose Rule. This only determines how traffic is handled once it reaches the core. It doesn’t send browser or other app traffic to the client; you’ll set that up in the next step.

The three common modes are Rule, Global, and Direct. Global mode sends traffic that reaches the core to the global policy, but whether it uses a proxy depends on the selected proxy in that policy. It doesn’t mean all apps on your computer are routed through the client. Direct mode sends connections that reach the core straight to their destinations. There’s no need to cycle through all three modes during initial setup. Keep Rule mode selected so you can check the results against the rules in the next steps.

Choose a Proxy in the Policy Group

Open the Proxies page and find the main group used for everyday traffic. It may be called Proxy, Proxy Selection, or something specific to your provider. Expand the group and choose a proxy you know is available, or keep the automatic selection group if your configuration provides one. A group option may lead to another group rather than a specific proxy. Follow the selection through to its final proxy instead of stopping at the first group name.

DIRECT means a direct connection, and REJECT means the connection is blocked; neither is a proxy. If a group meant to proxy traffic is set to one of these options, the proxy egress may not change or the page may fail to load. Don’t set every group to the same proxy: configurations may use separate groups for different services, and keeping that structure usually makes them easier to use and troubleshoot. Change only the group that the request you’re testing is expected to use.

If the client offers a connectivity test, run it from the main proxy group and check whether a proxy responds. The result only shows connectivity to the test address; it doesn’t guarantee that every website is reachable or indicate your actual download speed. If all tests fail, check that proxies have loaded, your service account is active, and your device’s clock is correct, then check your network. Repeated speed tests won’t fix a connection problem.

At this point, confirm that Rule mode is selected and the main proxy group has a specific proxy or automatic selection. Leave both settings as they are and continue to route traffic through the client. To learn about the differences between automatic selection, failover, and load balancing, see the proxy group reference later. You don’t need to write your own groups or reorder rules to connect for the first time.

Step 3: Connect

Rule mode can only act on traffic that reaches the client. Desktop system proxy, TUN, and mobile VPN permission are different ways to route traffic through the client; they aren’t the same as Rule, Global, or Direct mode. For your first setup, use the simplest option on your platform, then expand coverage after you’ve confirmed it works. Before connecting, close other proxy or VPN tools that might route the same traffic to avoid conflicts with routes or system settings.

Desktop: Start with the System Proxy

On a Windows or macOS client, find the System Proxy switch on the home page or in Settings and turn it on. The core should be running and the current configuration enabled; some clients require you to click Start first. The system proxy updates your operating system’s proxy settings, directing apps that follow those settings to a local listening port. For your first test, use a browser that follows the system proxy. Don’t start with a game, command-line tool, or app with its own proxy settings.

If your browser has a proxy-switching extension, check that it isn’t overriding the system settings. Apps with manually configured proxies may also keep using their own settings. You don’t need to enter the port separately in each browser; first let your test browser use the system proxy. Once the client is running, new browser requests should reach the core. Minimizing the window usually won’t stop it, but quitting the client may interrupt the connection, depending on how its background service works.

Enable TUN only if you need to route traffic from apps that ignore system proxy settings. The client may ask to install a service, create a virtual network adapter, or request administrator permissions. Follow prompts from a client you trust. Clients handle system proxy and TUN differently when both are enabled, so for your first troubleshooting pass, use the traffic-routing method recommended in the client’s documentation. If local network access stops working, switch back to the system proxy setup you’ve confirmed works. Don’t change all your routes and DNS settings at once.

Mobile: Approve the System Connection

In an Android or iOS client, enable the configuration and choose a policy, then return to the home page and tap Connect or Start. The first time you connect, the operating system usually asks to add a VPN configuration or establish a VPN connection. Check that the request comes from the client you’re using before approving it. If you deny the request, the system won’t route traffic through the client, even if the configuration was imported successfully. After granting permission, return to the client and check that it shows Connected or Running.

A VPN icon in the system status bar means the traffic-routing tunnel is established; it doesn’t guarantee that the proxy is reachable. Some clients let you include or exclude individual apps. If you’ve changed those settings, make sure your test browser is included. Battery restrictions may also stop the client in the background. For your first test, keep the app running normally. Once the connection works, you can allow any background activity it needs in system settings.

At the end of this step, the core should be running, the system proxy should be on, or the mobile client should show an active connection. If the client reports a listener error, check for a port conflict. If the permission prompt doesn’t appear, check whether the client already has system permission or another VPN connection is active. For more help, see the troubleshooting FAQ. For the differences between system proxy and virtual network adapters, read TUN Mode vs. System Proxy.

Step 4: Test Your Connection

Judge the result by real requests and connection logs, not just the switch state. Keep the client running, open a new browser tab, and visit a site you can normally access to confirm your basic connection is working. Then visit a site that should use a proxy under your current rules. Use a new request rather than relying on a page that’s already loaded; cached content and existing connections may still use the previous route. After changing the mode or proxy, close old tabs and try again if needed.

Check the Rule, Proxy Group, and Final Proxy

Open the client’s Connections, connection log, or request log page, then refresh the target page in your browser. Find the new entry for the target domain and check which rule matched, which proxy group was used, and which proxy handled the request. Clients show different levels of detail, but you should at least be able to confirm whether the request reached the core and whether it went direct or through the selected proxy. Check the request you just made rather than relying on status text on the home page.

In Rule mode, some requests are supposed to go direct. A webpage loading successfully or a connection showing DIRECT doesn’t by itself mean the proxy is broken. First check that the configuration is supposed to proxy that destination, then compare the result. To check your public IP, you can use a trusted IP lookup service and confirm in the client that the request matched a proxy group. If the lookup site is set to go direct by your rules, seeing your regular network IP is expected.

A successful test means the target page loads, the request appears in the client, the matching policy is as expected, and the final proxy is the one you selected. If some apps still behave differently while the browser test works, check which traffic is being routed before switching all your proxies. Command-line tools, apps with their own network stacks, and apps with dedicated proxy settings may need separate configuration or a suitable TUN setup.

Narrow Down the Problem by Where the Request Appears

If refreshing the target page produces no connection log entry, first check that the system proxy is still enabled, the browser isn’t overriding system settings, and the mobile client is still connected. Make sure the connection list doesn’t have a filter enabled and that the request hasn’t disappeared from the active connections list; check the logs if needed. Only troubleshoot the traffic-routing method once you’ve confirmed the request never reached the core. Don’t change proxy protocol settings yet.

If a connection entry appears but the request times out, check that the final proxy is the one you selected, then try another available proxy in the same group. If only one domain fails, use the logs to distinguish a DNS error, a rule mismatch, or a problem with the destination service. If all destinations fail, check your subscription status, proxy availability, and current network. Change one setting at a time and retry the request so you can tell what made a difference.

After your first successful test, keep Rule mode and the traffic-routing method you’ve confirmed works. You can configure subscription update intervals later. Before quitting the desktop client, turn off the system proxy or confirm that the client will restore your system settings. Otherwise, apps may keep connecting to a local port that’s no longer listening. On mobile, disconnect from the client and confirm the system VPN connection has ended. The next time you start, you’ll usually just need to check that the configuration is active, select a proxy, and connect.

If you still can’t complete the test, note the client name, operating system, traffic-routing method, and the step where the error occurs, then check FAQs and troubleshooting. Before sharing logs, remove subscription URLs, account details, and proxy credentials. For help with mixed-port, DNS, or custom rules, see the configuration file reference. Don’t replace an entire configuration that already loads just to get your first connection working.