Import a Clash Subscription and Set Up Your Connection

1. Import a Subscription and Activate the Configuration

Open the client and go to “Profiles,” “Subscriptions,” or a similar page. Look for “Add,” “Import,” or a plus button. If your provider gave you a complete URL, choose the remote profile option or import by URL. If you already have a YAML file, import it from your device. Either way, you need a configuration the client can parse. Don’t save a URL as if it were a local file.

Paste the URL and Wait for It to Download and Parse

Paste the complete subscription URL into the remote profile field, give it a recognizable name, then click “Import,” “Download,” or “Save.” The name only helps you identify the profile; it doesn’t change the server settings. Remove any leading or trailing spaces when copying the URL. Don’t include explanatory text, quotation marks, or line breaks from a message, and don’t alter the URL’s query parameters.

Wait for the client to finish the request. On success, a new entry usually appears in the profile list, along with an update time, profile details, or an update option. Some subscriptions require the client to request content in a specific format. If you see a format error, ask the provider whether the subscription supports your client and core instead of repeatedly changing the file extension. A URL opening in your browser doesn’t mean it returns a valid Clash configuration.

If the remote download fails, leave the proxy disabled and check that your current network can reach the subscription service. Some clients use separate proxy settings for subscription updates, so a successful browser test isn’t conclusive. Note any status code or error message, then see subscription and import troubleshooting. Don’t disable certificate checks just to get one download to work, and never submit a private subscription URL to an unknown conversion site.

Activate the Configuration and Check for Proxy Groups

Once the configuration has been added, click its entry or the adjacent “Enable” or “Use” button to make it active. Some clients select an imported profile automatically; others only add it to the list. Check which profile is marked active—don’t assume it’s selected just because it appears in the list. Then open the Proxies page and confirm that the configured proxy groups and available outbounds are there.

To import a local file, select the YAML file in your system’s file picker, wait for the client to parse it, then activate it as above. Local imports usually don’t update automatically when the remote service changes. If you receive a new file, import it again or replace the existing one using the client’s available options. Keep a copy of the original so you can roll back before making later rule changes.

At this point, you’ve only loaded the configuration; you haven’t confirmed that the proxy works. If the Proxies page is empty, parsing reports a field error, or a different profile is still active, stop here and fix that first. Once the proxy groups appear, move on to choosing a mode.

2. Choose Rule Mode and a Proxy Outbound

Return to the client’s home or Proxies page and find “Mode,” “Operation Mode,” or a similar option. For your first setup, choose Rule mode (Rule). The core uses the configuration’s rules to decide whether each connection goes direct, through a proxy group, or is rejected. This option doesn’t create rules, and it doesn’t send every site through the same proxy.

Choose the Mode First, Then Select a Proxy Group

After switching to rule mode, open the proxy list and find the group used for proxy traffic in your configuration. It may be called “Proxy,” “Select Node,” or something else; check your provider’s configuration. Expand the group and choose an outbound you know is available. If the group contains nested groups, check the current selection at each level. Otherwise, you might think you’ve selected a proxy while the final outbound is actually DIRECT.

A manual selection group lets you choose an outbound directly. An automatic or fallback group follows the checks and switching behavior defined in the configuration. If clicking an entry doesn’t keep it selected, check the group type before assuming the client is broken. For your first connection, keep the configuration’s existing group structure. Don’t rush to rename groups or remove ones that look duplicated; rules may refer to them by name.

If the client offers a connectivity test, run it after selecting a proxy group to rule out obviously unreachable options. The result only reflects a single request to the specified test target; it doesn’t prove that every app can connect or indicate real download speeds. Finish the browser test and connection-log checks later in this guide before judging whether everything works.

Rule, Global, and Direct Modes Compared

“Global” mode typically sends all connections that reach the core through the global proxy group. It’s useful for a quick check of whether a problem is related to the rules. Check the group’s outbound after switching: if it’s set to DIRECT, traffic won’t go through a proxy as expected. Switch back to rule mode after the comparison so a temporary troubleshooting setting doesn’t become your everyday setup.

“Direct” mode sends connections that reach the core straight to their destinations, so it can’t verify whether a proxy outbound works. Also, global mode only controls how the core handles connections it has received; it doesn’t capture traffic from every app on your system. Which apps reach the core depends on whether you enable the system proxy or VPN in the next step.

At this point, confirm two things: the current mode is Rule, and the target proxy group has a clearly selected outbound. For details, see proxy modes and proxy groups. For your first setup, leave the rules file unchanged and continue to connecting.

3. Start the Core and Route Traffic Through It

Return to the home or status page and check whether the client has started the core. Some desktop clients start it when the app launches; others require you to click “Start” or “Connect.” If you see a configuration error, startup failure, or port conflict, fix it first. Enabling the system proxy won’t help if the local service isn’t running—in fact, your browser may lose internet access.

Desktop: Start with the System Proxy

On Windows, macOS, or a Linux desktop client that supports this feature, find and enable the “System Proxy” switch. If the system asks for permission to change network settings, make sure the request comes from the client you just started, then approve it as prompted. Browsers and apps that follow the system proxy settings will then send requests to the local proxy port.

