Clash User Guide: Connect in Four Steps

Before you begin, prepare an installed Clash desktop client and the subscription URL generated by your network service provider. A subscription URL is usually a link beginning with https:// that retrieves proxy nodes, proxy groups, and routing rules. Treat it as a personal configuration credential: keep it on trusted devices and never post it on public forums, screenshots, or group chats.

Open the client and leave it running for several seconds to check whether the main interface loads normally. Seeing sections such as Configuration, Proxies, Connections, or Settings usually means the graphical interface has started. If the window closes immediately, the system reports that the app is damaged, or the core repeatedly fails to start, you have not reached the subscription setup stage yet. Follow the platform-specific installation section in the Installation Guide first.

Also confirm that the system date and time are correct. HTTPS subscription requests rely on certificate validity periods, and a large clock offset can make the client report a valid URL as a certificate or network error. Managed networks at workplaces and schools may restrict certain connections; during first-time setup, and where permitted, compare the result on another ordinary network.

Find the Subscription or Configuration Entry

After opening the client, go to “Configuration,” “Subscription,” or “Profiles.” Common interfaces provide a URL field with an “Import,” “Download,” “Add,” or plus button beside it. When copying the subscription URL, select every character from the beginning to the end. Avoid omitting the protocol, adding trailing spaces, or copying only the portion shown in a collapsed web view.

Paste the URL into the URL field and click Import or Download. The client requests the configuration from the subscription server and then parses the YAML content. Normally, a new configuration record appears with its name, update time, or an update button. Some clients switch to the new configuration automatically; others require you to click its name or choose “Set as Active.” Do not skip this step: a configuration appearing in the list does not mean the core is using it.

Confirm That Proxy Groups and Nodes Have Loaded

After importing, open “Proxies,” “Proxy,” or the policy page. You should see the proxy groups defined by the subscription, such as node selection, automatic selection, failover, direct connection, or blocking. Expand at least one selectable group and confirm that node names are listed. If the configuration page reports a successful import but the proxy page is completely empty, the configuration may have failed to parse, the downloaded content may not be a Clash configuration, or an older configuration may still be selected.

If a subscription update fails, click the update button beside the configuration record and try again while watching the error message. A timeout means the client could not retrieve remote content within the allowed time. A format or YAML parsing error means the response does not meet the current core’s requirements. An unauthorized or status-code error means you should return to the provider’s page and confirm that the subscription is still valid. Do not repeatedly concatenate multiple URLs in one field, and do not mistake the provider dashboard login URL for a subscription URL.

Establish a Regular Update Routine

Nodes and rules in a subscription may change as the provider updates its servers. After the first import, set a reasonable automatic update interval if the client supports it, or update manually when connections fail. Updating refreshes the configuration and may change the node list, proxy groups, or rules, so check the selected node again afterward. For configuration structure, YAML fields, and overrides, see the Installation and Configuration Guide; for now, keep the default settings and continue.

Choose Rule Mode for First-Time Setup

On the client’s home, settings, or proxy page, find “Mode.” Common choices include Rule, Global, and Direct. For a first setup, choose Rule mode: connections are matched against the configuration’s rules from top to bottom, ordinary direct traffic can use DIRECT, traffic requiring a proxy enters the assigned proxy group, and blocking rules use REJECT. This lets you verify the subscription’s routing logic while keeping a practical everyday setup.

Global mode sends most connections through one global proxy group. It is useful for briefly checking whether a problem is caused by rule matching, but it should not be treated as a permanent fix for every issue. Direct mode bypasses proxy nodes and can quickly confirm whether the local network itself works. These modes change the traffic path; they do not replace the system proxy or TUN switch. Selecting Rule mode without enabling a traffic-capture entry point may leave other applications outside Clash.

Assign Nodes to Selectable Proxy Groups

Keep Rule mode selected and open the Proxies or proxy-group page. Find the main group named something like “Node Select,” “Proxy,” or “PROXY,” then click a node. The selected item usually shows a highlight, checkmark, or status dot. If the group includes “Auto Select” or “Failover,” you can choose one of those subgroups and let its detection logic select the actual node.

A latency test reflects the client’s response to one test address at one moment; it does not directly represent the real speed of every website. For the first connection, choose a node with a normal status and a location and purpose that fit your needs. Repeated timeouts beside one node do not necessarily mean the entire subscription is invalid: an unreachable test address, local DNS problems, or network restrictions can affect the result. Select a node that completes the test, finish connecting and verifying, then judge the result by the sites you actually access.

