Clash Setup Guide
Import a subscription, choose a proxy mode, enable the connection, and verify the result. Follow four steps to set up a connection you can troubleshoot. Allow about 10 minutes for your first setup.
- Client installed
- Compatible subscription or YAML file
- Working internet connection
Import a Subscription and Enable the Configuration
Clash needs a configuration to know which proxy exits are available, how policy groups are organized, and which requests should connect directly. Installing the client does not create a usable subscription. Before you start, get a compatible link from your subscription provider or a YAML configuration you know works. Use a subscription only from a source you trust and are authorized to access.
Create a Configuration from a Subscription Link
In the client’s sidebar or bottom navigation, open Subscription, Configuration, or Profiles. Look for Add, New, or Import from URL. Paste the full link into the URL field, give the configuration a recognizable name such as Daily, then click Import, Download, or Save. Some clients can import from the clipboard; make sure it contains the subscription URL first.
Wait for the download to finish. The configuration should appear in the list as a card or row, usually with its name and last-updated time; some subscriptions also show usage details. Click Enable or Use, or select the configuration to make it active. Adding a configuration and enabling it are separate steps: if the Proxy page still shows old content, return to the list and check which configuration is selected.
Next, open the Proxy page and check for policy groups and available nodes. Group names depend on the configuration and may include PROXY, Auto Select, or custom names; they don’t have to match this guide. If groups and nodes are visible, the client has loaded the configuration. That doesn’t mean you’re connected yet—you still need to choose a mode and an exit.
Import a Local File
If you have a .yaml or .yml file, choose Import File on the same configuration page, open it in the system file picker, then enable the configuration. Don’t paste a subscription link into the editor as if it were YAML, and don’t just rename a file in another format with a YAML extension. Changing the file extension doesn’t change its contents, so an incompatible format will still fail to parse.
If the import fails, read the error message carefully. A network timeout usually means the subscription URL can’t be reached from your current network. For an authentication error, check that the link is still valid in your provider’s dashboard. If the error mentions YAML parsing, make sure you used the compatible configuration import option—not a webpage URL or a link in another subscription format. Keep any field names and line numbers from the error; they can help with troubleshooting.
For your first setup, update the subscription manually once and confirm it downloads successfully before setting an automatic update interval. An update may overwrite changes made to the remote configuration, so there’s no need to edit its rules yet. For help identifying link formats, see Subscription Formats: URL, Base64, and YAML. For a specific error, see Common Issues and Troubleshooting.
Step complete: The configuration is selected, and the Proxy page shows policy groups and nodes. Keep this configuration active; next, choose how it should handle traffic.
Choose Rule Mode and a Proxy Exit
Open the Proxy or Overview page and find the mode selector for Rule, Global, and Direct. For your first setup, choose Rule mode. The client uses the rules in your active configuration to decide where each connection goes, making it a good fit for everyday use when some traffic should connect directly and other traffic should use a proxy. The rules come from the configuration you’re using; clients don’t apply one fixed set of rules to every subscription.
| Mode | How it handles connections | When to use it |
|---|---|---|
| Rule | Matches rules in order | Everyday use and routing checks |
| Global | Routes traffic through the global policy | Temporarily compare rule and proxy exit behavior |
| Direct | Connects directly to the destination | Temporarily stops proxy routing |
Choose a Node in the Policy Group Used by Your Rules
After switching to Rule mode, expand the main policy group that handles proxy traffic in your configuration. Choose an available node or an automatic selection group. The current selection is usually marked with a check, a highlight, or text. If the group lists other groups rather than nodes, open the selected subgroup until you can confirm the final exit.
Policy groups can reference one another, so choosing any node won’t necessarily affect all connections. For example, if a rule points to the Work group but you changed the Media group, traffic for Work won’t use the new selection. You don’t need to reorganize every group for your first setup—just find the main group used by the traffic you want to test. If you’re unsure how groups differ from nodes, see Policy Groups and Nodes in the Glossary.
If the client offers a connection test, run it on the selected group to identify obviously unavailable options. Results depend on the test address, network conditions, and node policy. A successful test only confirms that the test request completed; it doesn’t replace testing a real website or app. Don’t change DNS, rules, and connection modes all at once because one test failed.
Keep a Baseline for Comparison
For your first connection, stay in Rule mode and choose an exit manually. You can use Global mode for troubleshooting later: if the same destination works in Global mode but fails in Rule mode, check which rule matched and how its policy group is configured. Switch back to your original mode when you’re done comparing. Direct mode doesn’t test proxy nodes; even while the client is running, it may send the request directly.
Step complete: The mode is set to Rule, and the main policy group shows a clear selection. Your configuration now determines where traffic should go. Next, route app traffic through the client.
Start the Core and Enable the Connection
Return to Overview or the home page and make sure the core is running. If the client combines starting the core and connecting into one action, click Start or Connect. If you see a port conflict or configuration loading error, fix it before routing traffic. Having a configuration, selecting a node, and routing system traffic through the proxy are three separate steps.
On Desktop, Start with the System Proxy
Find and enable System Proxy in the desktop client. It points system proxy settings to the local client, allowing browsers and apps that use those settings to send requests through Clash. For your first test, use a browser and leave TUN off. That makes it easier to tell whether an issue is with the configuration, the node, or the traffic entry point.
After enabling it, open a new browser tab and visit the target page. Existing tabs may reuse old connections, so refreshing immediately after a change may not use the new route. Some apps have their own proxy settings or ignore the system proxy entirely. If the browser works but another app doesn’t, that doesn’t necessarily mean the selected node is at fault. Check the app’s network settings before deciding whether to use TUN.
If you need to configure a proxy manually for an app, use the listening address, port, and protocol shown in the client. Don’t assume commonly used port numbers from a guide match your setup, and don’t confuse the HTTP and SOCKS endpoints. You usually don’t need to enable Allow LAN for local use; it lets other devices connect to your proxy service and isn’t required for this device to connect.
On Mobile, Approve the System VPN Request
When you tap Connect on a mobile device, the system may ask to add a VPN configuration or establish a VPN connection. Make sure the request comes from the client you just installed, then follow the system prompts to approve it. Return to the client, wait for it to show Connected, and check that the system displays a VPN status. The system VPN interface routes device traffic; the actual exit is still determined by your configuration and policy groups.
If another app is already using the same type of VPN interface, stop its connection before starting this client. The apps may replace each other’s system connection, causing their status indicators to keep changing. If the connection often drops when the app goes into the background, check the system’s app battery settings for background restrictions. You don’t need to change every power-saving setting right away.
Enable TUN Only If You Need to Route More Apps
TUN routes traffic through a virtual network interface and can cover some apps that don’t use the system proxy. Enable it in Settings only after basic browser testing works, then follow the client’s prompts to install a service or grant the required permissions. If startup fails, check the specific error. Don’t repeatedly toggle the system proxy, TUN, and other network tools at random.
Whether you need both the system proxy and TUN depends on the client and your settings. For your first setup, follow the client’s instructions and change only one traffic entry point at a time. TUN, DNS, and routing are covered in more detail in the Advanced Configuration Guide. For now, focus on getting one connection you can observe and verify.
Step complete: The client is running, with System Proxy enabled on desktop or a system connection established on mobile. Next, verify the connection with a real request instead of relying on the toggle’s status.
Verify Access and Rule Matches
First, open a page in your browser that should use the proxy—for example, a site your configuration explicitly routes through a proxy policy. Then open the client’s Connections, Active Connections, or Logs page and look for the domain you just visited. Details vary by client; focus on the destination, matched rule, policy group, and actual exit.
Check the Page and Connection Record Together
A page loading is the first sign that access works; a connection record showing the expected proxy policy chain is a second piece of evidence. If the site is also reachable directly, a successful page load alone doesn’t confirm that it used the proxy. Check that the record didn’t unexpectedly use DIRECT or a different policy group. If the rule is supposed to send the destination direct, seeing DIRECT is expected.
Next, visit a page that your configuration should route directly and check that it matches a direct policy. When both types of requests follow the expected route, your rules and traffic entry point are working together as intended. An IP lookup can help check the route for one request, but the lookup site is also affected by your routing rules. Its result doesn’t represent the exit used by every app or domain.
Verify with a new connection. After changing the mode or policy group, existing long-lived connections may keep using the old exit. Close and reopen the page, or disconnect the relevant active connection if you understand the impact. Don’t clear the entire configuration just to refresh a route—you could lose settings you’ve already confirmed work.
Narrow Down the Problem by Checking for a Connection Record
If the page fails and there’s no matching entry at all in the connection list, go back to Step 3. Check System Proxy or the mobile connection status, and make sure the browser isn’t using its own proxy settings. Also check the log level: a missing entry may mean the current level doesn’t record that type of information, not that the request never reached the client. Use the Connections page and a new request to confirm.
If there is a record but the connection times out, choose another node you’re authorized to use in the same policy group, then try the same page again. If only one destination fails, check its matched rule, the destination service, and any DNS errors. If all proxied requests fail, check whether the upstream service is available, your account is active, and your current network allows the connection.
If pages that worked before become unreachable after you enable the client, turn off the traffic entry point you just enabled. Confirm that basic internet access returns, then check the logs. This keeps your device online and lets you continue consulting the documentation. If the issue persists, note your operating system, client, mode, traffic entry point, and full error type. Redact sensitive details before asking for help. For more steps, see Troubleshooting FAQs.
Save a Working Setup for Everyday Use
After verification, note the active configuration name, mode, and main policy group selection. If you want automatic subscription updates, set an appropriate interval on the configuration page and confirm the same configuration remains active after an update. Before changing rules locally, back up the working configuration and learn how subscription updates interact with local overrides. This helps prevent temporary changes from being overwritten in a remote configuration.
Before closing the client for the day, use its Stop Connection or Exit option and check that the system proxy has been restored. If your browser can’t connect afterward, check whether the system still points to the stopped local proxy. Next time, verify in this order: configuration enabled → correct mode and exit → traffic entry point enabled → new connection recorded as expected.