First-Time Setup · 4 Steps

Clash Setup Guide

Import a subscription → choose a proxy mode → connect → verify it works. If the client is installed and you have a valid subscription, follow these steps to get set up in about ten minutes.

Before You Begin: Client and Valid Config

Open the installed client and make sure you can reach its main screen. A Clash client reads the config, applies rules, and routes traffic; installing the software does not provide proxy nodes. Before continuing, get a subscription URL from a trusted config provider or a YAML config compatible with your client’s core, and make sure the service is active.

Subscription URLs often contain personal credentials used to retrieve your config, so treat them like passwords. Use the provider’s copy button, and don’t post the URL in public forums or paste it into an unfamiliar online conversion tool. If several formats are available, choose one explicitly labeled Clash or mihomo. Browser subscriptions and formats made for other clients may not import directly.

Before setup, quit any other proxy client or VPN that’s routing traffic, and keep your current network connection working. For now, leave DNS, routing, and other advanced settings alone. This makes it easier to tell which setting caused a change. First, get your browser working; then decide whether to route traffic from other apps. Not sure about a term? Open the quick glossary as you read.

1. Import a Subscription and Activate the Config

Paste the URL and wait for the config to download

Find the “Subscriptions,” “Configs,” or Profiles page in the client’s sidebar or bottom navigation. Click “Add,” “Import,” or the plus button. If prompted to choose an import type, select URL, then paste the full subscription URL. Give it a short name that identifies the source, and leave the update interval at its default for now. Check for spaces or line breaks at either end of the URL, then click Confirm or Download.

Importing usually means fetching the remote URL, then parsing the downloaded config. Wait for the process to finish; don’t click Add repeatedly. When it succeeds, you should see a config card or subscription entry. Some clients also show when it was last updated. An entry alone doesn’t mean the config is active: click “Use” or “Activate,” or select the card, and make sure it’s marked as the current config.

Next, open the “Proxies” or “Proxy Groups” page. If you can see group names and candidate nodes, the client has read the relevant config data. Some clients show proxy groups only after the core starts; if so, start it as prompted, but don’t enable the system proxy yet. Don’t assume the import worked just because a success message appeared—confirm that the config is actually running.

Import a File or Troubleshoot an Error

For a local file, choose “Import from file” on the same config page, find the YAML file in your downloads folder, and load it. A subscription URL and a local file are two ways to provide a config; you generally only need one. Importing a file may not preserve a remote update URL. Future updates depend on the file and client, so don’t expect automatic renewals.

If you see “Parse failed,” first check that you chose a compatible format. An expired link, login page, or service expiration notice may download as text, but none of these is a config. For a timeout, check whether your current network can reach the subscription source and confirm you copied the full URL. Don’t delete config fields to fix a format error or switch to Global mode repeatedly: the config hasn’t loaded yet, and changing modes won’t fix a download or parsing issue.

If your provider requires a proxy to update subscriptions but you don’t have a working config yet, use a legitimate alternative import method provided in its instructions or connect through an accessible network. Avoid the catch-22 of needing a connection to download the config and needing the config to connect. When the import is done, return to the proxy groups page and check the contents. For common errors, see troubleshooting. Once you can see the nodes, choose a mode.

2. Choose a Rule Mode and Proxy Node

Choose Rule mode, then check your proxy group

Find “Mode” on the main screen, in Settings, or in the tray menu. For your first setup, choose “Rule” or “Rule mode.” This mode uses the rules in your current config to decide whether each connection goes direct, through a proxy, or is blocked. It’s a common starting point for everyday traffic routing, but the config determines the actual outcome. It doesn’t mean every site will use a proxy or that the client can identify what every app is for.

“Global” mode usually sends routed traffic through the global proxy group, which can help you briefly check whether rules are affecting the result. “Direct” mode usually sends routed traffic straight to its destination. Switching to Global won’t route apps that aren’t already sending traffic to the client, and it doesn’t replace the system proxy or TUN. For consistent testing, stay in Rule mode rather than changing both the mode and node every time a site fails to load.

Next, open “Proxy Groups” and find the main group that selects your outbound route. It may be called “Node Selection,” “Proxy,” or something else chosen by your config provider. Expand it and select an actual node. If DIRECT is listed, that’s a direct-connection policy, not a proxy node. If the main group points to another policy group, check the selection in that nested group too; seeing a group name doesn’t mean you’ve chosen an outbound node.

Test reachability, not download speed

Click “Latency Test” or the speed-test icon in the group and wait for results. Rule out nodes that consistently time out, then choose one that completes the test. The result usually measures how long a request to a test address takes; it doesn’t tell you the actual download speed. A node with a low latency result may still buffer video or download files slowly because of bandwidth, congestion, or the destination site. Test with real traffic to know for sure.

If the config includes an “Auto Select” group, you can keep its automatic selection and check whether the current node works. For a manual group, click a candidate and make sure the selection indicator changes. Don’t leave the page just because you expanded the list: in some clients, expanding, testing, and selecting are three separate actions.

