Clash subscription import and connection guide

Import the subscription and select the active configuration

After opening the client, look for the “Subscription,” “Configuration,” or Profiles page. Some clients place the subscription field at the top; others require you to click “New,” “Import from URL,” or a plus button first. Paste the complete URL provided by your subscription service into the field. Do not mistake a web dashboard URL, plan name, or individual node text for a subscription URL. Check that there are no extra spaces or line breaks, then click “Import,” “Download,” or “Add.”

Normally, the client requests the subscription URL and creates a new configuration entry. Do not enable the connection immediately. First check the entry name, update time, and status reported by the client. If the page shows a network error, format error, or configuration parse failure, the import has not completed; switching proxy modes will not fix it. Copy the subscription URL again, confirm that the service page is reachable in a browser, and check that the subscription is still active. Authorization failures, empty subscription content, and server-side errors must be handled by the subscription service provider.

Once the configuration entry appears, click it or use its adjacent enable button to make it active. Many clients can store multiple configurations, but the core executes only the currently selected one. Adding a subscription to the list without selecting it is a common reason for seeing no policy groups on the proxy page. After selecting it, open the “Proxy” or Proxies page. If the policy groups and options defined by the subscription are visible, the core has read the configuration and you can continue.

What a successful import looks like

The clearest sign is not that a webpage loads, but that the client contains a selectable configuration entry, its details show policy groups, and parse errors are not recurring. Some clients switch to the new configuration automatically after import, while others keep the previous local configuration active, so confirm the current selection manually. If policy names change noticeably after an update, check the active selection again to avoid continuing to use an old cached configuration.

This stage answers where the configuration comes from and which configuration the core reads. It does not yet decide which route each request takes or send browser and system traffic through the client. Once the configuration is selected, choose a proxy mode so the core knows whether to evaluate rules individually or send requests to one policy.

Choose Rule mode or Global mode

Open the client’s “Mode,” “Proxy Mode,” or Mode settings. Common options include Rule mode, Global mode, and Direct mode. For an initial setup, Rule mode is recommended. It checks requests against the rules from the top of the configuration file, stops at the first match, and sends the request to the specified DIRECT, REJECT, or policy group. This lets different domains and addresses use different routes and matches how most subscription configurations are designed to work.

After choosing Rule mode, open the “Proxy” or policy group page. The names shown there come from the active configuration and may differ completely between subscriptions. Find the policy group used for primary proxy selection, then choose a specific option or an automatic selection provided by the configuration. Do not assume PROXY is a built-in button that must exist; in YAML examples, it is usually just a policy group name defined under proxy-groups. Use the group names displayed by the active configuration.

Global mode sends all traffic that the client can capture to the selected global policy, making it useful for a short comparison test. For example, if a site fails in Rule mode but works in Global mode, the issue is more likely related to rule matching, policy group selection, or the DNS path than to the subscription being completely unavailable. After the comparison, return to Rule mode and use the logs to find the matched rule. Staying in Global mode permanently bypasses the configuration’s intended split-routing logic and does not help identify which rule produced the result.

Direct mode normally sends captured requests straight to their destinations. It can help determine whether client traffic capture affects an application, but it is not the same as turning the client off. If the system proxy or TUN remains enabled, traffic may still enter the core before being sent out through the direct policy. To stop capture completely, disable the corresponding system proxy, VPN, or TUN switch in the next step rather than only changing the proxy mode.

If the policy group is empty, every option is unavailable, or switching modes immediately produces a configuration error, return to the first step and check the active configuration instead of enabling the system proxy. Once both the mode and policy can be selected normally, the configuration is ready; the next step is to hand device or application traffic to the client.

Enable the system proxy and establish the connection

Return to the client’s home or settings page and enable “System Proxy,” “Set as System Proxy,” or an equivalent switch. On desktop systems, the system proxy writes to the operating system’s proxy settings so browsers and applications that follow them send requests to the client’s listening port. After enabling it, the client usually displays an active status. You can also open the system network settings to confirm that the client manages the HTTP, HTTPS, or SOCKS proxy entries.

