How to Import a Clash Subscription and Connect

Before You Start: Check the Client and Configuration Source

Open the installed client and make sure its main window appears normally. If your operating system asks whether the client can access the network, grant permission for the features you intend to use. If installing a service or creating a virtual network adapter requires administrator access, note the prompt and handle it during the connection step. Before configuring the client, close any other proxy or VPN apps routing network traffic. Running two at once can change system proxy settings, routes, or DNS and make it hard to tell which setting affected your test.

Next, get a subscription link or a complete YAML configuration file. The client reads the configuration and handles traffic; installing it does not provide usable nodes on its own. Your service provider usually supplies the subscription URL. Choose a Clash- or Mihomo-compatible configuration that works with your client's core. Do not paste the provider's homepage or account sign-in URL into the import field. A file containing only a node list may lack proxy groups and rules, so it may not be a complete, usable configuration.

Subscription links may contain account-identifying information. Copy the full URL, but never share the complete link, its QR code, or a configuration containing credentials. Before editing an existing configuration, export it or save a separate copy. The steps below cover the settings needed for everyday connections; you do not need to understand every YAML field first. For field descriptions and platform-specific setup, see the Configuration Files section.

Step 1: Import a Subscription and Activate the Configuration

Open “Configuration” in the client's sidebar or bottom navigation, then look for “New,” “Add subscription,” or “Import from URL.” Choose the link option and paste the subscription URL into the URL field. If there's a name field, enter a label that's easy to recognize. Before saving, check that no spaces, line breaks, or punctuation from a chat app were added around the URL. Do not remove parameters after the question mark to shorten the link; they may be required for authentication or to return the right format.

Click “Import” or “Save” and wait for the client to download and parse the configuration. When successful, a new entry appears in the configuration list, possibly with a name, update time, or enabled status. Adding a configuration and using it are two different things. If the new configuration wasn't activated automatically, click its entry or open its menu and choose “Use,” “Activate,” or “Set as current.” Then return to “Proxies” to check that the configuration's proxy groups and available outbounds are visible.

For a local file, choose “Import file” or “New from file” on the same page, then open the complete configuration with the .yaml or .yml extension. On mobile, you may need to save it to the system file manager first, then select it using the file picker. After importing, make sure the file is active. Saving a file in your Downloads folder without importing it into the client does not change the configuration in use.

If you see a “Configuration parsing failed” error, stop here rather than repeatedly toggling the system proxy. For a link import, check whether the subscription has expired, requires sign-in, or returns a webpage instead of a configuration. For a file import, check that the file is complete, the editor hasn't changed its indentation, and its fields are supported by your core version. Start with the first clear error in the log, then look for the cause under FAQ: Installation, Configuration, and Troubleshooting.

Once the configuration is working, try “Update subscription” manually so you know where to find it later. Updating a remote subscription may replace its existing contents, so don't put important permanent edits directly in a downloaded copy that could be overwritten. If the client supports overrides or merging, explore those options once you're familiar with them. For now, confirm the configuration is active and its proxy groups are visible, then move on to outbound mode.

Step 2: Choose Rule Mode and a Proxy Group

On the home page, the “Proxies” page, or under “Outbound mode” in settings, find the “Rule / Global / Direct” options. For your first setup, choose Rule mode. It routes requests according to the rules in the active configuration: some go direct, some use a specified proxy group, and others may be blocked. Whether Rule mode behaves as expected depends on the imported configuration. The mode name alone doesn't tell you whether a particular site will use a proxy.

In “Global” mode, ordinary proxy requests handled by the core use the selected global outbound. In “Direct” mode, ordinary requests connect straight to their destinations. These modes control how the core forwards requests it receives; they don't determine which apps send requests to the core. So if your terminal isn't using the system proxy, switching to Global mode alone won't route its traffic through the client. First verify your setup in Rule mode, and switch to Global briefly only if you need it for troubleshooting.

Stay in Rule mode and expand the selection groups listed on the configuration's “Proxies” page. Group names come from the configuration and may be in English or another language, so don't look for a particular label. Check the available options: in a manual group, select an available node. If an option is another group, check how that nested group selects its outbound. Choosing DIRECT means a direct connection; REJECT means the connection is blocked. Neither selects a proxy node.

If there's a “Latency test” or “Connection test” button, run it once to rule out options that are clearly unreachable. The result measures one attempt to a specific test target; it is not a speed test and does not guarantee access to every site. A timeout may mean the node is unavailable, the test target can't be reached, or your local network is restricting access. Avoid testing lots of nodes repeatedly. Select one outbound that passes, then verify real-world access in Step 4.

