Clash Setup Guide:
Import a Subscription and Test Your Connection

1. Import a Subscription and Activate the Configuration

Open your provider's subscription management page, find the configuration option labeled Clash, Clash Meta, or mihomo, and copy the full subscription URL. Treat it like a credential, since it may contain personal access tokens. Don't share it in group chats, screenshots, or unfamiliar online conversion tools. If you need help, describe the error and hide the full URL.

Return to the client and open Subscription, Config, or Profiles. Choose Add, Import, or the equivalent plus button. If prompted for a configuration type, select remote subscription. Paste the URL, then enter a local name you can recognize. Check for spaces or line breaks at either end, then click Download, Save, or Import. Wait for the request to finish before continuing; don't click repeatedly and create duplicate entries.

After a successful import, the configuration should appear in the list. Select it or choose an option such as Enable or Set as Active. Some clients treat downloading and activating as separate steps: seeing the name in the list doesn't mean the core has loaded it. Check which configuration is active, then open the proxy page and confirm that proxy groups and their nodes are listed.

For a local file, choose Import from File and locate the existing config.yaml or another YAML configuration. Activate it after importing. A filename doesn't determine whether the contents are compatible; don't rename an HTML file saved from a webpage to YAML, or treat a single node link as a complete configuration. For your first setup, use a format your provider explicitly supports and avoid editing fields before import.

If you see a “parse failed” error, first make sure you copied a subscription URL, not the provider's home, sign-in, or payment page. If the request fails, check that the link is still valid and the service is available on the original management page. Subscription URLs may contain sensitive data, so don't paste them into random external tools to inspect the response. If the import succeeds but no nodes appear, check which configuration is active and ask your provider whether the subscription includes nodes.

Before moving on, confirm both that the configuration is active and that the proxy page shows selectable nodes. There's no need to change the update interval, DNS, or ports yet. Learn more about the difference between subscriptions and configuration files in the Quick Reference. If imports keep failing, use the Troubleshooting Guide to investigate subscription issues.

2. Choose Rule Mode and a Proxy Node

Once the configuration has loaded, open Proxy, Mode, or the mode selector on the client home screen. For your first setup, choose Rule. Rule mode follows the configuration's rules to decide whether connections go direct, through a proxy group, or are blocked. It's a good starting point for everyday use, but routing depends on the configuration and may not match your expectations for every site.

Some interfaces also offer Global and Direct modes. Global mode generally routes connections that reach the core through the global policy; it can be useful for a quick comparison. Direct mode generally sends those connections without a proxy. The important distinction is “connections that reach the core”: changing modes doesn't enable the system proxy or VPN, and apps that aren't routed through the client won't use a proxy just because Global mode is selected. Stay in Rule mode for now; switching modes repeatedly isn't a substitute for setting up the connection.

Next, check the proxy groups. Their names come from your subscription and may include options such as “Proxy” or “Auto.” Expand the main group used for proxied traffic and select an available node. If the group points to another proxy group, check that group's final selection too, and make sure it hasn't ended up on an unintended DIRECT policy. Don't change a group just because its name stands out; the rules may not use it.

If the client offers a latency test, run it once to rule out nodes that clearly can't establish a test connection. The result applies only to the test target; it doesn't measure bandwidth or guarantee access to every site. A timeout could be caused by the test address, your local network, or the remote service. Pick a node that passes the test and continue; there's no need to chase the lowest number yet.

With an automatic selection policy, the controls and behavior may differ from manual selection. You can keep the subscription's default automatic group or choose a node in a main group that supports manual selection. Either way, note the final policy so you can compare it with connection logs in step four. If the client offers Apply or Reload, follow its prompt. If changes take effect immediately, there's no need to restart the client.

You're ready to connect once Rule mode is selected and the main proxy group has a clear choice. For how rules, proxy-groups, and MATCH work together, see Rules and Routing Terms. You don't need to edit the rules or replace your entire subscription with an example configuration from the web.

3. Enable the System Proxy or Approve the VPN Connection

Return to the client home screen and check that the core or service is running. An open interface doesn't mean the proxy service has started. If it shows stopped, failed to start, or a port conflict, resolve that first. Once it is running, follow the steps for your platform below. Desktop system proxy settings and mobile VPN permissions are separate options.

Desktop: Start with the System Proxy