Android and iOS clients typically capture traffic through the system VPN interface. On first launch, the system displays a VPN configuration or connection permission prompt; after approval, a system-level VPN indicator may appear in the status bar. This permission allows the client to create a local network tunnel; it does not mean the subscription service and client have the same provider. If permission is denied, the configuration and policies may still appear normally in the client, but traffic from other applications will not enter the core.

On macOS, clients may use the system proxy, a VPN configuration, or a network extension. Windows clients may also request administrator privileges when TUN is enabled. If you only want to test a browser first, use the system proxy. Its scope is easier to observe and it is easier to disable when something goes wrong. Terminal tools, some games, virtual machines, and applications with their own network stacks may ignore the system proxy; consider TUN for those cases instead of enabling every capture method during the initial setup.

Before enabling capture, confirm that an available option is selected in the policy group. If the client supports policy testing, you can run its availability check once, but the result only describes requests to the test target and cannot replace real application testing. Keep the client running, open a new browser window, and continue to the next step. Do not change the subscription, mode, DNS, and TUN at the same time before and after connecting; change one layer at a time so you can identify the cause of any difference.

At this point, the connection path should be: the application reads the system proxy or enters through VPN/TUN; traffic reaches the client’s listening entry; the core reads the active configuration and processes the request according to the selected mode; and the request is finally sent through a direct, rejected, or proxy route. Verify this path from both the application’s behavior and the client logs rather than relying only on whether the home-screen switch is lit.

Verify that the proxy and rules are working

Choose a webpage you have not opened before and visit it in a new tab. A new request reduces interference from browser cache, existing connections, and DNS cache. While the page loads, open the client logs or connection records and search for the domain you just visited. Seeing the domain, matched rule, and final policy confirms that the request reached the core. An enabled system proxy switch alone does not prove that a specific application is using it.

The log result should match the rule’s expected behavior. A target matching a direct rule should show DIRECT; a rejected request should show REJECT; and a policy-group match should show the group and its final selection. Rule mode evaluates from top to bottom and stops at the first match, so a later rule will not override an earlier match even if it appears more specific. If the route is unexpected, record the matched rule first, then investigate rule order or the policy group instead of repeatedly switching nodes.

After the browser test succeeds, test the application you actually need. If the browser works but a terminal command fails, they are usually reading different proxy entries. The terminal may require HTTP_PROXY, HTTPS_PROXY, or ALL_PROXY environment variables, or it may need TUN capture. An application with its own proxy settings may override the system proxy; check whether it is set to “No proxy,” a fixed port, or an old address. For a detailed browser and terminal troubleshooting workflow, see the Help Center instead of changing too many parameters during the basic setup.

If the test domain never appears in the logs, inspect the traffic entry point: on desktop, confirm that the system proxy is still enabled and its port matches the client’s listening port; on mobile, confirm that the system VPN has not been replaced by another VPN app; for TUN, confirm that permissions were granted and routes were created successfully. If the domain appears but the request fails, inspect the final policy, connection error, and DNS result. The first case means the application never entered the client; the second means it entered the client but failed at the outbound or resolution stage. The two cases require different troubleshooting paths.

You can also run a mode comparison. Keep the same configuration and test address, temporarily switch from Rule mode to Global mode, and choose the same available policy. If Global mode succeeds but Rule mode fails, focus on rule matching and DNS. If both modes fail, focus on policy availability, subscription status, and the local network. If the browser succeeds but another application fails, focus on that application’s proxy settings and capture scope. Return to Rule mode after testing so the test state does not become a permanent setting.

Troubleshoot by stepping back through the layers

Troubleshoot by moving backward through this guide: if the logs show no request, return to the connection step and check the system proxy, VPN, or TUN; if a request appears but has no suitable policy, return to the mode step and check the policy group and rules; if the proxy page has no policy groups, return to the import step and verify the active configuration and parse status. Handling one layer at a time preserves useful clues and is easier than deleting and reinstalling the client.