Clash Setup Guide: Import a Subscription and Test Your Connection

Step 1: Import a Subscription and Enable the Configuration

Start here: installing the client doesn't give you a working proxy. Before you begin, get a Clash-compatible subscription URL from your service provider or a working YAML configuration file. Subscriptions typically contain nodes, proxy groups, and routing rules; the client reads and applies them. Don't use the URL of a provider's login page, order page, or regular share page as a subscription. These may return a webpage instead of configuration data, causing an import error.

Add a Remote Subscription

Open the client and go to “Configuration,” “Subscriptions,” or “Profiles.” Look for “Add,” “Import,” or a plus button, then choose “Remote Subscription” or “URL.” Paste the full link into the address field. Add a name to identify it if you like, then click “Save,” “Import,” or “Download.” If “Save” and “Update” are separate actions, save first, then update and wait for the download to finish.

Check for extra spaces, line breaks, or punctuation added by your chat app before pasting the link. Some clients can import from the clipboard, but verify the address even if it is recognized. Your subscription token is a credential: never post the full subscription URL in a public comment or screenshot. The example below only shows what a link looks like; it doesn't provide a proxy and you don't need to open it.

https://example.com/sub?token=xxxx

If your provider offers multiple subscription formats, choose the one they specify for your Clash or mihomo core. A link opening in a browser doesn't mean it returns usable configuration data. If you see “parse failed,” “unsupported,” or no proxy nodes, check the format on the subscription page first. Don't submit a private subscription to an unfamiliar online converter. See Troubleshooting for more help.

Check the Import and Set the Active Configuration

After a successful update, the configuration list usually shows a name, update time, or status. Click “Use” or “Activate,” or select the relevant card. Then open the “Proxy” page and check that proxy groups and nodes are listed. A common mistake is to download a configuration but keep using the old one: a configuration appearing in the list doesn't mean it's active. Check the selected state and the contents of the Proxy page, not just the download notification.

If you have a local YAML file, choose “Import from file” and select the configuration file—not a compressed archive. Keep the original file intact and don't rewrite its contents during your first setup. Once the configuration loads and proxy groups appear, continue to step two. If the import itself fails, fix that first; there's no need to change system proxy or DNS settings yet.

When nodes change later, use “Update” on the existing subscription; you usually don't need to add it again. An update may overwrite edits made directly to the subscription file, so this guide doesn't ask you to modify the original. To preserve custom rules, see the YAML guide to overrides and merging. Avoid adding those variables during your first connection.

Step 2: Choose a Rule Mode and Proxy Node

Once the configuration is active, open “Proxy” or “Proxies.” Find the “Rule,” “Global,” and “Direct” modes, and select Rule first. The mode determines how requests that reach the core are routed; it doesn't automatically send every app through the proxy. Choose a routing mode now, then enable the system proxy or VPN in the next step. These are separate settings.

Use Rule Mode for Everyday Browsing

Rule mode checks requests against the rules in your configuration. A request may go direct or be sent to a proxy group. Global mode sends requests that reach the core through the global proxy; it doesn't mean every app's traffic is being captured. Direct mode sends requests that reach the core straight to their destinations; it doesn't turn off the system proxy. Unless you have a specific reason to change it, keep Rule mode and avoid switching back and forth.

“Global mode is always faster” is a common misconception. Speed depends on the node, destination, network congestion, and your local connection; changing modes can't improve those conditions on its own. If a website behaves unexpectedly, you can briefly test it in Global mode, then switch back to Rule mode. Otherwise, services that should connect directly may use a different route. For details, see Rule, Global, and Direct Modes Explained.

Choose a Node in the Proxy Group Your Rules Use

After choosing a mode, expand the main proxy group and select a node. Group names come from your subscription and may be “Select Node,” “Proxy,” or something else—not necessarily PROXY. Some configurations route different services through different groups, so changing a group outside the main route may not affect the website you're testing. For your first connection, find the primary group used by the configuration and avoid changing every group at once.

Run a “Latency Test” or “Connection Test” and check whether it times out. The test uses a destination specified by the client, and latency isn't the same as download speed. A successful test also doesn't guarantee every website will work. If one node times out, try another. If they all fail, check your subscription status, local network, and client logs before changing the whole configuration. For more on test results, see Node Latency and Connection Troubleshooting.

With an automatic group, the client may change the route based on test results. With a manual group, the node you selected usually stays selected. To make troubleshooting easier, choose one working node for your initial test and note its name. At this point, you should know which configuration is active, which mode is selected, and which proxy group is expected to handle requests. Then connect.

Step 3: Enable the System Proxy or VPN Connection

Now route app traffic through the client. Running the core and routing traffic through it are two different things: some desktop clients start the core automatically, but your browser may not be using it yet. On mobile, importing a configuration usually doesn't connect automatically; you still need to tap Connect. Quit other proxy clients before getting started to avoid conflicts with system settings. Don't try to stack multiple VPN connections.

