Clash Tutorial: From Subscription Import to Connection Verification

Before you begin: client, subscription URL, and system permissions

Before you start, prepare two things: a Clash GUI client suited to your operating system and a Clash subscription URL generated by your service provider. The client reads the configuration, starts the local proxy port, and applies rules; the subscription URL supplies nodes, proxy groups, and rules. They are separate items. With only the client installed and no usable configuration, the Proxy page will usually have no selectable nodes.

First open the Download Center and choose an installer for Windows, macOS, or Linux. Windows users generally download the installer for the matching architecture and follow the setup wizard; macOS users must distinguish between Apple Silicon and Intel processors; Linux users should choose the package format for their distribution. On first launch, the system may request network, VPN configuration, or firewall permissions. These permissions enable a local proxy or virtual network interface and should be granted according to the client’s features.

A subscription URL is usually generated in your service provider’s dashboard and appears as a long link beginning with https://. It may contain account-identifying parameters, so do not paste the full URL into public chats, screenshots, or log posts. This guide does not provide nodes or subscription services, and it does not treat “free nodes” as a reliable configuration source; public URLs often expire and their contents are difficult to verify.

After installation, open the client without enabling the system proxy immediately. The goal during first launch is simply to confirm that the app opens normally and that you can find a “Profiles,” “Subscriptions,” or “Profiles” entry. Import the configuration first, choose a strategy next, and enable the system proxy last. This prevents system traffic from being sent to an unprepared local port before the client has loaded its rules.

Import a subscription: load the configuration file

Open the “Profiles,” “Subscriptions,” “Profiles,” or “Configs” page in the sidebar. Most desktop clients provide a URL field near the top, with an “Import,” “Download,” “Add,” or plus button beside it. Paste the complete subscription URL into the field and import it. The client will request the remote configuration and save the resulting YAML file in its local profile directory.

After a successful import, a new profile should appear on the page. It usually shows the profile name, update time, and an update button. Do not leave as soon as the record appears: click it or use its side menu to set it as the active profile. Some clients call this “Enable,” “Select,” or “Set as active profile.” If the record already has a check mark, colored border, or Active status, the profile is in effect.

Switch to the “Proxy” page to check the result. You should normally see several proxy groups, such as “Node Selection,” “Auto,” “Failover,” or names defined by the service provider. Each group should offer at least DIRECT, an automatic strategy, or specific nodes. Group names are not standardized; as long as the page is no longer empty and shows strategy and node levels, the core has read the configuration.

If the import reports a format error, first determine whether the link is a Clash YAML subscription or a generic subscription intended for another client. A link opening in a browser does not guarantee format compatibility. If the response is only an encoded string rather than YAML containing fields such as proxies, proxy-groups, and rules, the current client may not be able to read it directly. Format detection, configuration structure, and subscription conversion involve additional edge cases; consult the configuration chapter in the User Guide for help.

After importing a subscription, understand the difference between “Update” and “Edit.” Updating downloads the configuration again from its remote URL and is needed when the provider adds nodes or changes rules. Editing the local file affects only the current copy and may be overwritten by the next update. During first-time setup, do not rush to add custom rules. Complete one connection using the original configuration first, then handle rule overrides, script extensions, or configuration merging.

Choose a proxy mode: start with Rule mode

Once the configuration is loaded, open the “Proxy” page or the mode selector on the main screen. Common options are Rule, Global, and Direct. For first-time use, choose Rule mode. It matches the rules in the configuration from top to bottom and sends each connection to DIRECT, PROXY, REJECT, or a proxy group according to the match.

Rule mode separates different kinds of traffic. Local networks and domains marked for direct access can use DIRECT; domains that require a proxy enter the PROXY group; explicitly blocked requests go to REJECT. You usually only need to choose a node in the proxy group rather than decide how every site connects. Rule order, domain matching, IP matching, and the final MATCH fallback are advanced topics covered in the User Guide’s rule-routing chapter.

Global mode sends most connections through the currently selected proxy node. It is useful for briefly checking whether a site is being sent DIRECT by the rules, but it should not be the only troubleshooting method. Direct mode bypasses the proxy and is useful for temporarily restoring the original network path or checking whether the proxy chain is responsible. After troubleshooting, switch back to Rule mode as needed.

After selecting Rule, configure the proxy groups. Click the top-level “Node Selection” group or its equivalent and choose a specific node. If the configuration provides an “Auto” strategy, you can select it and let the core choose a candidate according to its configured tests. Latency tests only describe the response from the client to the test endpoint; they do not prove that every site is reachable. Use them here only to eliminate clearly unavailable nodes.

Some configurations contain nested proxy groups. The top-level group may point to “Auto,” a regional group, or another child group, which then points to specific nodes. After changing the top-level strategy, open the referenced child group and check the final node. If the top level uses an automatic strategy, manually changing a lower-level node may not immediately affect the current connection. If it uses a regional group, the options inside that group determine the actual exit.

Establish the connection: enable System Proxy and keep the client running

Return to the client’s home or Settings page and turn on the “System Proxy” switch. This points the operating system’s HTTP and HTTPS proxy settings to the local address where Clash is listening, commonly 127.0.0.1 plus a local port. The port is determined by the client configuration. Do not manually change the current configuration to a fixed number just because another guide uses it.

Once the system proxy is enabled, browsers and most desktop apps that read system proxy settings send requests to Clash. The client must remain running. When the process closes, the local listening port disappears; if the system proxy is not restored promptly, apps may be unable to open any web page. Before quitting, disable the system proxy or confirm that the client restores system settings automatically on exit.