You should now have two clear results: Rule mode is active, and the group responsible for proxying traffic points to a working node or an automatic selection group. If all candidates time out, check the service status, your network, and the system clock before editing rules. For a full explanation of policy groups and rule priority, see the cross-platform guide. Keep the current config for now and move on to routing traffic.

3. Connect and Route Traffic

Enable the system proxy on desktop first

Return to the main screen and confirm that the core is running. If there’s a separate Start button, click it first. Then turn on “System Proxy.” Some clients combine starting the core and setting the system proxy in one Connect button; check the status to make sure both are enabled. A running core means the local proxy service is up—it doesn’t mean your browser or other apps are sending requests through it.

On Windows and macOS, browsers that follow system proxy settings will usually use this route. Support varies across Linux desktop environments and apps, so you may need to check your desktop proxy settings. If a browser has a fixed proxy configured, switch it back to using the system proxy so it doesn’t keep connecting to an old client port. Test with one browser first; there’s no need to configure command-line tools or background services yet.

Once the system proxy is on, open a new browser tab and visit the site you want to test. Existing long-lived connections may keep using their previous route, so refreshing an old page may not show the change. If startup reports that a port is already in use, quit other proxy programs, check for lingering processes, and try again. Don’t change the client port without also updating any proxy address you entered manually in an app.

Approve the VPN on mobile; use TUN only if needed

Android and iOS clients usually establish a system VPN connection when you tap “Connect.” The first time, the system asks for permission to add a VPN configuration or establish a connection. Check which app is requesting access, then approve it. Return to the client and check its connection status and the system status bar. A VPN icon means the tunnel is up; you still need to check rules and real requests to confirm how traffic is routed.

On desktop, consider TUN mode only if you need to route traffic from apps that ignore the system proxy. It may require administrator access, service mode, or support for a virtual network interface. Install or start the service as prompted by the client, then enable TUN. First test the system proxy path with TUN off, then try TUN. This helps distinguish a node problem from a routing problem. Follow the client’s instructions on whether to leave both options enabled; don’t stack them without checking.

Disconnect other VPNs while testing to avoid routing conflicts. Corporate networks and managed devices may restrict proxies and virtual network adapters; follow your device management policies. If enabling the connection immediately blocks all websites, turn off the system proxy or VPN you just enabled, confirm that your regular network works again, and then check the logs. Don’t keep changing DNS and routing settings while the network is down. Once traffic is routed, the final step is to confirm requests are actually going through the client as expected.

4. Verify Rule Matching and Real-World Access

Match a web request to its connection log

Open the client’s “Connections,” “Active Connections,” or log page. Then, in your browser, visit a site you’re allowed to access and expect the current config to route through a proxy. To avoid cache issues, open a page you haven’t visited before or start a new browser session. In the client, find the matching domain and check the matched rule, proxy group, and final node. Some clients show these details in a separate connection view.

Seeing a request doesn’t mean it went through a proxy. If the final policy is DIRECT, the connection was routed directly; REJECT means it was blocked. A proxy group name may not be the final node, so expand the policy chain to see the actual outbound route. A short-lived connection may disappear from the active list. If supported, temporarily enable info-level logs and repeat the request, then restore the previous log level.

Now visit a site that the config is expected to route directly, and compare the two log entries. Seeing both requests follow their expected policies is stronger evidence that traffic routing is working than checking just one exit IP. An IP lookup only shows the route used by that lookup request; it can’t prove that every app uses the proxy. Even if the browser works, games, terminal tools, and other apps may use separate network settings, so check each one with its own request.

Troubleshoot by symptom; change one thing at a time

If a page won’t load and there’s no matching connection in the client, check that the system proxy is still on, the browser follows system settings, and another proxy program hasn’t overridden them. If you’re using TUN, check the virtual interface and service status. If the client shows the connection but the request fails, check the final node and timeout details in the logs. Try a node that passed the connectivity test, then retry without changing the mode or other settings.

If the logs show a DNS resolution failure, first check whether normal network traffic is also having DNS issues, then review DNS settings using the client’s instructions. Don’t replace every DNS server just because a page won’t load: node failures, rule rejections, and DNS problems need different fixes. If the browser works but one app doesn’t, check how that app is routed rather than importing the entire subscription again. For more help, see Clash connection and internet access issues.

After the connection works, test it with something you actually use: open a familiar site, play a short video, or download a file you’re allowed to access. Check that it stays stable; one latency result isn’t a substitute for real-world use. To confirm the DNS route, check the DNS config and use network diagnostic tools. A VPN icon or one test page isn’t enough to draw a conclusion. See DNS and networking terminology for related concepts.

Record the current config name, mode, main proxy group selection, and routing method so you can reproduce the setup later. Before normally quitting the desktop client, use its option to turn off the system proxy. If your browser loses its connection after an unexpected quit, check whether the system still points to a local proxy that has stopped running. Subscription import, policy selection, traffic routing, and request verification now form a complete setup. For more, see platform differences and advanced configuration.