An automatic group usually selects an outbound according to the configuration's test URL, interval, and policy; it may not let you pin a specific node. If you need manual control, choose a group configured for manual selection rather than changing an unfamiliar group type. Note the group name and selected outbound so you can compare them with the connection log later. For details on rule order and nested proxy groups, see the Platform Guides. You don't need to edit any rules here.

Step 3: Start the Core and Connect

Return to the home page and check the core status. Some clients start the core automatically; others require you to click “Start” or “Connect.” Check the status shown in the interface and the logs rather than relying on the tray icon alone. If startup fails, open “Logs” and look for a port conflict, configuration load error, or insufficient permissions. Fix startup problems before enabling the system proxy; otherwise, requests may be sent to a local port that isn't listening.

Desktop: Test Your Browser with the System Proxy

On Windows, macOS, or Linux, open the client's settings or tray menu and turn on “System Proxy.” The client will point the system proxy to a local listening address. This is usually enough for a first test in browsers that follow system proxy settings. Desktop environments and apps vary in their Linux support. If the toggle isn't available, check the desktop proxy settings using the instructions for your client; don't assume another platform's menu path applies.

Next, check that “Mixed Port” is listening. A common example is 7890, but use the value shown by your client. If you changed the port to avoid a conflict, update it in any apps where you configured the proxy manually. For your first test, keep the listener local; you usually don't need to enable “Allow LAN.” The external controller address is for managing the core, not a proxy address to enter in your browser.

Mobile: Approve the System VPN Request

Android and iOS typically route traffic through the system VPN interface. Tap “Connect” or the start button in the client, then approve the VPN request after confirming it's from the client you're setting up. Return to the app and check that the connection stays active. A VPN icon means the tunnel is established, but it doesn't prove the remote outbound works. Test access to your destination in the next step.

If another VPN is running, disconnect it before starting this client. Whether two VPNs can run together depends on the operating system and how each product works. On Android, if the connection drops often when the screen is locked, check battery optimization and background permissions after your first test. On iOS, first confirm the VPN status in system settings matches what the client shows. Avoid repeatedly switching between clients, which can make permission issues hard to distinguish from node problems.

TUN: Enable Only If You Need It

Consider TUN mode only if your browser works but you also need to route apps that don't follow the system proxy. TUN typically requires a virtual network adapter, a service, or administrator permissions. Follow the client's prompts to authorize it before turning it on. For your first test, don't change the system proxy, TUN, DNS, and routes all at once; adjust one setting at a time so you can identify what made a difference. TUN support, permissions, and routing vary by platform. For detailed steps, see the Platform Guides.

Step 4: Verify Access and Rule Matching

Leave the client running, open a new browser tab, and visit a site you know is reachable and that falls within the scope of your current configuration. Don't rely only on refreshing a page that's been open for a long time: cached content, reused connections, or a browser proxy extension can skew the result. If you use a proxy-switching extension, check whether it overrides system settings. You can temporarily disable it and test with the browser's default network settings.

Once the page loads, open the client's “Connections” or “Active connections” page and look for the destination domain you just visited. Check the matched rule, proxy group, or outbound chain and compare it with your selection in Step 2. Log fields and retention vary by client, and short-lived connections may disappear quickly. If so, leave the connections page open and try the request again. If you use logs to troubleshoot, keep only what's necessary and hide personal domains, subscription details, and credentials before sharing screenshots.

Check two things separately: Did the request reach the client, and which outbound did it use? If there's no matching record, check whether the browser uses the system proxy, whether the listening ports match, and whether another extension or VPN is routing traffic. If a record appears but access fails, check the selected node, the rule's destination, and any errors in the log. A DIRECT record is not a proxy failure if the configuration is meant to send that destination directly. Test another destination that the configuration should proxy.

If the browser works but a terminal or another app doesn't, first check whether that app reads system proxy settings. Many command-line tools need proxy environment variables configured separately, while other apps have their own proxy settings. Don't assume that a working browser means every app is routed, and don't re-import the subscription just because a terminal fails. For app-specific checks, see Connection Troubleshooting, or read How to Troubleshoot Browser and Terminal Proxy Issues Separately.

If a page loads but you want to check your apparent exit IP, use an exit-check service you trust as an additional reference and review the rule matched by that request. The result reflects only that request's route, not every app. If the rule sends it direct, seeing your local network's IP may be exactly what the configuration intends. Judge the setup by whether the expected destinations work, whether connection records match the rules, and whether the apps you use are routed through the client.

After testing, you can keep the settings that worked. To stop using the proxy later, turn off the system proxy or disconnect the VPN in the client before quitting. Whether the client restores system settings automatically varies, so check that your network still works after closing it. To move to another device, write rules, or adjust DNS, continue with the Cross-Platform Installation and Configuration Guide. You're done here; you don't need to configure every advanced option just to get connected for the first time.