If a regular desktop browser connects on Windows but Microsoft Store apps or some system components produce no connection records, check the UWP loopback restriction. Clients commonly provide a loopback helper in Settings or the service-mode section. This concerns network permissions for Windows app containers and is not required on every PC; use it only when the target app does not read the current proxy. For the full explanation, see the System Proxy and TUN chapter in the User Guide.

The first time you change the system network proxy on macOS, you may need to enter your system password; enabling TUN may also require approval for a network extension. Linux desktop environments do not all handle system proxies the same way: browsers may read desktop settings, while command-line programs usually do not. For this step, verify the system proxy in a browser first and check terminal programs separately in the next step.

TUN mode is not required for the first connection. It uses a virtual network interface to capture more traffic from apps that do not read system proxy settings, providing broader coverage than a standard system proxy. It also involves administrator permissions, routing, DNS, and coordination with other VPN software. Start with only the system proxy and confirm that the subscription, nodes, and rules work. Enable TUN later only if games, command-line tools, or special apps cannot connect. This keeps the troubleshooting scope smaller.

If the system proxy turns itself off immediately or the client reports that the port is already in use, quit other proxy software and check whether another Clash instance is running in the background. Do not let multiple programs modify the same system proxy settings or listen on the same port. After clearing the conflict, restart the client and verify the sequence again: profile enabled, Rule mode, node selected, then system proxy.

Verify that it works: check the browser and connection records together

Open a browser and visit a stable HTTPS page. Do not assume the proxy is working merely because the page loads; the rules may have assigned it to DIRECT. Then return to the Clash client and open “Connections.” Look for a new session generated by the browser. Session records usually show the destination domain, protocol, matched rule, and final strategy.

Find the relevant domain and focus on two details: which rule matched and which strategy was ultimately used. DIRECT means the request passed through the rule engine but was sent directly according to the configuration. PROXY or a specific proxy group and node means it entered the proxy chain. REJECT means the rule actively blocked it. This is more reliable than simply refreshing a page because it distinguishes “never reached Clash” from “reached Clash and was routed directly.”

Next open “Logs.” A normal connection usually shows the destination, matched rule, and selected strategy. For repeated connection timeouts, try another node in the same proxy group. For DNS resolution failures, check DNS settings, TUN status, and whether another network tool is also handling DNS. If the logs contain no browser requests at all, the likely causes are the system proxy switch, a browser proxy extension, or the app’s own proxy settings.

Browser extensions can override the system proxy. If a proxy-switching extension is installed, temporarily disable it or set it to read system settings, then open a new page and test again. Existing browser connections may be reused, so use a new private window or close and reopen the browser completely. This makes the newly generated session easier to find on the Connections page.

Terminal programs require a separate check. Many command-line tools do not read the desktop system proxy; instead, they use the HTTP_PROXY, HTTPS_PROXY, and ALL_PROXY environment variables, or require an explicit proxy address in the command. First check the HTTP or mixed port shown in the client’s Settings page, then make a request with an explicit argument:

curl -x http://127.0.0.1:7890 https://example.com

The 7890 above is only an example of the command structure. Replace it with the local HTTP or mixed port shown by your current client. After running the command, return to Connections and look for the corresponding session. If the explicit proxy works but a command without -x produces no record, Clash is working correctly; the terminal simply has not been configured with proxy environment variables.

Finish with a recovery test: disable the system proxy, refresh the page, and check that the new request no longer appears in Connections; then enable the system proxy again and confirm that sessions resume. This toggle test verifies that the system setting is actually changing. Leave the client in Rule mode afterward and decide whether to launch it at startup based on your needs. Do not enable multiple auto-start network tools before understanding how they behave on exit.

Still not connected after ten minutes? Troubleshoot in order

Do not randomly toggle every switch while troubleshooting. Clash’s basic chain has five stages: the subscription URL downloads, the core reads the configuration, the proxy group has an available strategy, the local port is listening, and the target app sends traffic to that port. Check them in this order to quickly identify the failing layer.

1. Configuration layer: Return to the Profiles page and run one update, confirming that the current profile is clearly selected. If the update fails, fix the subscription URL, network connection, or configuration format before switching nodes.
2. Strategy layer: Open the Proxy page and confirm that the mode is Rule and the top-level proxy group is not stuck on an unavailable option. Choose another specific node and create a new browser connection; do not judge the result using a page that has been open for a long time.
3. Port layer: Check the client logs for a port conflict or core startup failure. If there is a conflict, quit other proxy programs and duplicate client instances, then restart the client.
4. System layer: Confirm that System Proxy is enabled. On Windows, check the system proxy settings; on macOS, inspect the proxy entries for the current network service; on Linux, confirm that the desktop environment and target app read the same settings.
5. Application layer: Check proxy extensions in the browser, environment variables in the terminal, and TUN requirements for games or special apps. Do not use one app’s result to assume that every app uses the same proxy mechanism.

If the issue affects only one site while other proxy connections work, inspect that site’s session for its rule, strategy, and error details. A rule error belongs to the configuration layer, an unreachable node to the exit layer, and a DNS failure to the resolution layer. If no site produces any connection record, check the system proxy and app settings first rather than editing the rules file.

If the cause is still unclear, keep an original configuration that can start successfully, then record the client name, operating system, current mode, whether TUN is enabled, the exact log error, and whether a session appears in Connections. Next open the From Zero to Pro User Guide and continue with the chapters on System Proxy, TUN, DNS, rule routing, and logs. Advanced configuration is covered in the guide; this page keeps the shortest path to a first connection.