Clash Setup Guide

Step 1: Import a subscription

Open your subscription provider’s account page and find the subscription option for Clash or Mihomo. Use the page’s copy button to copy the full URL. Your account home page, purchase history, and subscription URL are different things. After copying, make sure the URL has no leading or trailing spaces, line breaks, or extra text. If the provider offers multiple formats, choose one compatible with your client’s core; don’t import a format just because its name looks similar.

Create a configuration from a URL

In the client, open the Configuration or Subscription page and find Import, Add, or a plus button. Choose Import from URL, paste the copied address, and enter an easy-to-recognize local name, such as “Daily subscription.” The name only identifies the configuration; it doesn’t affect node connections. Save and wait for the client to download and parse the content. When it’s ready, you’ll usually see a new configuration card with its name, update time, or update controls.

Some clients have a Download button next to the URL field; others require you to save first and update manually. Look for a clear success message rather than assuming the content downloaded just because a card appeared. If there’s an error, check whether the download failed or the content couldn’t be parsed. For a download failure, verify the URL, subscription status, and access to the provider from your current network. For a parsing failure, confirm the response contains configuration data rather than a sign-in or error page.

Set the imported configuration as active

After the download succeeds, click the configuration card you just added, or choose an option such as Use or Activate from its menu. Look for a selected border, check mark, or active status, then open the Proxy page and check the policy groups. If the card is present but inactive, the client may still be using the previous configuration, so you could end up choosing nodes from outdated content. For your first setup, keep one clearly identified configuration active to avoid switching between similar names.

If you received a local file, use the file import option on the same page and select the complete YAML configuration from your provider. A snippet containing only node details may lack the policy groups, rules, and base settings needed to run; changing its file extension won’t make it a complete configuration. After importing, activate it and confirm the Proxy page shows its contents. Local files usually don’t sync with remote subscription updates, so follow your provider’s instructions for future updates.

If you need to convert another format into a Clash configuration, read the subscription conversion FAQ first to check format support and link privacy. For repeated download failures, follow the full subscription troubleshooting guide; there’s no need to change DNS, ports, and proxy mode at the same time. Once the active configuration looks good, continue to the next step and choose how to route requests.

Step 2: Choose a proxy mode

Open the client’s Proxy page and find the Rule, Global, and Direct mode options. For your first setup, choose Rule. The current configuration’s rules determine whether each request goes direct, through a proxy, or to another policy. Rule mode doesn’t guarantee that all sites in mainland China go direct or that all sites outside China use a proxy; that depends on the configuration. After selecting this mode, make sure the policy group referenced by the rules has a suitable route selected.

Global mode usually sends requests that reach the core through a single global policy. Use it to temporarily compare rule-based routing with a single proxy route; it won’t capture apps that aren’t already sending traffic to the client. Direct mode usually connects requests that reach the core straight to their destination; it doesn’t turn the client off. Knowing these limits helps you distinguish rule issues from traffic-capture or node problems.

Choose an outbound in the main policy group

Expand the main selection group configured by your provider on the Proxy page. Its name may include “Proxy,” “Node selection,” or other custom wording. Don’t rely on the name alone; check the configuration notes and, later, the policy chain shown in connection details. For a manual group, select a node and confirm the selection marker moves. If you select another policy group, expand that too until you find an available node or a clear automatic selection rule.

Automatic latency testing, failover, and load balancing are different policies; you don’t need to reconfigure them for your first connection. If your subscription already includes an automatic group, start with it and check which node it selects. A manual group won’t necessarily switch nodes when one is unavailable. If a test fails, try another known-good option rather than cycling through every mode. Learn the finer points of policy groups after the basic connection works.

Test node latency: check reachability first

Find the latency test option next to the policy group and run it once. Wait for the results to refresh. The client typically tests a candidate node by requesting a specified test URL; the result helps show whether that route was reachable at the time. A timeout only means the test didn’t complete as expected—it could also be caused by the test URL, DNS, or server status. A low latency in milliseconds doesn’t mean faster downloads or guarantee that every service will work.

For your first test, choose any node that completes the test; there’s no need to keep testing to find the lowest number. Avoid comparing results during a large download or obvious network congestion, and don’t run multiple tests at once. Note the selected node and use it for the connection and web tests that follow, giving you a consistent baseline. If every node times out, check the subscription first, then follow the node timeout steps in the troubleshooting guide.

At this point, the client should be in Rule mode with a clearly selected main policy group. This determines how requests are handled once they reach the core, not which apps send traffic to it. Next, enable system traffic capture and test a real web request.

Step 3: Connect

First confirm the client core has started and there are no configuration load failures or port conflict warnings. Some desktop clients start the core when you open the app; others require you to click a Start button on the home screen. Seeing the app icon alone doesn’t confirm that the core is running. Keep the client window open during your first connection so you can check its status and any errors, then follow the steps for your device.

