Clash Setup Guide

Step 1: Import a Subscription

Before you begin, install a client that supports your operating system and processor architecture. Find one on the client downloads page. Get a subscription URL from a trusted provider that explicitly supports Clash or mihomo, or use an existing YAML config file. The client reads the config and establishes the connection; installing the software alone does not provide a working proxy. Subscriptions usually contain node details and may also include policy groups, rules, and DNS settings. Check the provider's documentation and the imported config to see what yours includes.

Add the URL and wait for the config to download

Open the client and go to Config or Subscription. Look for an option such as New, Add, or Import from URL. Paste the entire subscription URL into the address field, give it a recognizable name, then save or import it. Don't use the provider's login page URL as the subscription URL, and don't include surrounding quotation marks, line breaks, or text added by a chat app when copying. Subscription URLs may contain access credentials; don't post them on public forums, include them in screenshots, or paste them into online conversion tools.

After submitting the URL, wait for the download to finish. You should see a new config card, often with an update time, node list, or policy group entry. Some clients download the config without enabling it, so you may need to click Use, Activate, or Select. Return to the home screen and check that the active config name has changed. If you were using another subscription, make sure the old config is no longer active. A new entry in the list does not mean the core has loaded it.

Check the Format and Load Status

Open the Proxy page and check for policy groups and available outbounds. If you see only a few default entries, return to the Config page and check the import status and any error messages. Errors mentioning YAML, parse, or “invalid config” may mean the URL returned a login page, a plain node list, or an incompatible format. First confirm whether the provider supplies a full config subscription or a node subscription intended only for proxy providers. Don't start deleting unfamiliar fields in an editor.

If you have a local YAML file, choose Import from File on the same page and select it. File imports usually don't retain a remote auto-update link, so you'll need to reimport the file or maintain it yourself. URL subscriptions, by contrast, can be updated from the Config page, but an update may overwrite direct edits to the downloaded config. For your first connection, keep the original config. Once the network works, learn about overrides and merges in the configuration reference.

At this stage, check just three things: the download completed, the config is enabled, and the Proxy page shows the expected policy groups or outbounds. If the subscription download times out, try again on your regular network and make sure the URL is still valid. Don't change system DNS, proxy ports, and routing all at once to fix an import issue. Once all three checks pass, keep the current config and move on to choosing a proxy mode.

Step 2: Choose a Proxy Mode

Find the mode selector on the home screen or Proxy page, and choose Rule for your first setup. The interface may also offer Global and Direct, which correspond to the common config values rule, global, and direct. These options determine how connections are routed after they reach the core; they don't route traffic from every app into it. After choosing Rule mode, complete step 3 to route traffic through the system proxy or VPN.

Start with Rule Mode, Then Check Your Policy Groups

In Rule mode, the core checks destinations against rules in order. The first matching rule determines which policy group handles the connection or whether it goes direct. DIRECT usually means a direct connection; policy group names are set by the config author and may be something like “Proxy” or “Auto Select.” Don't infer a group's purpose from its name alone. Check its options and see which group the connection log actually references.

Open the main proxy policy group, select an available outbound, and make sure the selection indicator moves to it. If the selected option is another policy group, open that group and choose the final outbound too. Auto-select groups test and switch outbounds according to the config, while manual groups keep the option you choose. For your first test, pick a specific outbound so an automatic switch doesn't complicate troubleshooting. Latency tests can be useful, but a response doesn't prove that every website, protocol, or UDP connection will work.

Know the Difference Between Modes: Global Doesn't Capture Traffic

Global mode sends connections that reach the core through the global policy. It can help you briefly check whether a routing rule is affecting access, but it is not the same as TUN and won't route apps that bypass the system proxy into the core. Direct mode tells the core to handle connections as direct, so it can't test whether a proxy outbound works. If you switch to Global mode for troubleshooting, select an outbound in the global policy group, then switch back to Rule mode when you're done.

If the config includes ad-blocking or reject rules, some requests may match REJECT. That's different from an outbound connection failure. Note the destination domain and matched rule; don't delete an entire block of rules. For details on rule scope, match order, and fallback syntax, see the rule syntax reference. For now, make sure Rule mode is selected and the policy group in use isn't set to an unexpected Direct or Reject option.

Your config and outbound selection are ready. Next, route app traffic through the client. Keep the current mode and policy group unchanged so that, if step 3 or 4 fails, you can tell whether the issue is traffic capture or the outbound connection itself.

Step 3: Connect

First check the home screen to see whether the core is running or whether there's a Start or Run button. Some desktop clients start the core automatically, but leave the system proxy off. For your first test, use one clear traffic capture method: the system proxy on desktop and the client's VPN connection on mobile. For now, don't run other proxy tools, browser proxy extensions, and multiple virtual network modes at the same time; requests could be routed through a second setup.