You don’t need to enable TUN for your first setup. Start with the system proxy and test in a browser; it involves fewer variables and is easier to undo. Linux desktop environments and apps vary in their support for system proxy settings. If your client has no switch, or your browser uses its own proxy settings, check the app’s proxy configuration using the client’s documentation. Don’t copy port numbers from another guide; use the listening port configured in your client. See port settings for details.

If your browser has a proxy-switching extension, pause it or set it to follow the system settings. Temporarily quit other proxy clients and disconnect any active VPN to keep them from changing the system settings. Don’t run multiple traffic-capture tools during your first connection test, or it’ll be hard to tell which service handled the request.

Mobile: Approve the VPN Connection

In the Android or iOS client, tap “Connect” or the start button on the home screen. The first time you connect, the system usually asks to configure or enable a VPN. Approve the request as prompted; iOS may also require device authentication. This VPN is the system’s interface for routing traffic—it doesn’t confirm that your subscription is working.

Return to the client and check that its status says Connected or Running. Check the system’s network status too to confirm that the VPN is active. Status bar icons vary across Android manufacturers, so don’t rely on an icon alone. If another VPN is already active, find out whether connecting will replace it before proceeding. Keep the client in the foreground for your first test to avoid confusing background restrictions or disconnections with configuration issues.

If you denied the request, return to the client and connect again. Check the system settings to make sure the app is allowed to create a VPN. Don’t delete another app’s network settings unless you understand the consequences. If permission prompts keep appearing or startup continues to fail, note your OS version and the exact message, then see connection troubleshooting.

When you finish this step, keep the client running with the system proxy enabled on desktop or the VPN active on mobile. Don’t close the client or change DNS settings yet. Next, test the connection with a real request.

4. Verify Access and Check Rule Matches

Open a new browser window or tab and visit a site that your configuration is expected to route through the proxy, and that you know is working. Choose a familiar destination; there’s no need to sign in or enter sensitive information. If the browser keeps reusing an old page, close it and open a new one. Cached content and existing long-lived connections can make before-and-after results hard to compare.

Browse and Check the Connection Log

Open the client’s “Connections,” “Connection Log,” or request history page, then refresh the browser tab. Find the entry for the domain you just visited and check which rule matched, which proxy group handled it, and which outbound was ultimately used. If the interface only shows some fields, open the connection details or check the logs. A page loading is only the first check; the connection log confirms whether traffic took the expected route.

Next, visit a destination the configuration is expected to connect to directly and check its log entry the same way. If the first request uses the expected proxy outbound and the second shows DIRECT, rule mode is handling at least these two destinations as configured. DIRECT requests may still appear in the client’s log because they reached the core before it connected directly to the destination.

Don’t assume every rule works just because one site loads, and don’t treat a single IP lookup as proof that every app is routed. An IP lookup only reflects the path taken by that request. Different apps, domains, and connection types can match different rules. For your first setup, test a browser you commonly use and one real-world scenario, then expand your tests gradually.

Troubleshoot One Part of the Connection at a Time

If a destination won’t load and there’s no matching connection log entry, first check whether the system proxy or VPN is still enabled, whether the browser bypasses system settings, and whether the core is still running. Focus on the traffic entry point before changing rule sets. If a connection is logged but uses the wrong outbound, return to step two and check the mode, proxy group selection, and active configuration.

If the connection log shows the expected proxy outbound but the request still fails, open the Logs page and look for errors around the time you tried to access the site. A timeout usually means a connection stage didn’t complete in time. A DNS failure needs further investigation to distinguish the destination domain from the server’s domain. Neither message alone tells you which side is at fault. Try another known-working outbound in the same proxy group and test the same destination again, leaving other settings unchanged.

Raise the log level temporarily only when you need more detail, then restore your usual level after testing. When asking for help, include the client name, OS version, steps to reproduce, time of the issue, and a redacted error message. Never share your full subscription URL or credentials. For more troubleshooting scenarios, see connection and access issues. For help reading logs, see Common Clash Errors: What They Mean and How to Troubleshoot.

Save the Working Setup and Check What Happens When You Disconnect

Once access and routing behave as expected, note the configuration name, selected proxy group, and traffic-capture method, and keep a backup of the original configuration. After updating a subscription, quickly check the proxy group selection; upstream changes to groups or outbounds may invalidate an earlier choice. Set up launch at startup, background operation, and scheduled updates one at a time after the basic connection is stable.

When you’re done on desktop, turn off the system proxy before quitting the client, then confirm that regular websites still load. Most clients restore the proxy settings when they exit, but force-quitting may leave them in place. If your network stops working afterward, first check whether the system proxy still points to a stopped local service. On mobile, disconnect in the client and confirm that the system VPN has ended.

You’ve now completed the full setup: loading a subscription, choosing a mode, routing traffic, and verifying access. When you’re ready to customize routing or cover more apps, continue with the Complete Beginner-to-Advanced Guide. Keep this working configuration as your baseline and repeat the final verification step after each change.