Clash Subscription Setup and Connection Guide

Before You Start: Check the Client and Configuration Source

This guide assumes the client is already installed. Open it and check the client name and core type under Settings or About. The client provides the interface, subscription management, and system settings; the core parses the configuration, matches rules, and establishes connections. An app that opens successfully has only started its interface—it does not mean the core has loaded a valid configuration or that other apps’ traffic is being proxied.

Get a valid subscription URL from your service provider, or a complete local YAML configuration. The client does not include a remote proxy service. Without nodes and a valid configuration, the client cannot connect to a remote proxy. Subscription URLs may contain account identifiers, so paste them only into a trusted client. Don’t share them in screenshots, public logs, or online conversion tools.

For your first setup, quit any other proxy or VPN tools that are routing traffic so you have one clear test path. If you changed the system proxy manually, note the original settings so you can restore them later. Keep the client window open and follow the steps below in order. Avoid changing DNS, TUN, routes, and rules all at once, or it will be harder to identify the cause of a problem.

Clash Meta and mihomo: What’s Different?

Clash Meta is the former name of this core branch; the project was later renamed mihomo, so some clients still use the Meta label. Seeing the old name does not mean you need to install a different client. Check which core the current app actually uses and which fields it supports. If a subscription includes protocols such as VLESS or Hysteria2 but import reports an unknown protocol, check core compatibility first—repeatedly clicking Connect won’t fix it. See the protocol reference for details on protocols and core compatibility.

Step 1: Import a Subscription and Enable the Configuration

Open “Subscriptions,” “Configuration,” or “Profiles” in the client’s sidebar or bottom navigation. Choose “Add,” “Import,” or the plus button, select a remote URL as the source, and paste the complete subscription URL. It usually starts with https://. Keep all query parameters when copying it, and remove any chat app notes, line breaks, or extra spaces. You can give it a descriptive local name, such as “Daily,” which changes only how it appears in the client—not the subscription itself.

After you click Download, Save, or Import, wait for the configuration card to show a successful status. If the client has separate “Save URL” and “Update Configuration” buttons, run the update too, and wait for the nodes and proxy groups to download. Don’t proceed just because a configuration name appears in the list: some clients save the URL before fetching it, leaving an empty card if the request fails. Open the details to check for parsing errors, then confirm the provider’s proxy groups appear on the Proxies page.

Click the configuration card to make it active. Some clients mark the current configuration with a highlighted border, a checkmark, or an “Enable” button; others reload the core immediately. Return to Proxies and confirm the groups and node list are visible. This means the configuration has been imported and enabled. If you have several configurations, check that the newly imported one is active so you don’t keep using an older configuration after updating the subscription.

For a local .yaml or .yml file, use “Import from File”—don’t paste its filename into the remote URL field. Content starting with ss:// or vmess:// is usually a single node share link, not a complete Clash configuration with proxy groups, rules, and DNS settings. Use the client’s node import option only if it explicitly supports that format.

Subscription Updates and Import Errors

After importing a subscription, you can set an automatic update interval in its edit page. The interval controls when the configuration is fetched again; it does not guarantee that the provider’s nodes will always work. After a manual update, check for a success message, then return to the proxy groups to see whether your selection was preserved. If a download fails, determine whether the URL has expired, the account has an issue, your network cannot reach the URL, or the download succeeded but parsing failed. Each cause requires a different fix.

If parsing fails, start with the field name, protocol, and line number in the error. Don’t delete large sections of the configuration at random. The provider should fix a complete subscription or explain how to select a mihomo-compatible format. If a subscription expires or nodes disappear after an update, continue with common issues. Keep the last working configuration until the problem is resolved so you don’t overwrite your only working setup.

Step 2: Choose a Rule Mode and an Exit Node

With the configuration enabled, open “Overview,” “Proxies,” or “Mode” and set the operating mode to “Rule.” Rule mode follows the configuration’s rules in order: some destinations connect directly, others go through a proxy group, and explicitly blocked destinations are rejected. This setting controls connections that reach the core. To route app traffic into the core, you’ll still need to enable the system proxy or another traffic-capture method in the next step.

Next, open the main proxy group. Its name is set by the subscription author and might be “Select Node,” “Proxy,” or something else; there’s no universal name to look for. Expand the group and choose a node you know is available. If the client offers a connectivity or latency test, run it first. The result reflects a check against a specific test address; a displayed latency does not guarantee that every site or app will work.

A proxy group may point to another group. For example, if the main group selects “Auto Select,” the nested group determines the actual exit. With “Manual Select,” open the corresponding group and choose a node. If the final selection is DIRECT, traffic goes directly to its destination—not through a remote proxy. For your first test, pin a specific node to reduce variables. Once everything works, you can switch back to automatic selection.

When to Use Rule, Global, and Direct Modes

“Global” sends connections that reach the core through the global proxy policy. It does not capture apps that bypass the client. “Direct” sends connections that reach the core straight to their destinations. For everyday use, start with rule mode. If a destination behaves unexpectedly, briefly switch to global mode for comparison. If it works in global mode but not in rule mode, check the matched rule and proxy group. Switch back to rule mode when you’re done so you don’t leave a test setting enabled.

Check Rule Placement Before Adding Custom Rules

