Clash Setup Guide
Import a Subscription and Verify Your Connection
Set up Clash for the first time: import a subscription → choose a proxy mode → connect → verify that it works. Start by getting a browser request through, then configure traffic routing for other apps. If you already have a client and a working subscription, follow these steps to get started quickly.
1. Import a Subscription and Activate the Configuration
Before you begin, install a client and get a subscription URL or local configuration file from your provider. The client reads the configuration, applies its rules, and establishes connections; installing it alone doesn't give you a working proxy. A subscription URL is not an account sign-in page, purchase page, or ordinary web link. You need a configuration link explicitly marked as compatible with Clash or the client's current core. If you don't have a configuration yet, you can explore the interface, but there's no need to keep toggling the connection on and off.
Add the URL on the Subscription or Configuration Page
Open the client and go to “Subscription,” “Configuration,” or “Profiles.” Look for an option such as “New,” “Add,” or “Import.” If the page asks for an import type, choose URL or remote configuration, then paste the complete subscription URL into the address field. The name is just for identifying the configuration, so use a recognizable source or purpose; don't paste the link into the name field. Before saving, check both ends of the URL for extra line breaks, spaces, or text added by a messaging app. Then choose “Import,” “Download,” or “Save.”
Wait for the client to download and parse the configuration. On success, the list usually gains an entry with a name, update time, or other summary. Select the entry or tap its activation button to make it the current configuration; downloading it doesn't always activate it. Then open the proxy page and confirm that the configuration's proxy groups are visible. If the page is still blank, return to the configuration list to check which entry is selected, then look for a parsing error.
If you have a local YAML file, use “Import from file” rather than the URL field. Select and apply the configuration after importing it. File imports usually aren't linked to a remote update URL; whether you can update them later depends on the client and configuration source. Don't use a file path as a subscription URL. For QR code imports, check the decoded result first and confirm it's a configuration URL before letting the client read it.
Import Failed? First Find Out Where It Failed
A “Download failed” message usually means the client couldn't retrieve the remote content. Check that the URL is complete, the subscription is valid, and the current network can reach it. “Parsing failed” means the content was retrieved, but it may be a web page, an error message, or an incompatible configuration. If the client reports an unsupported format, check which core it's using. Don't delete fields at random just to clear the error. See the protocol and core reference for how formats and cores relate. For now, focus on loading a compatible configuration successfully.
Once the configuration is active and its proxy groups are visible, move on to the next step. For now, leave DNS, custom rules, and other advanced options alone. Keeping the provider's defaults makes it easier to pinpoint problems during testing.
2. Choose Rule Mode and a Proxy Group
Go to the home screen or proxy page and find “Mode,” “Operating mode,” or “Mode.” Common options are Rule, Global, and Direct. For your first setup, choose Rule mode. The core uses the current configuration's rules to decide whether each request goes direct, through a proxy, or is rejected. Rule mode doesn't send every request through the same exit, and it doesn't mean every app on your system is being routed through the client.
Choose an Operating Mode, Then Check the Group's Policy
After choosing Rule mode, open the proxy group list. Group names are set by the configuration author and may refer to a use case, region, or app, so there's no single “correct” name to look for. Check the main selection group or the entry group named in the configuration notes, then select a connection in a group that allows manual selection. The selected item usually has a checkmark, a changed border, or another highlight. Make sure the marker moves to your chosen item rather than just opening its details.
Some proxy groups use automatic selection, failover, or load balancing, so you may not be able to pin a single connection. If an option inside a group is itself another group, open it to see where the final policy leads. DIRECT means a direct connection, not a remote proxy. And a group name that suggests a particular use doesn't guarantee that a given website will use it; check the connection log in the final step to see what actually happened.
If the client offers latency testing, use it to spot connections that time out or can't be reached. A successful test only confirms that a specific probe completed. The latency in milliseconds isn't a download speed and doesn't guarantee that your target app will work. For your first setup, choose a connection that passes the test, then check it with a real webpage. If the test feature itself isn't available, use the logs and a real request instead; there's no need to keep testing until every entry shows a number.
| Operating mode | How it works | When to use it |
|---|---|---|
| Rule | Applies the policies defined by the configuration. | A good starting point for everyday use and the checks in this guide. |
| Global | All requests routed through the core use the global policy, subject to traffic routing and related settings. | Use temporarily to compare the effect of rules, then switch back to Rule mode. |
| Direct | Requests handled by the core use a direct connection. | Use when a direct connection is needed; this does not turn off the system proxy. |
At this point, the client knows how to route a request once it receives it. Whether the request reaches the client depends on traffic routing, which is the next step. Keep the current mode and proxy group selection as they are, and configure only the connection entry point to avoid changing multiple variables at once.
3. Connect and Route Traffic
First, make sure the core is running on the home screen and the current configuration is loaded. Some desktop clients start the core automatically; others require you to click “Start” or “Connect.” The core running, a proxy group selected, and the system proxy enabled are three separate states. If any one is missing, the interface may look fine even though no requests reach the client. While testing for the first time, quit any other active proxy or VPN clients to reduce conflicts between system proxy settings, routes, and virtual network adapters.
On Desktop, Start with the System Proxy
Find “System Proxy” on the desktop client's home screen or in settings, then turn it on. This sets the system proxy for apps that follow the system settings; most browsers can use it. Go back to your browser and test in a new tab. If the browser has a separate proxy setting, proxy extension, or manual SOCKS address, it may ignore the system setting. For your first test, have the browser use the system proxy to avoid stacking multiple routes.
The system proxy doesn't route all device traffic. Some command-line tools, games, and other apps don't use it, so “the browser works, but one app still uses its usual route” doesn't necessarily mean the subscription is broken. Test the browser first, then check whether the app supports its own proxy settings or needs TUN. Don't change every port, DNS setting, and rule to fix one app. Keeping a verified route stable makes further troubleshooting easier.
Enable TUN Only If You Need It
TUN routes traffic that matches its routing conditions through a virtual network interface, and can cover more apps that ignore system proxy settings. If you need it, find “TUN mode” or “Virtual adapter” in settings, then follow the client's prompts to install a service, grant system permissions, or enable the required components. Permissions vary by operating system, so follow the prompts for your client. If you see a permissions error or the service isn't running, fix that specific issue before trying the toggle again.
You don't need to enable both the system proxy and TUN to finish your first setup. If the browser works through the system proxy, note the current state and test TUN separately. Other VPNs, virtual machines, or corporate networking tools can affect routing. If a connection that worked before drops after you turn TUN on, turn TUN back off to restore the verified setup. See the protocol and core reference for details on how TUN, DNS, and rules interact. You don't need to adjust all of them during your initial setup.
On Mobile, Approve the System VPN Request
Once you've selected a configuration and proxy in the mobile app, tap “Connect” or “Start.” The first time you connect, the system usually asks to set up a VPN connection. Make sure the request comes from the client you just installed, then approve it as prompted. Return to the app to check the connection status, and confirm the system status bar or VPN settings show an active connection. A VPN icon means the traffic routing interface is active; it doesn't prove that the selected remote connection works.
If the connection drops right after you approve it, first check that no other VPN app is routing traffic, then look for configuration or permissions errors in the client. Android devices may also restrict background activity; check battery and background permissions only if the connection drops when the screen locks. On iOS, check the active connection in VPN settings. Don't stop at the status icon—the next step is to verify that actual requests follow the expected policy.
4. Verify the Request Path and Access
Keep the client running and open a familiar website that should be accessible in your browser. Open a new tab or reload the page so you don't just see cached content. Then return to the client's “Connections,” “Active connections,” or logs page and find the request for that domain. Fields vary by client; focus on the destination domain, matched rule, policy group, and final connection rather than just the traffic counter on the home screen.
Match the Page Load to Its Connection Log
If the page loads and the connection log shows that the request reached the client, check whether the policy matches what you expect. In Rule mode, a website showing DIRECT may be completely normal because the configuration may send it direct. Check a destination that the configuration explicitly routes through a proxy. If you're unsure how the rules handle it, look at the matched rule instead of assuming that a working website means all traffic is proxied.
An exit IP lookup can provide a useful clue, but it isn't the only way to verify a connection. Rules may send the lookup site direct, browser caching can affect results, and IPv4 and IPv6 may use different exits. A more reliable approach is to match a specific request to the client log and confirm the destination, rule, and policy form a complete path. To test a desktop app, generate a new request in that app and check its log entry; a successful browser test doesn't verify the app.
If the Connection Fails, Check in This Order
If a webpage won't load, go back to the first step and make sure the current configuration is still active and its latest update succeeded. Then check that the proxy group has a working connection selected, rather than having switched to Direct or another policy by mistake. Next, confirm the core is running and the desktop system proxy or mobile VPN is connected. Finally, inspect the request: if there's no log entry, check whether the app's traffic is reaching the client; if there's an entry but the connection fails, look at the remote connection, protocol compatibility, and the specific error in the logs.
If only one website or app fails, test another known destination to tell a local issue from a general connection problem. If the issue started after switching networks, disconnect and reconnect so the client can establish a connection on the current network. Change one thing at a time—for example, change only the proxy selection or turn off only TUN—then repeat the same request. Changing the mode, DNS, ports, and subscription all at once makes the result hard to interpret. For protocol support, DNS, or complex routing, see the protocol and core details in the in-depth guide.
Save Your Everyday Settings After Verification
Once everything checks out, enable subscription auto-updates and client startup options if you need them. Updates may change proxy group members or rules, so if something behaves differently afterward, check that your current selection is still valid. Client startup, core startup, and automatically enabling the system proxy may be separate settings. After restarting your device, run a quick check rather than assuming every toggle was restored.
Before closing the desktop client, turn off the system proxy so the system doesn't keep sending requests to a local entry point that's no longer running. On mobile, disconnect normally in the client and check that the system VPN has disconnected too. To change subscriptions later, start again with importing a subscription. To change only the operating mode, go to choosing a mode; there's no need to reinstall the client. Keep a verified setup as a reference for future troubleshooting.