Desktop: Check the Core, Then Enable the System Proxy

Check the client home screen or “Settings” to make sure the core is running, then turn on “System Proxy.” If the client asks to install a helper service or requests permission to change network settings, verify where the prompt comes from before approving it. Once enabled, browsers and apps that follow system proxy settings will send requests to the local listening port. Some terminal tools, games, and apps with their own network settings may not follow it automatically.

For your first connection, keep the client's default port and leave “Allow LAN” off. The example below shows local listening settings for reference; don't paste it over your entire subscription. Use the port shown in your client. Don't force every system setting to 7890 just because this guide uses it as an example.

mixed-port: 7890
allow-lan: false
mode: rule

mixed-port is the shared listening port for HTTP and SOCKS. allow-lan: false restricts access from your local network. If the logs say the port is already in use, first check for another client or an older instance still running. Don't terminate unfamiliar system processes. If you need to change the port, do so in the client settings and reapply the system proxy so both values match. See How to Troubleshoot a Port Conflict for details.

Desktop environments on Linux don't all handle system proxy settings the same way. If the client has enabled the system proxy but your browser still isn't using it, check the desktop environment and browser network settings. TUN can handle traffic that system proxy settings don't, but may require changes to permissions, routing, and DNS. Test a basic browser connection first, then consult the YAML guide if needed. Don't enable TUN, change DNS, and edit routes all at once.

Mobile: Approve the System VPN Permission

On Android, tap Start or Connect on the home screen. The first time, Android will usually ask you to approve a VPN connection. Confirm, then wait for the client to show Connected and check for the VPN icon and ongoing notification in the status bar. The VPN is Android's way of routing traffic through the client; it doesn't provide a separate proxy service. Your actual route still depends on the imported configuration and selected node.

On iOS, tap Connect and allow the client to add a VPN configuration if prompted. Complete any authentication required by the system, then return to the client and check the connection status. If you deny permission, check the client's VPN permission in system settings and try again; reimporting the subscription won't fix a permissions issue. If Android disconnects only after the screen locks, check background activity and battery restrictions. See Background Disconnections and Battery Settings.

Step 4: Test Real Requests and Routing

A lit connection icon only confirms that a toggle or connection state is active. You're done when the target page loads and traffic follows the expected route. Keep the configuration and node unchanged for a simple browser test, then check the connection log. If a page won't open, don't immediately change the node, mode, and DNS all at once—you won't know which change helped.

Cross-Check Two Websites Against the Connection Log

First reload a regular website you can normally access to confirm your local connection still works. Then open a website you expect to reach through the proxy. To reduce cache interference, try a new private window, but note that private browsing doesn't bypass every DNS or system cache. If the page loads, return to the client's “Connections” page and check the requested domain, matched rule, and outbound policy.

The fields vary by client: some show the full policy chain, while others show only the destination and outbound route. Check whether the request is DIRECT or uses the selected proxy group and node. In Rule mode, some sites should connect directly; not every connection needs to use a proxy. One direct connection doesn't mean the client isn't working—one page may request resources from several different domains.

An IP lookup page only shows the route used to access that page; it doesn't represent traffic from every app or domain. The site may be set to connect directly, and your browser may use a different route from other apps. Don't reinstall the client just because your IP didn't change, or assume every app is covered just because it did. Check both the target website and its corresponding connection log for a reliable result.

Narrow Down the Problem Based on What You See

If no new browser requests appear in the client, check whether the system proxy is enabled, whether the browser has its own proxy settings, and whether the listening ports match. On mobile, confirm the VPN is connected and that no app-exclusion rules are enabled. If requests appear but time out, test another node. If only one domain fails, check its matched rule and the logs. Don't change all your network settings because of one website.

If regular websites stop loading even after you turn off the proxy, disable the system proxy or disconnect the VPN in the client, then check whether your system still points to a local proxy port. Make sure your local connection works again before comparing proxy behavior. For parsing errors, certificate errors, or frequent disconnects, note the exact error and when it occurred, then use Troubleshooting to investigate. For help understanding configuration fields, see the YAML Configuration Reference; you don't need to learn every option to get started.

Everyday Use After Verification

Once the connection works, keep Rule mode and update your subscription as needed. If an update changes node or group names, check your selection again rather than assuming it stayed the same. When you're done, turn off the system proxy before quitting the desktop client, or disconnect the VPN on mobile. This prevents apps from sending requests to a local proxy port after the client has stopped listening.

Remember the order: valid configuration → selected route → traffic routed through the client → real-world test. Change one thing at a time and test again; it's easier to find the cause than by reinstalling repeatedly. When asking for help, share the client name, operating system, steps that failed, and a redacted error message. Don't include subscription tokens, account details, or your full private configuration.