The client starts normally
After opening the home page, you should see basic entries such as Configuration, Proxies, Connections, or Settings, without the client remaining stuck in initialization.
10 minute setup
A step-by-step setup flow for first-time Clash users. Follow the subscription, mode, connection, and verification stages to complete the basic setup in about ten minutes.
Before setup
Before you begin, confirm that the client is installed and opens normally. On first launch, desktop systems may ask for network access, firewall, or background-running permissions; mobile systems commonly request permission to create a VPN configuration when the connection starts. Grant the permissions required to complete the connection. Otherwise, the interface may show that the configuration is loaded while the client still cannot handle device traffic.
This guide assumes you already have a valid subscription URL from a configuration provider. The URL is not generated automatically by the Clash client; it usually contains proxies, policy groups, routing rules, and DNS settings. Configuration structures vary by source, so policy group names may differ after import. If the configuration parses successfully, the policy groups appear, and there are no obvious errors, continue to the next steps.
If other configurations are already saved on the device, review the active one first instead of deleting anything whose purpose is unclear. For a first test, create a separate subscription entry and keep the original URL. This lets you update the subscription again and restore the provider’s original content after changing rules or testing another mode.
After opening the home page, you should see basic entries such as Configuration, Proxies, Connections, or Settings, without the client remaining stuck in initialization.
The URL can be copied in full, without extra spaces or line breaks. If the provider offers a web console, check there that the subscription is active.
Enable automatic date, time, and time-zone settings. A significant clock error can prevent some secure connections from being established.
Once these checks are complete, do not enable the system proxy immediately. Import the subscription into the client first. Configuring before taking over traffic prevents the proxy from starting without a usable policy, which could temporarily disconnect browsers and other apps.
After opening the Clash client, look for an entry named “Configuration,” “Subscription,” “Profiles,” or “Configuration files.” Desktop clients usually place it in the left navigation, while mobile clients may show it in a configuration section on the home page. Choose Add subscription, Import from URL, or Add remote configuration, then paste the complete subscription URL into the field. If a name is required, use a short, recognizable label. It only distinguishes the entry on this device and does not change the subscription.
Save the entry and run an update once. The client will request the subscription URL and parse its YAML configuration. Normally, the list will show a configuration name, update time, or update button; some clients also show the number of proxy groups. Do not rely only on a “Download complete” message—confirm that the new configuration actually appears in the list. If the list is still empty, check whether the URL was truncated or contains leading or trailing spaces, then paste it again.
A successful import does not necessarily mean the configuration is enabled. Many clients can store local configurations and several remote subscriptions at once, so you may still need to click the selection button, radio marker, or enable action for the new configuration. After selecting it, the home page will usually show its name, and the proxy page will contain several policy groups. These changes confirm that later mode selection will use the imported configuration.
If the client reports a configuration parse error, do not keep enabling the system proxy. Common causes include incomplete subscription content, a URL that returns a login page, incompatible configuration fields, or broken indentation after local editing. Updating again with the provider’s original subscription URL is usually safer than editing the generated configuration directly. If it still fails, note the field name and line number in the error, then consult Troubleshooting for subscription update and configuration loading issues.
After these checks, the configuration is ready to run. Next, decide how traffic should pass through Clash. For a first setup, you do not need to understand every rule; choose a mode suitable for testing and make sure the main policy groups are not pointing to unavailable options.
Open the client’s “Mode,” “Runtime mode,” or “Mode” section. Common options include Rule, Global, and Direct modes. For first-time setup, Rule mode is recommended: the client uses domains, IP addresses, and rule sets in the configuration to decide which requests use the proxy and which connect directly. Rule mode is also the expected everyday setting for many subscription configurations, preserving normal direct access to local networks and common direct-connect services.
Global mode sends most traffic through one global policy. It can help briefly confirm whether a connection option works, but it should not be the only way to troubleshoot every problem. Direct mode bypasses proxy policies and is mainly useful for pausing the proxy or running a comparison test. If Direct mode is selected by mistake, external access will not reflect the effect of the proxy configuration even when the Clash core is running.
Routes traffic according to the configuration rules. Prefer this mode for first-time setup and everyday use.
Handles traffic through one global policy for short comparison tests.
Sends traffic without proxy policies, useful for pausing the proxy or comparing network behavior.
Once the mode is set, open the “Proxies,” “Proxy,” or policy group page. Subscriptions often include groups such as “Proxy,” “Auto,” or “Fallback,” though providers may use custom names. Find the group responsible for the main outbound choice and check its current selection. If the group offers automatic selection, start with that; if manual selection is required, choose an available option whose region and purpose match your needs.
Some clients provide latency testing. The result reflects the response from your device to the target at that moment; it does not by itself represent full download speed or long-term stability. During the first connection, use the test to rule out clearly unreachable options rather than chasing the smallest number. If every option times out, first confirm that the subscription updated successfully and that the device has basic network access instead of switching modes repeatedly.
Policy groups may reference one another. For example, a rule group may point to “Auto,” which then chooses an outbound option from several candidates. Changing only the outer group may not change the final result. With a complex policy structure, keep the subscription defaults and simply confirm that the main selection group contains an available option. See Protocol and Core Technical Reference for the relationship between the core, policy groups, and protocol types; advanced fields are outside this guide.
Once the runtime mode is Rule and the main policy group points to an available option, Clash’s internal decision path is ready. Only then should you start the core and let the operating system send the relevant network requests to the client.
Return to the client home page and find the start, run, or service toggle. Desktop clients usually separate “Start core” and “System proxy” into two states: the core reads the configuration and provides a local proxy port, while the system proxy sends requests from browsers and apps that follow system settings to that port. Therefore, starting the core without enabling the system proxy may leave the client appearing healthy while webpage traffic never reaches the connection log.
Start the core first, wait until its status changes to running, and then enable the system proxy. If the client offers launch at startup, decide whether to enable it after the first successful verification rather than adding another background variable during troubleshooting. Some Windows clients may require elevated permissions to set the system proxy or install a service; macOS may request approval for a network extension, helper tool, or administrator access. Complete the system prompts, then return to the client and confirm the toggle has not switched itself off.
Android and iOS clients generally use the system VPN interface to create a local connection. After you tap Start, the system displays a confirmation dialog for creating the VPN connection. Allow it; a VPN indicator should usually appear in the status bar, and the client home page should show Connected or Running. This VPN configuration hands device traffic to the local client. If permission is denied or another VPN-style app is occupying the connection, Clash cannot take over traffic.
A mobile device can usually maintain only one connection of this type at a time. If the connection stops immediately after starting, check whether another VPN or network-filtering tool is connected in system settings. Disconnect the conflicting service and start again from the client. Android power-saving rules may also terminate the connection after the app moves to the background; keep the client in the foreground during the first test, then allow the required background activity in system settings once basic connectivity is confirmed.
On Windows and macOS, after enabling the system proxy, open the operating system’s network or proxy settings for a cross-check. Normally, you will see a local proxy address and port written by the client. Do not change these values manually if you are unsure how the client manages them; otherwise, inconsistent settings may remain after the client closes. To stop using the proxy, turn it off from the client first so it can perform the appropriate cleanup.
Linux graphical clients handle this differently depending on the desktop environment and the client implementation. Some can write the system proxy directly; others only provide local HTTP, SOCKS, or mixed ports that must be specified in desktop network settings or the target app. If the client selected on the download page clearly provides a system proxy toggle, use its built-in method first. Servers and command-line-only environments are core deployment scenarios; see the Technical Reference for configuration compatibility and operating boundaries.
After the system proxy or VPN is connected, do not immediately cycle through different options. Keep the current configuration and Rule mode, then move to the final step: use a regular webpage and the client connection log to determine whether requests are following the expected path.
Close any test pages already open in the browser, then open a new window and visit a site that normally loads for you. This first checks that the proxy settings have not disrupted basic connectivity. Next, open a site that should be handled by the subscription rules and see whether it loads normally. Keep the client running during the test, and do not enable a browser proxy extension, another VPN, or a second system proxy tool, as layered settings can change the request path.
A webpage loading successfully is only the first result. Return to the client and open the “Connections,” “Logs,” or “Connections” page. Refresh the webpage and look for a new domain, a matched rule, or a policy name in the connection list. If the request appears, system traffic has entered Clash. If no new records appear, check the system proxy or VPN takeover state before investigating the subscription option itself.
In the first case, the webpage loads, connection records continue to appear, and the expected policy is shown. Import, mode, core, and system takeover are working as one complete chain, so the basic setup is complete. In the second case, the webpage fails but the connection log shows requests and errors. Traffic has reached the client, so the issue is more likely related to the selected option, DNS, rules, or the target connection. In the third case, the webpage fails and the connection log remains unchanged. Check the system proxy, VPN permissions, and conflicts with other network tools.
The connection chain is established. Continue monitoring rule matches and normal usage.
Check the selected policy option, DNS status, rule result, and the specific error in the log.
Check the system proxy, VPN permission, the browser’s independent proxy settings, and other connection tools.
If verification fails, first confirm that the device can access the basic network normally with Clash’s system proxy or VPN disabled. If the underlying Wi-Fi, mobile, or wired connection is unavailable, restore it first. Once basic connectivity works, reopen the client and confirm that the active configuration is the subscription you just imported. Then check that the mode is Rule and that the main policy group has a clearly selected option.
Next, restart the core and system proxy. On desktop, turn off the system proxy, wait a few seconds, and enable it again. On mobile, disconnect the VPN and reconnect from the client. Afterward, refresh one webpage while watching the connection log. Change only one part at a time so you can identify what restored the connection.
If requests already appear in the connection log but it reports name-resolution failures, unmatched rules, or invalid configuration fields, do not rewrite the entire configuration during this introductory setup. Update the subscription and retest with another available policy option. If it still fails, open Troubleshooting and follow the “Clash not working” and “Subscription update failed” categories. DNS request paths, fallback conditions, and core compatibility are advanced configuration topics covered in the Technical Reference.
When a regular webpage loads, the request that needs handling appears in the connection list, and the matched policy fits the current configuration, all four steps are complete. Only then configure launch at startup, background operation, or automatic subscription updates based on your needs. Avoid adding extra settings before the basic connection chain is confirmed.
After setup
Once basic connectivity is confirmed, keep a clear update and troubleshooting routine instead of frequently changing advanced parameters.
Subscription options and rules can change. Before updating, confirm that the current network works. Afterward, check that the configuration is still selected and that the main policy group retains a sensible option. If automatic updates are supported, choose a reasonable interval; there is no need to refresh repeatedly within a short period.
When one website cannot be reached, first check whether the request entered the client, which rule matched, and which policy was used. The connection log helps distinguish system takeover, rule, and target connection problems more effectively than switching every toggle without a plan.
When testing custom rules, copy the configuration before editing it, and keep the remote subscription as a recovery source. If parsing fails, revert to the original version first, then add changes one at a time instead of combining multiple problems in one file.
For operational issues such as client crashes, failed subscription updates, or leftover system proxy settings, see Troubleshooting. For choices involving protocol differences, core families, subscription compatibility, and resource usage, open the Technical Reference instead of adding too many advanced variables to the basic guide.
Return to the download page when you need another client or platform. For a specific error, open Troubleshooting based on the observed symptom.