You don’t need to add rules just to connect for the first time. If you need to route a specific domain, first find the client’s “Override,” “Extended Configuration,” or “Rule Editor” settings and check whether changes apply to the active configuration or all configurations. Direct edits to a downloaded subscription file may be overwritten on the next update. Prefer a persistent editing method supported by the client, and review the generated configuration after saving.

Rules are generally matched from top to bottom, and the first match determines the policy. Place a new rule before any broader rule that would catch the same destination, and make sure the policy name exists. For example, DOMAIN-SUFFIX,example.com,DIRECT sends the domain and its subdomains directly. This is a syntax example only; you don’t need to add it to your configuration. For rule sets and DNS details, see the protocol and core reference. First, complete the connection test below.

Step 3: Start the Core and Route Traffic

Return to the client’s Overview and confirm the core is running, with no repeated configuration load failures or port conflicts. Some clients start the core automatically; others require you to click “Start” or the main connection button. Check Settings for the local proxy listening address and port. Use the values shown by your client—don’t assume every client uses the same port. If the configuration is enabled but the core fails to start, switching nodes won’t fix the listener.

Desktop: Start with the System Proxy

Turn on “System Proxy” in the desktop client, then make a new request in a browser that follows system proxy settings. The client should direct the system’s HTTP proxy to its local listening port. If a browser extension manages proxy settings separately, pause it first so it doesn’t override the system setting. An already-open page is not proof that traffic has switched; refresh it or open a new test page.

Some command-line tools, games, and apps ignore system proxy settings. If they connect directly while your browser works, the node may not be the problem. Check whether the app has its own proxy setting. If not, consider TUN. See TUN vs. system proxy to learn which traffic each method can route. You don’t need to enable every networking feature during your first setup.

Mobile: Approve the System Connection

Tap the connection toggle on the mobile client’s home screen. The first time you connect, approve the prompt to create or establish a VPN configuration. Return to the client, confirm its status shows Connected, and check for the VPN indicator in your system’s network status. The indicator confirms that a system tunnel is active, but does not prove the node is working. If another VPN is running, disconnect it first, then reconnect in the current client.

Enable TUN Only If You Need to Route More Apps

TUN routes traffic through a virtual network interface and routing rules. A desktop client may require service mode, administrator privileges, or approval of a system extension. Follow the prompts for your client. Once enabled, check the logs for messages confirming the virtual interface was created and is listening. If you see a permissions or interface creation error, turn TUN off and restore the system proxy path you already tested. Then look up the error in Troubleshooting.

Don’t run two TUN or VPN traffic-capture setups at the same time. When troubleshooting for the first time, avoid changing DNS and route exclusions together. Whether to use the system proxy and TUN simultaneously depends on the client and the apps you need to route; follow the client’s documentation. Start with one clear, testable traffic path. Your configuration, node, and routing method are now set—observe the results before changing anything else.

Step 4: Verify Access, Rules, and Your Actual Exit

First, open a reliable HTTPS site to make sure traffic capture hasn’t disrupted your basic connection. Then visit a destination that should use a proxy under your current configuration. Generate a new connection rather than relying on cached content. If you changed modes or nodes during testing, an existing connection may still use its previous exit. Close and reopen the destination page; if needed, remove only that destination’s existing connection from the client.

Next, open the client’s “Connections” page and filter by the domain you just visited. Check whether the request appears. If there’s no matching record, first check the browser’s proxy settings, the app’s own configuration, and TUN’s coverage—not the remote node. If the request is listed, inspect the matched rule, proxy group chain, and final exit. Together, these show how traffic was routed after it reached the core.

For a destination that should use a proxy, make sure it hasn’t unexpectedly matched DIRECT. If it matched a proxy group, expand the policy chain and confirm the final selection is the node you expected. A direct connection isn’t always an error; the subscription’s rules may intentionally route that destination directly. What matters is whether the recorded route matches the expected one—not whether every connection shows a proxy name.

Check Your Exit and DNS Separately

Use a trusted IP-check page as a secondary test. Compare the result with your direct-connection baseline, and check the request in the client’s connection list too. If the exit doesn’t match the provider’s description, consider the node’s actual exit, the lookup service’s database, and the proxy chain rather than relying on the location label alone. Never submit a subscription URL or account details to a so-called one-click checker.

A page loading successfully or a changed exit IP does not prove that every app’s DNS requests follow the expected route. First verify access and rule matches. If you need to check DNS, read about Fake-IP and DNS handling. For issues affecting specific domains, note the destination, matched rule, and error, then follow the steps in common issues to narrow down the cause.

Save a Setup You Can Reproduce

Once pages load and connection records match your expectations, note the configuration name, mode, proxy group selection, and traffic-capture method. You don’t need to share the full configuration. Then test a normal shutdown: turn off the system proxy or disconnect first, then quit the client and confirm regular internet access still works. If you end the process while the system proxy still points to its local port, the browser may fail because nothing is listening. Reopen the client and disable the system proxy, or restore the settings you noted earlier.

Finally, enable launch at startup and automatic configuration updates if needed, then check the setup again after the next restart. Starting the app at boot does not guarantee that the subscription loaded, the core started, or TUN permissions are ready. Keep the four steps in order: valid configuration, clear mode, traffic routed through the core, and a verifiable path. If something goes wrong later, check the first step that no longer behaves as expected; it’s easier to find the cause than by toggling several settings at once.