Desktop: Start the Core, Then Enable the System Proxy

In your Windows, macOS, or Linux client, turn on System Proxy. Your operating system may ask for permission to change network settings. Approve the prompt and check that the switch stays on. Then open a browser that follows the system proxy, disable any extensions that set their own proxy, and visit a familiar site. Don't assume the connection is working just because the taskbar or menu bar icon has changed.

The system proxy tells apps that support it to use a specified local proxy address, but not every app follows that setting. Some terminal tools, games, and standalone environments may continue to connect directly. If you see this behavior, complete the main test in a browser first; there's no need to switch to TUN right away. To configure an app manually, use the HTTP, SOCKS, or mixed port shown in your client. Don't assume every client uses the same port.

Mobile: Approve the System VPN Prompt

On Android or iOS, tap Connect or the start button on the client home screen. The first time you connect, the operating system will usually ask to establish a VPN connection or add a VPN configuration. Approve the prompt and return to the client. Check that the connection stays active, then test in a browser. A system VPN icon only indicates that the connection interface is up; it doesn't prove that the subscription's outbound works or that every rule is matching as expected.

If the connection drops immediately after you tap Connect, check the client error message and config load status first. Another VPN on the device, a work profile network policy, or system management restrictions may prevent it from starting. Android app routing settings may also limit the tunnel to selected apps. If the browser is excluded, its traffic won't go through the client. Check which apps are included before importing the same subscription again.

Save TUN for After the Basic Connection Works

TUN uses a virtual network interface to capture more traffic, making it useful for apps that ignore the system proxy. It usually requires service permissions and takes control of routing and DNS. You don't need TUN for a first-time setup. If a browser works through the system proxy but a particular app still can't connect, enable TUN if needed and make sure you've met the client's requirements for service components or administrator permissions. For background, read about network stack concepts in the glossary; refer to the configuration guide for parameter combinations.

Once connected, hold off on enabling launch at startup or background operation. Keep the client window open and have the Connection and Logs pages ready so you can monitor requests. Next, compare what happens in the browser with the connection records to confirm that actual traffic is flowing—not just that a switch is on.

Step 4: Verify the Setup

Check three things: whether the page loads, whether the request reaches the core, and whether it uses the expected outbound. Start with a site you can normally access to make sure the basic network still works, then open one that should use the proxy according to your config. Make fresh requests to both sites. If needed, open a new browser window or reload the page so cached results aren't mistaken for a successful connection. Change one setting at a time and keep results you can compare.

Check Rules and Outbounds in the Connection Log

Open the client's Connection page and refresh the target page in your browser. Look for the new entry. Depending on the client, it may show the destination domain or IP, matched rule, policy chain, and connection status. A request expected to go direct should end at DIRECT; one expected to use a proxy should enter the relevant policy group and use the selected outbound. If connections disappear quickly, check the history or logs. Some clients require a temporary increase in log verbosity to show match details.

Don't rely only on a page loading or a single outbound IP check. The browser may use cached content, and the IP-check site itself may be set to go direct by your rules. An IP check only shows the route used for that request; it doesn't represent every domain, app, or DNS query. For a first setup, compare a few known destinations with the connection log to confirm the basic route works. DNS leak tests and complex routing checks can come later.

Troubleshoot One Stage at a Time

If there are no new connections, don't start by switching outbounds. Check that the connection list has no active filters, then confirm the core is running, the system proxy points to the current client, and the browser isn't using its own proxy settings. If a connection is logged but the logs show a timeout or refused connection, check the selected outbound and subscription status first. If only one site has a problem while others work, note the rule it matched before deciding whether to change the policy.

If the logs show a DNS resolution error, don't paste in an unfamiliar DNS config and replace the whole thing. Save the error, note your current network type and the affected domain, then work through the troubleshooting categories in the FAQ. Remove subscription URLs, node credentials, and other personal information before sharing logs. See the DNS configuration reference for details on nameserver, fake-ip, and sniffing. Avoid introducing too many variables during your first connection.

Disconnect and Next Steps

After verification, note the working config name, proxy mode, and policy group selection. When you update the subscription, return to the Config page and click Update, make sure it loads successfully, then retest your usual sites. If an outbound has been renamed, check that your previous manual selection is still valid. If you enable launch at startup, restart your computer and confirm that the core is actually running—not just that the client window has opened.

On desktop, turn off the system proxy before quitting the client. If you're using TUN, disable it first or follow the client's normal shutdown procedure to release the interface. On mobile, disconnect the VPN from the client. If pages won't load after quitting, check whether the system still has a local proxy configured or whether a setting that blocks connections outside the VPN is enabled. Clean shutdown matters just as much as a clean startup; it keeps leftover settings from complicating your next troubleshooting session.