Clash subscription import and connection tutorial

Before you begin, make sure a working Clash graphical client is installed on the device and prepare either a subscription URL or a local YAML file. A subscription URL is usually generated by a network service provider and should be a complete web address; a YAML file is a configuration file that can be imported directly. Choose one—you do not need to import both. If the client is not installed yet, visit the package downloads page and choose a client for your operating system.

After opening the client, first check that the main interface loads normally. Desktop clients usually place “Configuration,” “Subscription,” or “Profiles” in the sidebar. Android clients often put configuration access on the home screen or in the top-right menu, while macOS menu bar clients may reveal features through a status bar icon. Names and locations vary, but the workflow is the same: save the configuration to the client, set it as the active configuration, and only then choose a mode and establish a connection.

If another proxy, VPN, or network-filtering app has been running on the device, close it before starting this setup. Multiple programs changing the system proxy, VPN routing, or DNS can make the client appear connected while traffic bypasses the current configuration. During initial setup, run only one traffic-capture tool. Once the basic connection works, restore other software one at a time to identify conflicts more easily.

Open the client’s “Subscription,” “Configuration,” or “Profiles” page and choose to add a subscription. Paste the complete URL into the input field, checking that its beginning, parameters, and final characters were copied. When a subscription URL is long, do not delete symbols that look duplicated or treat a chat app’s truncated display as the full address. Give the subscription a recognizable local name, such as “Daily configuration,” then click Add, Download, or Update.

The client will request the subscription content and convert it into a local configuration. After a successful import, the configuration list usually shows a name, update time, or selectable status. You must still click that configuration or choose an action such as “Set active” or “Enable” so the client actually loads it. Saving a subscription in the list does not make it active; if the main interface still shows the old configuration name, later mode and policy-group settings will continue using the old content.

After selecting the configuration, open the proxy or policy-groups page and confirm that policy groups and node entries are present. Common group names include “Proxy,” “Auto,” “Fallback,” and “Direct,” although the actual names depend on the configuration provider. Seeing these entries means the subscription has at least been parsed by the client. If the list is empty, shows only a parse error, or immediately returns to the old configuration after updating, fix the import problem before enabling the system proxy.

When using a local YAML file, choose “Import file” instead of the subscription input field. After importing, set the file as the active configuration and check that policy groups appear. Do not make broad YAML changes before the first connection; connect once with the original configuration to distinguish an unusable source configuration from an error introduced by manual edits. For fields such as proxies, proxy-groups, rules, and dns, see the configuration reference.

Return to the client home screen or “Mode” settings. You will usually see Rule, Global, and Direct modes. Rule mode is recommended for first-time setup. It matches requests from the top of the configuration’s rule list and sends different traffic to Direct, Proxy, or Reject policies. This preserves normal paths for local networks and commonly direct services while routing selected requests through the intended policy group, making it the most common choice for everyday use.

Global mode sends most capturable traffic through one proxy policy. It is useful for briefly testing whether a node can connect, but it should not be used to attribute every failure to the rules. Direct mode bypasses the proxy and is useful for temporarily restoring the original network path. During troubleshooting, compare Rule and Global mode once: if Global works but Rule fails, inspect rule order, the target policy, or DNS matching; if both fail, continue checking the node, system proxy, VPN permission, and network environment.

After selecting Rule mode, open the “Proxy,” “Proxies,” or policy-groups page. A configuration may contain automatic-selection groups, manual-selection groups, and nested groups. Find the group that provides the primary proxy exit, then choose a healthy node or an automatic-selection option. If the group points to another policy group, continue into the next layer and confirm the final exit. Selecting only the outer group without choosing a node for the inner group may leave the connection using an old selection.

A client’s latency test only shows whether a particular probe received a response; it does not prove that every website is reachable. A node can return a latency result while real requests fail because of protocol handshakes, destination restrictions, DNS, or the system clock. For initial setup, choose a node that completes the client test, then confirm the result through real access and the connection log in step four. Do not keep running latency tests while skipping connection verification.

If the policy group has no selectable options, return to the previous step and check whether the configuration loaded successfully. If nodes exist but all report errors, refresh the subscription once and confirm that the device date, time, and time zone are correct. Complex nested groups, rule providers, and override merges are outside this basic workflow; read the configuration reference later when you need custom routing.

