Clash Setup Guide
Import a subscription → Choose a proxy mode → Connect → Verify traffic. If the client is installed and your subscription is ready, follow these steps to finish your first setup in about 10 minutes.
Before you start, get a Clash-compatible subscription URL from your service provider or a working YAML configuration file. The client reads the configuration, routes traffic, and establishes connections; it doesn’t generate subscriptions or working nodes. If you only have an account, order page, or provider homepage, sign in to the provider’s control panel and look for “Clash subscription” or “Copy subscription URL.”
For your first setup, keep your existing network settings and run just one proxy client. Complete the four steps below before considering options such as launch at startup, TUN, or DNS changes. Changing too many settings at once makes it difficult to identify the cause of connection problems.
Step 1: Import a Subscription and Activate the Configuration
Open the client and go to “Profiles,” “Subscriptions,” or a similarly named page. Find “New,” “Import from URL,” or “Import subscription,” then paste the full subscription URL into the address field. If you’re asked for a name, choose one that’s easy to recognize. Check that there are no extra spaces, line breaks, or punctuation added by a messaging app, then click “Import,” “Download,” or “Save.”
Wait for the client to download and parse the configuration. After a successful import, the profile list usually shows a new entry with a name, update time, or enabled status. Some clients activate imported profiles automatically; others only save them to the list. Select the new profile and choose “Enable,” “Set as current,” or the equivalent to make it active. “Download successful” alone doesn’t mean the profile is in use.
Next, open the “Proxies” page. You should see the configuration’s proxy groups, with available nodes or other groups inside them. Don’t test everything yet; first confirm that the list isn’t empty and there are no parsing errors. If you still see groups from an old configuration, return to the profile page and check which one is selected. If needed, reload the configuration using the client’s reload option, then check again.
Importing a Local File vs. a Subscription URL
If you already have a YAML file, choose “Import from file” on the same page, select the saved file, and activate it as described above. File import is useful when you have a complete configuration; importing from a URL makes it easier to get updates from the source. Don’t save a web page as a configuration file or simply change a file’s extension to make the client accept it. The file’s contents determine its format.
If import fails, start with the error message. For a timeout or download error, check whether your current network can reach the subscription source. For a parsing error, make sure the server returned a Clash-compatible configuration, not a login page, expiration notice, or differently formatted node list. Repeatedly clicking Import won’t fix a format mismatch; go back to the subscription dashboard and select the correct format. For definitions, see subscriptions and configuration files in the glossary.
A subscription URL may contain access credentials. Hide the full URL and QR code in screenshots, and never post them in public discussions. After the first import, keep the default update settings until you’ve verified the connection. Then set an update interval based on your provider’s recommendations. Updates fetch a new configuration, so if you’ve made manual changes, check whether the client will overwrite them.
Before you continue: The profile page shows an active configuration, and its proxy groups appear on the Proxy page. Once both are in place, choose a mode.
Step 2: Choose Rule Mode and a Proxy Strategy
Open the “Proxies” or “Overview” page and find the mode selector. Common options are “Rule,” “Global,” and “Direct.” Some clients use the same English labels. For your first setup, choose “Rule.” This mode uses the configuration’s rules to decide whether each connection goes through a proxy, connects directly, or is handled another way. It’s a good starting point because it preserves the routing logic provided by your subscription.
After choosing a mode, expand the main proxy group. It may be called “Proxy,” “Node Selection,” or something else chosen by your service provider; names aren’t standardized. Select an available node or an automatic selection group already included in the configuration. The main group may point to another group, so keep expanding until you confirm the final selection. Don’t assume a node is selected based only on the top-level group name.
If you see DIRECT or REJECT, check what they mean: DIRECT connects to the destination without a proxy; REJECT blocks the request. These can be valid outcomes for some rules, but they’re usually not the right choice for a beginner’s main proxy group. Leave groups intended for local networks, sites in mainland China, or blocking rules as they are. Don’t change them one by one just to send “everything through the proxy.”
| Mode | How requests are handled | Recommended for first-time setup |
|---|---|---|
| Rule | Routes traffic according to the active configuration’s rules and proxy groups. | Use this first to check both proxy and direct connections. |
| Global | All requests that reach the core are handled by the global policy. | Use temporarily only when troubleshooting by comparison. |
| Direct | All requests that reach the core connect directly. | Don’t use this to test whether a proxy endpoint works. |
Proxy mode and traffic interception are separate settings
The mode decides “where traffic goes after it reaches the core”; the system proxy or TUN decides “how app traffic reaches the core.” Switching to Global doesn’t mean every app on your device is being routed through the client. If a browser isn’t using the proxy, switching between Rule and Global won’t change its route. Keep this distinction in mind; the next step sets up the traffic entry point.
If the client offers a latency test, use it to narrow down your options, but don’t treat the result as proof that a connection works. A successful test only shows that the test request completed at that moment; other sites, protocols, and apps may behave differently. Choose an available option and continue. In Step 4, use the connection log to confirm whether traffic is actually routed as expected. For nested proxy groups and rule order, see rules and traffic routing in the glossary.
Before you continue: Rule mode is selected, the main proxy group points to the intended node or automatic selection group, and it isn’t set to DIRECT or REJECT by mistake.
Step 3: Enable the System Proxy or Connect via Mobile VPN
Once the configuration and proxy groups are ready, start routing app traffic. On desktop, find “System Proxy” on the home screen, in Settings, or in the tray menu, and turn it on. Some clients also require you to click “Start” or “Connect” to run the core. Check that the client is running and leave it in the background. Closing the main window may only minimize the client to the tray; behavior varies, so avoid choosing “Exit” during your first setup.
The system proxy mainly affects apps that follow your operating system’s proxy settings. A browser is usually a good place to start testing. If it has a proxy-switching extension or a separately configured proxy address, check that it isn’t overriding the system settings. Command-line tools, games, and some apps may use their own network routes, so a successful browser test doesn’t mean those apps will use the proxy too.
On Android and iOS, tap the Connect button on the home screen and approve the VPN connection prompt from the operating system. This permission lets the client create a local traffic-routing tunnel; it doesn’t guarantee that your subscription nodes work. After granting permission, return to the client and check that it shows Connected or Running before testing. If your device is restricted by a work profile, parental controls, or device management policies, resolve those restrictions first.
Skip TUN for your first connection
If your desktop browser works through the system proxy, leave TUN off for now. Consider enabling TUN only if you need to cover apps that ignore the system proxy, handle specific protocols, or route traffic more comprehensively. It may require installing a service, granting administrator privileges, or allowing a network extension. Button names and permission steps vary by operating system and client version, so don’t follow instructions written for another platform.
A mobile VPN connection and the separate TUN toggle on desktop don’t need to match one-to-one. The goal is simply to get your chosen client running and routing traffic for the apps you need. If enabling TUN causes network problems, turn it off and return to the system proxy setup you’ve already verified. Then see the full guides for platform-specific permission, routing, and DNS checks.
If you configure a proxy manually, its port must match the port the client is actually listening on. A common example is the local address 127.0.0.1 with mixed port 7890, but these aren’t fixed values you should copy blindly. Use the client’s system proxy toggle when possible. If a port is already in use or the core fails to start, resolve the reported issue instead of changing ports at random across multiple settings pages.
Before you continue: The client core is running, the desktop system proxy is enabled or mobile VPN permission has been granted and connected, and no other similar tool is routing your traffic.
Step 4: Verify the Traffic Route and Test a Connection
Open a new browser tab and visit a site you normally use that should go through the proxy under your current rules. At the same time, open the client’s “Connections” page and find the request by domain name. You may need to select a connection entry to see its details. Check the destination domain, matched rule, proxy group, and final connection chain.
If the page loads and the request used the expected proxy group and node, that request worked. If the log shows DIRECT, first check whether the site was supposed to connect directly; DIRECT under Rule mode doesn’t necessarily mean the proxy is broken. Conversely, a page loading doesn’t prove the proxy worked, since the site may have been accessible without it.
Reload the page during testing so you’re not relying on cached content. Some clients show requests as soon as core connection logging is enabled; others require a separate logging option. If no requests appear, check that logging is enabled and that the display filters aren’t hiding them before deciding whether traffic reached the client. If needed, temporarily enable informational logs, then restore your usual settings once you’re done. Avoid leaving overly detailed logging on indefinitely.
Troubleshoot based on what you see—don’t change settings at random
- No new connection entries: Check that the core is running and the system proxy is enabled. Make sure no browser extension or separate browser setting is sending traffic elsewhere. On mobile, check that the VPN connection is still active.
- Connections appear, but use the wrong policy: Check Rule mode, the main proxy group, and any groups it references. Make sure the profile you just imported is active, not an older entry left in the list.
- The expected node is selected, but requests fail: Try another available node in the same group, then check your subscription status and client logs. If several nodes fail, don’t change DNS, ports, and TUN all at once.
- The browser works, but an app doesn’t: Check whether the app follows the system proxy or has its own proxy settings. If you need broader coverage, configure TUN or check per-app rules using the platform guide.
After verifying the proxy route, visit a frequently used site that should connect directly. Check that local network services and everyday apps still work too. If you use a router admin page, printer, or local development server, make sure those are still accessible. This can catch local requests being sent through the proxy by mistake, rather than only confirming that one external site loads.
An IP lookup can provide additional evidence, but its own request is also affected by your routing rules. It only shows the exit IP for that particular lookup; it doesn’t prove that every app or protocol uses the same route, or establish how DNS requests are handled. For more detailed DNS or TUN checks, use the configuration troubleshooting steps in the full guides. Don’t change every setting at once during your first setup.
Save Your Settings and Disconnect Safely
Make a note of the working profile name, main proxy group selection, and traffic interception method. After that, change one setting at a time so you can roll it back easily. If you want the client to connect at startup, check “Launch at startup” and “Connect on launch” separately; they may be different options. If a phone disconnects when locked, look into background activity or battery restrictions rather than disabling every system optimization before your first connection.
When you’re done, turn off the system proxy before exiting the desktop client, or use the client’s Disconnect option. On mobile, tap Disconnect and make sure the system VPN connection has ended. If websites stop loading after you quit, check whether the system still has a manual proxy pointing to a local port. Restore your previous settings and try again.
Setup is complete when: Requests expected to use the proxy show the right proxy chain in the connection log, while direct connections and everyday apps still work. Your first setup is now done. For platform-specific installation permissions or advanced settings, see the installation and setup guides—there’s no need to import your subscription again.