Clash Setup Guide

1. Import a subscription and activate the configuration

Start with a valid Clash-compatible subscription link. The client reads the configuration and creates the connection; it doesn’t provide proxy service by itself. If you have a service account but no subscription link, look for a “Subscription” or “Clash configuration” option in your provider’s account portal and copy the full URL. If you have a local YAML file, import it through the client; the activation steps are the same.

Open the Clash client and go to “Profiles,” “Subscription,” or the Profiles page. Look for an option such as “New,” “Add,” or “Import from URL.” Paste the link you copied into the URL field. Check that it has no extra spaces, line breaks, or text added by a messaging app. You can give it a name to help you identify it; leave the other options at their defaults, then click “Import,” “Download,” or “Save.” Wait for the download to finish, and don’t add the same link repeatedly.

After a successful import, you’ll usually see a profile card with a name, update time, or selected indicator. Some clients activate the profile automatically; others require you to click the card or choose “Use this profile.” Once it’s active, open the Proxies page and check that its groups and nodes are listed. If the file appears in the list but you haven’t switched to it, the core may still be using the previous configuration. This is an easy step to miss during initial setup.

If the import fails, check whether the problem is the link or the configuration

If the download times out, first make sure your device is online, then retry using the subscription update option from your provider. Don’t post your subscription URL in a public chat for help; its parameters may let others access your configuration. If the client reports a format error, check that you copied a Clash-compatible subscription, not an account sign-in page, order page, or link intended for another client. A successful download doesn’t guarantee a valid configuration; an error page may also be saved as a file.

If the configuration activates but no nodes appear on the Proxies page, check whether the subscription has expired, still includes available servers, and contains remote proxy groups. Remote groups may need to be updated separately. Don’t start by writing node fields manually or using an unfamiliar online converter. Check the error message against the subscription type first. For more on format issues, see the FAQ.

The client now knows where it can connect. Next, choose which connections should use a proxy and which node should handle them. These choices depend on the proxy mode and policy groups.

2. Choose a rule mode and proxy node

Open the “Proxies” page and find the proxy mode at the top of the page, in the main menu, or in settings. Set it to “Rule.” Rule mode is a good place to start: the client uses the rules in the active configuration to send each connection through a proxy, directly, or via another outbound route. These rules come with your subscription, so you don’t need to edit the configuration to get started. If they don’t work for a particular site, adjust them during troubleshooting.

After choosing a mode, find the main proxy group. It may be called “Proxy,” “Proxy Selection,” or “Node Selection,” or have a name chosen by your subscription provider. There’s no standard name across all clients. Open the group and select a node you’re authorized to use. If it includes subgroups such as “Auto Select” or “Fallback,” start with the subscription’s default selection. For troubleshooting, choosing a single node makes it easier to identify the result.

Policy groups and nodes are at different levels: a top-level group may select another subgroup, which then points to a specific node. So even if a node has a selected icon, check the full chain to see which route the top-level group actually uses. If the main proxy group selects DIRECT, connections routed through it will go direct. Setting the mode to “Rule” doesn’t automatically send them through a proxy.

Use node latency tests as a guide, not proof of connectivity

Click “Test,” “Latency Test,” or the refresh icon near a policy group and wait for the result. The test usually sends a request to an address configured in the client; it doesn’t measure every website’s speed or your download bandwidth. Start with a node that returns a result—you don’t need to keep chasing the lowest number. If every node times out, the test address, your current network, or the subscription may be the problem. A failed test alone doesn’t prove that every node is down.

Global mode changes the outbound route for connections that reach the core; it doesn’t automatically capture traffic from every app on your device. Traffic that never reaches the client won’t be handled just because you switch to Global. Stay in Rule mode, make sure a node is selected, then enable the system-level or app-level traffic entry point.

3. Enable the proxy connection

On desktop, return to the home or status page and check that the core is running and the active configuration loaded without errors. Then turn on “System Proxy.” This sets the system’s proxy address so apps that follow those settings send their requests to Clash. Some clients start the core automatically; others require you to start it manually. Check the client status and logs rather than looking for an identical button in every app.

Next, return to your browser and open a new tab for testing. If you have a proxy-switching extension installed, make sure it isn’t forcing a different proxy address. Don’t run another proxy client or VPN at the same time, as they may overwrite each other’s system settings. For your first test, use just one traffic entry point so it’s easier to tell which app is handling the connection.