Desktop users should find and enable “System Proxy” or a similar switch. The client writes its proxy address to the operating system settings, allowing browsers and applications that honor the system proxy to send requests to Clash’s local listening port. Keep the client running in the background after enabling the switch. Quitting the client stops the local port from listening, while the operating system may retain the old proxy settings and make websites inaccessible.

Android and iOS clients usually capture traffic through the system VPN interface. After you tap Connect, the system displays a VPN permission request. Allow it, check for the VPN indicator in the status bar, and return to the client to verify the connection state. If the first authorization was canceled, the client cannot approve it on the system’s behalf; tap Connect again and accept the request. Some systems also restrict background activity, so allow the client to stay connected under the device’s battery and background settings. Otherwise, switching apps or locking the screen may interrupt the connection.

If only your browser and ordinary desktop applications need proxy access, the system proxy is usually sufficient. Some applications ignore system proxy settings or use an independent network stack; consider TUN mode only then. TUN may require administrator permission, an auxiliary service, or approval for a network extension, and the client will usually show a system prompt the first time it is enabled. Verify the system proxy first, then enable TUN so permission, driver, and subscription problems do not get mixed together.

A lit Connect button does not prove that requests are using the correct node. Also confirm that the local port is available. Clash configurations commonly use HTTP, SOCKS, or mixed listening ports. If another program occupies the same port, the client log will show a listen failure or address-in-use message. Close the conflicting program or change the port after confirming which applications reference it. See the general fields section of the configuration reference for the port field’s purpose and editing method.

Do not change more settings immediately after connecting. Keep the client, configuration, Rule mode, and node unchanged, then proceed to the next step for layered verification. This process checks the direct path, proxy path, and client connection records separately, helping identify whether the problem occurs before system traffic capture or between the rules and the node.

First open a website that normally works through a direct connection to confirm that basic network access is intact. Then visit a destination expected to use the proxy policy. Do not check only whether the browser loads the page; also inspect the client’s “Connections” or log page. A successful request usually shows the destination domain, matched rule, policy group, and final node. This is more useful for confirming expected behavior than observing the page alone.

In Rule mode, a direct site should match DIRECT or the corresponding direct group in the configuration. A destination requiring a proxy should match a proxy rule and show the policy group and node you selected. If every request shows Direct, check whether Direct mode was selected accidentally and whether the rules are using the active subscription. If every request enters the same proxy, check whether Global mode is still enabled or whether the catch-all rule at the end overrides earlier matches.

If the browser works but a standalone application cannot connect, first check whether that application reads the system proxy. On desktop, test TUN without changing the subscription or node. On mobile, check whether the application is excluded by the client’s per-app settings. If a domain fails but its IP address responds directly, DNS resolution is the more likely issue. DNS modes, Fake-IP exclusions, and LAN domain handling are advanced settings covered in the configuration reference.

During verification, make one clearly defined request at a time and promptly clear or filter the connection records. Background apps continually generate update, sync, and push traffic, and a large volume of entries can hide the target you just tested. Use the client’s domain filter, or note the target domain first and then inspect its matching rule and policy. This prevents connections from other applications being mistaken for the current test result.

If Rule mode fails but Global mode works, there is no need to reinstall the client. First see which policy the target matched in Rule mode. If it fell through to Direct or the wrong policy group, the issue is in the rules or policy selection. If both modes fail but the client shows connection records, prioritize checking the final node, protocol connection, and DNS. If the client shows no connection records at all, return to step three and check the system proxy, VPN, TUN, and the application’s own proxy settings.

After the basic connection works, record the current configuration name, mode, and primary policy-group selection. If an update or rule change later causes problems, compare it with this verified state. Subscriptions often support manual or scheduled updates. After updating, confirm that the same configuration remains active and quickly check whether the policy-group selection was reset by the new content.

For port settings, DNS, Fake-IP, TUN, nested policy groups, rule syntax, or override merges, continue with the configuration reference. It explains fields and examples by YAML structure and is intended for changes made after the basic connection works. For specific issues such as subscription update failures, leftover system proxy settings, loss of access after connecting, or DNS leaks, use Frequently asked questions to search by symptom.