Clash Subscription Import and Connection Setup

Step One

Import the Subscription and Select the Profile

Open the client’s “Config,” “Subscription,” or “Profiles” page. You will usually find a subscription URL field beside an Import, Download, or Add button. Paste in the complete URL you copied, check that it begins with https://, and then import it. The client retrieves the profile over the current network; normally, a new item appears in the profile list within a few seconds.

The new item may show a service name, a profile name, or only a short title generated from the URL. Do not stop at seeing it in the list: click or check it to make it the active profile. Many first-connection failures occur because the client is still using a built-in example, an empty profile, or a leftover profile—not because the subscription download failed. The selected item usually appears highlighted or checked, or is shown as the current profile on the home page.

Next, open the “Proxy,” “Proxies,” or policy-group page. If the import worked, you should see several policy groups, such as node selection, auto selection, failover, or app categories. Group names come from the profile provider and vary between subscriptions. Open a main policy group and look for selectable nodes or an automatic testing option. Seeing these entries means the client has parsed the profile, rather than merely saving a URL.

If the list reports a download failure, timeout, or format error, do not keep clicking Refresh. Pasting a subscription URL into a browser address bar does not always produce a readable page, so the browser display alone cannot confirm whether the profile is valid. A more reliable sequence is to confirm that the underlying network works, copy the URL again from the service page, check for spaces before or after it, and add it again in the client. If the provider shows a subscription status, also confirm that it has not expired.

Set Automatic Updates After the First Test

Most clients let you set an automatic update interval for subscriptions. You can enable a reasonable schedule after the first import, but avoid repeated manual updates while troubleshooting. When the profile changes, policy-group names, node order, and rules may change as well, making the issue harder to reproduce. First verify the connection with the successfully imported version; once the basic path works, choose one of the client’s standard update intervals.

Before leaving this page, three conditions should be clear: the subscription appears in the profile list, it is selected, and the proxy page shows expandable policy groups with available options. Only then move on to mode selection. If the proxy page is empty, stop and fix the import first; the system proxy switch cannot compensate for an empty profile.

Step Two

Choose Rule Mode and a Policy Node

Once the subscription is active, find “Mode,” “Mode,” or the running-mode setting. Clash commonly offers Rule, Global, and Direct modes. Rule mode is recommended for first-time use. It checks the profile’s rules from top to bottom and sends each request to a direct connection, rejection rule, or specified policy group. This works well for everyday use and makes it easier to identify which rule matched a site in the connection log.

Global mode sends most proxyable traffic through one proxy policy. It can help determine briefly whether a node itself works, but it should not be the only result of the initial setup. If a site fails in Rule mode but works in Global mode, the issue is usually rule matching, policy-group selection, or DNS handling—not necessarily a failed node. Direct mode is mainly for temporarily bypassing the proxy and checking whether the local network works. Return to Rule mode after testing so the client is not left in diagnostic mode.

After selecting Rule mode, open the “Proxy” or “Policy Groups” page. Find the group handling the main traffic; it may be called “Node Selection,” “Proxy,” “PROXY,” or a custom name from the provider. If the group offers “Auto,” “Latency Test,” or “Failover,” start with Auto. If it contains only individual nodes, choose one with a normal status. Reported latency is only a connectivity reference; a lower latency does not guarantee that every target site will work.

After clicking an option, confirm that the highlight or check mark has moved to the new item. Some policy groups contain another policy group—for example, the main group may select “Auto,” while the Auto group chooses a node based on test results. This is normal. You do not need to edit every category group during the first setup; handle the main policy group first. Adjust a specific group only if an app or site still follows the wrong route.

Handle the System Proxy and TUN Separately for Now

The proxy mode determines how requests are routed after they enter Clash; the system proxy or TUN determines which requests enter Clash in the first place. These are separate layers. For now, set only the rule mode and policy choice, without enabling multiple traffic-capture methods at once. Use the system proxy for basic desktop testing. Android and iOS establish connections through the system VPN interface. Consider TUN only when command-line tools, games, or apps that ignore system proxy settings also need to use the client.

At this point, the profile defines the available rules, the running mode is set to Rule, and the main policy group has a clear selection. The next step is to hand system traffic to the client. If every node reports an error, update the subscription once and try another node. If all entries fail at the same time, the subscription, underlying network, or client core is more likely at fault than every node becoming unavailable simultaneously.

Step Three

Start the Core and System Proxy