Some subscriptions split different purposes into multiple proxy groups, such as streaming, developer services, messaging, and a final fallback. You do not need to change every group during basic setup; keeping the provider’s defaults usually produces more predictable results. Once the main proxy group has a clear selection, continue to the next step. For details on nested proxy groups, rule priority, and the MATCH fallback, see the relevant entry in Troubleshooting.

Confirm That the Core Is Running

Return to the client’s home page and check the core, service, or runtime status. A normal state usually shows “Running,” “Started,” or a teal-green status dot. If the client has a separate start button, click it and wait for the status to stabilize. The core loads the configuration, listens on local ports, and executes rules; an open graphical window alone does not prove that the core is running.

If the core fails to start, first return to the configuration page and confirm that the active configuration is valid. Another proxy application occupying the port, incompatible configuration fields, or insufficient permissions can prevent the listener from starting. Do not rapidly click the switch repeatedly; read the error line closest to the failure time in the client log. For port conflicts, service installation, and permission fixes, see Troubleshooting and follow the section matching the error.

Enable the System Proxy

Once the core is running, enable “System Proxy.” This points the operating system’s HTTP and HTTPS proxy settings to Clash’s local listening address. Browsers and desktop applications that follow system proxy settings will then send their connections to Clash. Windows and macOS usually allow a direct toggle; some systems may request permission. Follow the system prompt and allow the client to change network settings.

Do not close the client immediately after enabling it. Some clients only minimize to the system tray or menu bar when the window closes, while others stop the service and restore the system proxy when they exit. During first-time setup, keep the main window open until verification is complete, then confirm how the client runs in the background. If the system proxy switch turns itself off, this usually indicates a permission, service-component, or system-proxy write failure. Fix that state before testing websites.

When to Switch to TUN Mode

The system proxy mainly affects programs that actively read the operating system’s proxy settings. Some games, command-line tools, virtual machines, or apps with their own network stack may ignore them. Use TUN mode when this traffic also needs to be captured. TUN creates a virtual network interface so more connections enter Clash, but it requires higher privileges and may conflict with other VPNs, network filters, or security software.

For this ten-minute workflow, start with the system proxy and verify in a browser. If the browser works but the target application still connects directly, close other similar networking tools, enable TUN, and grant the administrator, VPN, or network-extension permissions requested by the system. The interaction between the system proxy and TUN depends on the client implementation; enable only what the target application needs. Use the connection log to determine whether its traffic is entering Clash.

Generate a New Connection in a Browser

Keep Clash running, open a new browser window or private window, and visit a site that normally opens reliably, followed by a site you expect to require a proxy. A new window reduces interference from existing connections, caches, and browser extensions. If the page is already open, refreshing may not create a completely new connection; close the tab and visit it again.

Then return to the client’s “Connections” or log page and search by domain for the request you just made. A normal record shows the destination domain, rule type, matched proxy group, and final node. A new record confirms that browser traffic entered Clash. DIRECT means the rule selected a direct connection; a proxy group and node name mean the connection used that selection.

Identify the Problem Layer from the Record

If the browser works but the client shows no corresponding record, first check that the system proxy is still enabled and that the browser is not using a separate proxy. Some browser extensions override system settings, bypassing the current client or forwarding traffic to another port. Temporarily disable those extensions and test in a new window to quickly distinguish browser settings from Clash configuration issues.

If a connection record exists but matches an unexpected rule, check the rule name in the record instead of repeatedly changing nodes. Rule mode matches strictly in configuration order; an earlier domain, IP, or rule set may capture the connection first. If switching temporarily to Global mode restores access, the node is usually usable and the issue is more likely rule matching or proxy-group selection. Switch back to Rule mode after testing and continue troubleshooting.

If the record shows a proxy node but the page still times out, try another node in the same proxy group and see whether the error changes. If several nodes fail, check whether the subscription needs updating, whether local DNS is working, and whether the device clock is correct. When only one node fails, treat it as a node-status issue first rather than modifying the entire configuration.

Verify the Terminal and Browser Separately

A working browser does not mean terminal commands automatically use the system proxy. Some terminal programs read only their own configuration or environment variables. First check whether the target domain appears in the client’s connection log while the command runs; a record means the traffic was captured, while no record suggests the command bypassed the system proxy. For persistent command-line proxy settings, configure the specific shell and tool instead of treating a temporary variable as a permanent system setting.

After TUN is enabled, terminal traffic is generally more likely to enter the client, but routing exclusions, DNS settings, and other virtual network interfaces can still interfere. Browser success, terminal failure, and application failure are separate troubleshooting branches. The complete browser, terminal, DNS, and TUN troubleshooting path is organized in Troubleshooting; during basic verification, simply confirm that at least one browser request consistently matches the expected policy.