Desktop: Start with the system proxy; consider TUN if needed

The mixed port accepts HTTP or SOCKS proxy connections from apps on your device. A common value is 7890, but check the client’s current settings. You usually don’t need to enter a port manually to test in a browser. If an app requires its own proxy settings, enter the local address and port shown in the client, along with the correct proxy type. Don’t use the proxy server’s port as the local listening port; they serve different purposes.

Not every app uses the system proxy. If your browser works but a game or command-line tool still connects directly, first check whether the app supports its own proxy settings. Consider TUN mode if needed. TUN routes traffic through a virtual network interface and may require administrator access, a service component, or additional network permissions. It can handle a wider range of traffic, but also adds routing and DNS settings to check. You don’t need to enable every option for your first connection.

Mobile: Connect and grant system permission

Android and iOS clients usually have a “Connect” or start button on the home screen. After you tap it, the system may ask to add a VPN configuration or establish a VPN connection. Confirm the request was initiated by the client you just installed, then allow it. Return to the app and wait for its status to show Connected. Whether a VPN icon appears in the status bar depends on your system and display settings, so check the client status as well instead of relying on the icon.

If another VPN app is already connected on your phone, disconnect it before trying again. Some Android clients also let you proxy or bypass specific apps; for your first test, make sure your browser isn’t excluded. If the connection drops only when the app goes into the background or the phone locks, check battery optimization and background permissions. Don’t change a lot of system settings before you’ve tested a foreground connection.

At this point, all three requirements should be met: the configuration is active, a node is selected, and the traffic entry point is enabled. Next, test an actual request. A Running status is only the starting point, not proof that everything works.

4. Test websites and check connection logs

First, visit a website that normally works without a proxy to make sure your basic internet connection is fine. Then try a site that requires a proxy on your current network. Use a trusted website, and don’t enter account credentials or download unfamiliar files just to test. If the page was already open, refresh it or open it in a new tab so cached content isn’t mistaken for a new connection. Once the page loads fully, check how the request was handled.

Switch back to the client and open “Connections,” “Active Connections,” or the Connections page. Find the domain you just visited. If the list updates quickly, open it before refreshing the site in your browser. Select the entry to check the matched rule, policy group, and final outbound route. Depending on the client, these details may appear in a side panel, a route field, or the log. For a site that requires a proxy, the route should use the expected proxy policy, not DIRECT.

Some short-lived connections disappear from the active list quickly. Others show only a destination IP, not the domain. In these cases, check the regular-level logs too. Don’t assume the connection failed just because an entry wasn’t visible for long. Before sharing logs for help, hide your subscription URL, account details, and any browsing history you don’t want to make public. You don’t need to leave verbose debugging logs on for a basic check.

Choose your next step based on what you see—don’t keep reinstalling

If the website loads and its connection details show the expected node, the basic setup is working. If it doesn’t load but the client shows the request, traffic is reaching the core. Try another node and check whether an unsuitable direct or reject rule matched. After switching nodes, refresh the page. If needed, close only existing connections to that site so they don’t keep using the previous route.

If the site won’t load and the connection list and logs never show its requests, check the traffic entry point first. On desktop, make sure the system proxy is still enabled and check for separate proxy settings in the browser. On mobile, confirm the VPN is actually connected and the browser hasn’t been excluded by app routing. If only some apps fail, check how those apps handle proxy traffic before replacing the entire subscription or reinstalling the client.

You can briefly switch to Global mode for comparison, but first make sure the global policy group has a working node selected. If Global works but Rule doesn’t, focus on the routing rules and policy group selections. This is a troubleshooting clue, not a reason to keep using Global. When you’re done, switch back to Rule and check that common sites use the expected outbound routes.

Checking your public IP can provide extra evidence, but it isn’t the only test. In Rule mode, the IP lookup site may be routed directly, so seeing your regular network’s IP doesn’t necessarily mean the proxy failed. Likewise, one site loading doesn’t mean every app on the device is using the proxy. Consider the website result, connection log, and matched rule together; they’re more reliable than a status icon or a single IP lookup.

You can stick with this basic setup; there’s no need to add custom rules right away. For subscription updates, node timeouts, leftover system proxy settings, and other specific issues, use the FAQ to troubleshoot by symptom. To understand how policy groups, DNS, TUN, and configuration files fit together, read the complete guide, from beginner to advanced. Avoid changing too many settings at once before confirming the basic connection works.