How to Import a Clash Subscription and Connect

Step 1: Import and enable a subscription

Open the client and find Configuration, Subscription, or Profiles in the sidebar or bottom navigation. Choose New, Add, or Import, then select Import from URL. Paste the full subscription link and check that it has no leading or trailing spaces, line breaks, or extra text from a chat app. If there’s a name field, enter something recognizable, such as “Daily subscription,” then select Download, Save, or Import.

Enter a subscription URL here—not your provider’s homepage, account page, or a text link for an individual node. Some providers offer multiple formats; choose one marked Clash or compatible with your client. Don’t guess the format by changing URL parameters. If you’re unsure, check your provider’s subscription instructions.

Once the download finishes, you should see a configuration card or subscription entry. Some clients save an imported file without switching to it automatically. Select Use, Enable, or the equivalent button, and make sure the configuration is marked as active. Then open Proxies. You should see policy groups and node names. That’s a better sign that the active core has loaded the configuration than a simple “Import successful” message.

Importing a local configuration file

If you have a local configuration file, choose Import from file in the same import menu. Select the .yaml or .yml file, then set it as the active configuration. A file extension alone doesn’t guarantee that the contents are valid—the client still needs to parse it successfully. If the file contains only a configuration fragment rather than a complete configuration, it may not work on its own. Check what it’s intended for first.

URL-based subscriptions can usually be updated from the configuration list; local files may not have a remote update URL. After your first successful connection, set an update schedule according to your provider’s instructions. Don’t keep deleting and re-adding the same subscription while waiting for new nodes. Try its Update button first. If the update fails, keep the current configuration if it still works rather than removing it.

What to check if importing fails

If the request times out, check that your device can reach the subscription URL and that the link hasn’t expired. A parse error may mean you received a web page instead of a configuration, the format is incompatible, or the current core doesn’t support it. Changing proxy modes won’t fix a parsing problem. A subscription URL that won’t open and a node that won’t connect are separate issues. For more help, see Troubleshooting.

Step complete when: The configuration is active, and the Proxies page shows policy groups or nodes. Leave it enabled; next, choose how traffic should be routed.

Step 2: Choose a proxy mode and node

Go to the client’s home or settings page and find Proxy Mode, Run Mode, or Mode. For your first setup, choose Rule. Connections will then be matched against the rules in your configuration: some go through a proxy group, some connect directly, and some rules may reject requests. Routing depends on the configuration; not all rule-based configurations use the same routing setup.

Next, open Proxies, Policy Groups, or the equivalent page. Group names are set by the subscription author, so they may be in English or describe a particular purpose; they won’t always be called “Node Selection.” Find the proxy selection group used by the configuration and choose a node. If the group lists another policy group, follow it until you can see which node will be used or which auto-select group makes the choice.

If the client has a latency test or speed test button, run it and wait for the results before choosing a node. The number usually shows response time to the test server—not download speed—and doesn’t guarantee that every site will be reachable. A timeout means that this test didn’t get a response; the cause could be the node, test server, or current network. Start with a node that responds, then verify it with a real website.

Rule, Global, and Direct modes explained

Rule mode is best for everyday use: the configuration determines where each request goes. Global mode sends connections handled by the core through the global policy. You’ll usually need to select a node in the global group as well. It doesn’t automatically capture traffic from every app; traffic that never reaches the core isn’t affected. Direct mode connects traffic handled by the core straight to its destination, without routing it through a proxy node.

If a site won’t load in Rule mode, temporarily switch to Global and select the same working node to compare. If it works in Global but not Rule, check the rule match and policy group rather than replacing the entire subscription. Switch back to Rule when you’re done so traffic meant to connect directly doesn’t go through the proxy. For more on the differences between modes, see Troubleshooting. This guide sticks to the shortest setup path.

Existing browser connections may not switch routes immediately when you change modes. Close the test page and reopen it after making a change. If the client offers a way to close existing connections, you can use it as long as it won’t interrupt anything important. A change to the mode label at the top doesn’t mean existing connections have been rerouted.

Step complete when: Rule mode is selected, and the active proxy policy group has a clear choice. Your routing is ready, but the system or app still needs to send traffic to the client.

Step 3: Connect and route system traffic

First, check whether the client’s home page shows that the core has started or the service is running. If startup fails, resolve any port conflict, permission, or configuration errors reported by the client before enabling system access. Starting the core alone doesn’t mean your browser is using the proxy: core status and whether the system routes traffic to it are two separate things to check.

Desktop: Enable the system proxy