Desktop: Enable the system proxy

On the client’s home or Settings page, find and enable System Proxy. This usually points your operating system’s proxy address to a port listening on the local client, so browsers and apps that follow system proxy settings send their requests through it. If the system asks to approve a network configuration change, grant permission only after confirming it’s the client you just opened. Then check that the setting stays enabled instead of switching back off.

You don’t need to enter every port manually for your first setup. Keep the client’s default listening settings and make sure the same client is managing the system proxy. If you previously set a proxy manually in your operating system, note the original values and check whether they still point to old software or a stopped process. The port must match what the current client is actually listening on; don’t set every device to 7890 just because one guide uses that number.

The system proxy doesn’t cover every app. Some terminal tools, games, and apps with their own network stack may ignore it. If your browser works but one app doesn’t, check that app’s proxy settings before assuming the node is unavailable. For port settings and conflicts, see Clash port troubleshooting. Start by testing in a browser that follows the system proxy, then decide whether you need broader traffic capture.

Mobile: Connect and approve system access

On your phone, return to the client’s home screen and tap Connect. The first time, the system usually asks to add a VPN configuration or establish a VPN connection; follow the prompt to approve it. Here, VPN refers to the system’s traffic-capture mechanism, not an automatic source of usable nodes. You still need the configuration and policy selection from the first two steps. After granting permission, check the client’s connection status and look for the corresponding VPN indicator in the system.

Other VPNs, filtering tools, or network booster apps on the same device may compete for the same traffic-capture slot. For a clear result, leave only the connection you’re testing active. If the connection drops soon after you switch to another app, complete a test in the foreground first, then check battery restrictions and background permissions in system settings. Don’t change power-saving, DNS, and routing settings before confirming that the basic connection works.

TUN mode: Consider it after basic testing

TUN captures traffic through a virtual network interface and can cover apps that don’t follow the system proxy. Whether it works depends on the client, platform permissions, and routing settings. For your first desktop setup, use the system proxy and leave TUN off. Don’t assume the mobile system VPN and a desktop option with the same name work the same way; follow your client’s instructions.

If you need TUN on desktop, first complete the browser test in the next step and note the working setup. Then enable TUN on its own and grant any required service or permission access. Change one setting at a time and retest the same destination; if something breaks, revert to the last working setup. For now, just confirm that the client is running and system traffic capture is enabled, then move on to testing real traffic.

Step 4: Check that it works

First open a site you can normally access directly to make sure your local network is working, then visit a service you want to test through the proxy. Choose a familiar page where you can clearly tell whether it loaded, refresh it, and wait for it to finish. A Running status only means some components have started, and a VPN indicator only means traffic capture is active. To confirm the setup works, check the route taken by the actual request.

Check whether the request reached the client

Keep the target page loading and switch to the client’s Connections page to find the request for its domain or process. Some clients show only active connections, so a short-lived request may disappear quickly. Refresh the target page and check immediately; if request logs are available, use the time and domain to find it. Don’t mistake a background request for the page you’re testing—look for the destination you just opened.

Once you find the request, check its matched rule, policy group, or connection chain and confirm it uses the expected node. Direct connections to sites in mainland China and proxy connections to test destinations are common configuration goals, but aren’t guaranteed by every subscription. If a destination that should use the proxy shows DIRECT, check the active configuration, mode, and rule match first. If the request uses the proxy but still fails, investigate the node, route, or destination service.

Choose your next step based on what you see

A public IP lookup can offer a useful clue, but it can’t prove that every app is using the proxy. With rule-based routing, different sites may use different exits. Cached pages and existing connections can also make a change hard to see right away. For a more reliable check, refresh the test page, inspect its policy chain in the client, and match the browser result to the recorded route.

Update your subscription and disconnect

Once access works, return to the configuration page and check the auto-update interval. Follow your provider’s recommendation; if they haven’t specified one, avoid very frequent polling. After a manual update, confirm the same configuration is still active and the main policy group selection hasn’t changed because a node was renamed. Subscription updates usually replace remotely managed content, so direct edits to rules in a subscription file may be overwritten. To customize rules, learn how your client handles overrides or configuration merges.

When you no longer need the desktop proxy, turn off System Proxy before quitting the client, so the operating system doesn’t keep pointing to a local address that’s no longer listening. On devices using TUN, stop traffic capture as well. On mobile, disconnect in the client and confirm the system connection has ended. If no web pages load afterward, first check for leftover proxy settings rather than reinstalling the app.

For help with a specific concept, check the FAQ. If you’ve followed the steps and still can’t get online, open the Clash troubleshooting guide and work through the checks for no internet access, node timeouts, subscription failures, slow speeds, or DNS issues. Keep the last known working setup and change one thing at a time to distinguish configuration issues from network changes.