Return to the client’s home page or general settings and check the core status first. Different clients may show “Running,” “Service Running,” or “Core Started,” or use only a status color. If the core is not running, writing a proxy address into the system settings does not help because no process is listening on that port. If the client has a separate start button, start the core and wait for its status to stabilize before enabling the system proxy.

Windows and macOS desktop clients usually offer a “System Proxy,” “Set as System Proxy,” or similar switch. Once enabled, the client writes the local proxy address into the system settings, allowing browsers and apps that honor system proxy settings to send requests to Clash. Do not quit the client immediately. Some clients minimize to the system tray when the window closes; fully quitting may stop the core and restore the system proxy, while others require you to disable the system proxy manually before quitting.

Android and iOS use a connection method closer to a system VPN. After tapping Connect, the system displays a VPN configuration or authorization prompt. Once approved, the status bar usually shows a VPN indicator and the client home page shows the connected state. The VPN indicator only means that the system has handed traffic to the client; it does not prove that the subscription node works, so continue with the access test in the next step.

Linux desktop environments differ considerably in their system proxy support. After enabling the system proxy in a graphical client, check the desktop network settings to confirm that the HTTP and SOCKS proxies were written. If the browser works but terminal commands do not, the terminal program probably does not read the desktop proxy settings. For this initial guide, verify with a browser first rather than changing shell environment variables. Continue with the TUN and System Traffic Capture section for command-line proxies, service processes, and transparent traffic capture.

When to Enable TUN

A system proxy works well for browsers and most desktop apps, is simple to configure, and is easy to undo when you exit. TUN captures traffic at a lower network layer and covers programs that ignore system proxy settings, but it usually requires administrator, VPN, or network-extension permissions. If the browser already works during the initial setup, keep the system proxy. Enable TUN only when a specific program clearly bypasses the system proxy, then test that program separately.

If TUN is necessary, close other VPNs first and grant the permissions requested by the client. After enabling it, check whether the client reports that the virtual network interface was created, the service was installed, or the required permissions are available. Do not enable TUN in two Clash clients at the same time, and do not let an old VPN and the current client control the default route together. If the connection breaks after sleep, a network change, or a client upgrade, disable TUN and enable it again.

After startup, the home page should show both layers of status: the core is running and traffic capture is enabled. On desktop, this usually means the core is running and the system proxy is on; on mobile, it usually means the core is running and the VPN is connected. Keep the client window or tray process running and continue to the final verification step.

Step Four

Verify the Connection with Access Results and Logs

Do not rely only on the “Connected” label on the client home page. A more reliable test has three layers: basic network access, proxied access, and rule matching. First open a site that normally works directly to confirm that enabling Clash has not interrupted the underlying network. If even ordinary sites fail, the issue may involve the system proxy port, DNS, TUN routing, or the current profile; switch back to a direct test first.

Once basic access works, open a target site that is expected to use the proxy. If the page loads consistently, the path from the app through the system proxy, Clash core, selected node, and target site is broadly working. Do not test only a cached page; open a private window or refresh a new URL path to reduce false results caused by browser caching.

Then open the client’s “Connections” or log page and refresh the test page in the browser. The connection list should show the relevant domain or destination, the matched rule, the policy group used, and the final exit. Fields vary by client, but you should at least see that the request entered the client. If the browser works while the connection list shows no new entries, the browser may be using its own proxy setting, an extension, or an independent DNS path, so the traffic is not taking the expected route.

If a connection is marked Direct when it should use a proxy, check the matched rule before changing nodes. Rule mode matches the profile in order; once an earlier rule matches, later rules are not evaluated. If switching temporarily to Global mode makes the site work, that usually indicates that the node is available and the rules or policy group need review. For custom rule syntax, rule overrides, and fallback entries, see the Rule-Based Routing section.

Run One More Disable-and-Restore Test

After confirming that proxy access works, disable the system proxy or disconnect the mobile connection and check whether ordinary sites remain accessible. Then reconnect and test the target site again. This confirms that the client can correctly write and restore the system network settings and can reveal a proxy address left behind after exit. If all sites stop working after closing the client, reopen it and disable the system proxy, or turn the proxy off in the system network settings.

Finally, return to Rule mode, confirm that the main policy group still selects the intended option, and watch the connection for a few minutes. One successful visit only proves that the path worked at that moment. If the connection repeatedly drops, determine whether the cause is a single unstable node, a subscription update that changed the policy selection, or a switch between Wi-Fi and mobile data. Once these checks are complete, the first setup is done; later, update the subscription on schedule and change the policy option when a node fails.