In desktop clients for Windows, macOS, and other platforms, find and enable System Proxy, Set as System Proxy, or a similar option. Most browsers read the system proxy settings, so you don’t need to enter a port manually for your first setup. If your system asks you to approve a network setting or helper service, confirm that the request comes from the client you’re using before approving it. Some clients combine starting the core and enabling the proxy in one button; check the status of both.

Linux desktop environments and individual apps vary in their support for system proxies. Some clients require you to configure the desktop environment’s proxy settings, and some browsers have their own proxy configuration. If you have a browser proxy extension installed, disable it or set it to use the system settings so it doesn’t override the proxy you just enabled. Terminals, games, and some app stores may also ignore the system proxy, so browser access doesn’t mean every app will use the same route.

For your first setup, don’t enable TUN at the same time. The system proxy is easier to check and undo, making it a good way to confirm that the subscription and node work. If you need to route traffic from apps that ignore the system proxy, see Advanced Setup for TUN permissions, routing, and DNS requirements. TUN and Global mode are different: TUN controls how traffic enters the core, while Global mode controls how traffic is routed once it’s there.

Mobile: Approve the VPN connection

In the Android or iOS client, tap Connect, Start, or the power button on the home screen. The first time you run it, the system will usually ask to allow a VPN connection or add a VPN configuration. Approve the request, return to the client, and wait for it to show Connected. Check the status bar or the VPN settings on your device as well. The VPN connection routes traffic to the client, but it doesn’t guarantee that the subscription nodes work—you’ll check that in the final step.

If your phone is already using another VPN, proxy, or network tool that relies on a VPN connection, disconnect it before starting this client. Whether multiple tools can run together depends on the system and app. If the client disconnects soon after going into the background on Android, keep it open while you test. Once the basics work, check battery optimization and background restrictions. Avoid changing power settings, DNS, and node options all at once, or it’ll be hard to tell what helped.

Step complete when: On desktop, the core is running and the system proxy is on; on mobile, the VPN permission is approved and the client shows Connected. Leave the client running. Next, check both website access and the connection logs.

Step 4: Verify access and traffic routing

Reopen your browser and first visit a site that normally works without a proxy to make sure your regular connection is still available. Then try a destination you expect to need a proxy for, such as a GitHub page that requires a proxy to load reliably on your current network. Don’t treat any one site as a universal test: the destination’s availability, account restrictions, and regional policies can all affect the result.

While testing, open the client’s Connections or Logs page. New connections usually show the destination domain or address, matched rule, and policy chain. Find the destination you just visited and check whether it used a node or connected directly. Some clients show the full policy chain only in connection details. If the page loads but no new entry appears, make another request and check that a filter isn’t hiding the entry.

Consider the page load and connection details together: a page opening while its connection shows the expected policy is strong evidence that routing works. A rise in traffic alone isn’t enough—background apps also make requests. A page loading by itself isn’t enough either; it may have been reachable directly or loaded from cache. If needed, visit a new page path and check the new connection it creates.

What to check if the result isn’t what you expected

If you can’t see a new browser connection at all, go back to Step 3 and check the system proxy, browser extensions, or mobile VPN status. If a connection appears as Direct even though the destination should use a proxy, revisit Step 2 and check Rule mode and the policy group; this is usually a routing issue. If the log shows a node but the connection keeps timing out, try another node before changing DNS or enabling TUN.

If every node fails, check that your subscription account is still active and that your network is online. Look for a specific error that keeps appearing in the client logs. Logs may contain domains, node addresses, or subscription details, so redact sensitive information before sharing them. For more help, see Troubleshooting. To adjust DNS, Fake-IP, rule sets, or the external controller, consult Advanced Setup.

Everyday use once everything works

Once the connection checks out, keep Rule mode and your working policy group selection, then set a subscription update schedule if needed. After changing networks, updating the configuration, or switching nodes, you can repeat the quick check—open a page and inspect the new connection—instead of going through the full setup again. Change one setting at a time, note its original value, and restore it if the result is worse. This makes troubleshooting clearer.

When you’re done, turn off the system proxy before closing the desktop client. On mobile, tap Disconnect and confirm that the system VPN has stopped. If regular websites won’t load after the client closes unexpectedly, first check whether your system still points to a local proxy. Automatic recovery varies by client, so checking the setting directly is more reliable than repeatedly restarting your browser.

Step complete when: Regular websites work, the test destination is reachable, and the connection log shows the expected policy. Subscription, mode, system access, and connection verification are all in place. Add advanced settings only when you have a specific need.