On Windows, macOS, and desktop Linux, you can usually start by enabling the client's System Proxy toggle. This points supported system proxy settings to the local proxy port, routing apps that honor those settings through the core. On macOS, if the client asks to change network settings or install a required service component, verify the prompt comes from the client you just installed before approving it. Desktop Linux support varies by environment. If the client can't update system proxy settings, enter the local address and port shown in the client under your desktop network settings.

Use the address and port shown in the client's current settings. HTTP or mixed proxies typically use the local address 127.0.0.1; read the actual port from the interface rather than copying a number from another guide. The HTTP proxy port may differ from the SOCKS port. You don't need to enable Allow LAN for your first connection, and you shouldn't expose the proxy listener to an untrusted network.

Once the system proxy is on, a browser is usually a good way to test the connection. Terminal tools, games, and some apps may ignore system proxy settings, so their traffic not being routed doesn't mean the node is down. Get the browser test working first, then configure a separate proxy for any apps that need one. Look into TUN only if you need to route more traffic. For now, don't enable the system proxy, TUN, and another VPN at the same time; it makes the traffic path difficult to diagnose.

Mobile: Approve the System VPN Request

On Android or iOS, return to the client home screen and tap Connect, Start, or the equivalent toggle. The first time you connect, the system will usually ask to add a VPN configuration or establish a VPN connection. Check the app name and approve the request. iOS may also ask for your device passcode or biometric confirmation. If you deny permission, the connection won't start; return to the app and try again. There's no need to remove the imported subscription.

After granting permission, check that the client shows Connected and confirm the status in the system VPN settings or status area. Phones typically can't keep multiple standard VPN apps connected at once, so disconnect any other active VPN first. On Android, if per-app proxying is enabled, make sure the browser you're testing is included. On iOS, if the connection drops shortly after starting, keep the app in the foreground and check for an error before moving on.

Once the core is running and the desktop system proxy or mobile VPN is connected, move on to the final step. “Connected” only confirms that local traffic routing is active; you still need to test whether the remote node and destination site are reachable.

4. Check Access and Rule Matches

Open a new browser tab and visit a site that normally works to make sure the network still works after your changes. Then visit a site that should use the proxy under your current configuration and wait for it to load. Don't rely only on a client toggle, tray icon, or latency test; whether the page loads and stays usable is part of verifying the connection.

While browsing, return to the client's Connections or logs page and find the entry for the site you just opened. If search is available, enter the domain to narrow the results. Check the destination, matched rule, and final policy chain: a site expected to use the proxy should show the relevant proxy group or node, while a direct connection may show DIRECT. Cached requests may not create a new connection entry. If needed, refresh the page or test a site you haven't opened yet.

If the site loads and its connection entry matches your expectations, keep the current settings. An IP lookup can provide a useful cross-check, but it only shows the exit used for that particular request and doesn't prove every app is routed through the proxy. In Rule mode, different sites using different policies is normal; don't switch to Global just because two sites show different exit IPs.

If a site won't load and there's no matching connection entry, first check whether its traffic is reaching the client. On desktop, make sure the system proxy is still on and no browser extension has set a separate proxy. On mobile, check that the VPN is connected and the app you're testing is included in the routed traffic. If a command-line tool can't connect but the browser works, check whether the tool supports proxies before changing nodes or DNS.

If a connection entry appears but the request fails or stays stuck connecting, the traffic has at least reached the client. Check the final policy first, then switch just one node and retry the same destination. If only one site fails, check the rule matched for its domain. If several destinations fail, check the subscription service and local network. For domain resolution errors in the logs, note the error summary and follow the DNS and node timeout steps in the Troubleshooting Guide. Don't overwrite your current settings with DNS configuration from an unfamiliar source.

Finally, test how to disconnect and restore your regular network. On desktop, turn off the system proxy before quitting the client, then confirm ordinary sites still load. On mobile, disconnect the VPN and check basic access too. Reopen the client and make sure the active configuration, Rule mode, and proxy group selection are still correct before connecting again. Enable convenience features such as launch at startup, auto-connect, or automatic subscription updates only after the manual setup is reliable.

Your first connection is set up. For everyday use, stay in Rule mode and check the active configuration and node selection after subscription updates. See the Quick Reference for configuration fields. If problems persist—such as no internet access, failed updates, or a system proxy that doesn't work—consult the Troubleshooting Guide rather than reinstalling the client from scratch.