Step 1: Import a Subscription
Open the client and look for Profiles, Subscriptions, or a similar section in the sidebar or bottom navigation. If there are no configuration cards yet, select Add, New, or Import, then choose the option for a remote URL. Paste the subscription URL from your provider. You can give it a short, recognizable name, then confirm. Don’t use the URL of your provider’s login page; the client needs a link that returns a compatible configuration.
After pasting the URL, check for leading or trailing spaces, line breaks, or punctuation added by your chat app. Some providers offer both a general-purpose link and a Clash-specific one; choose the link explicitly marked for your client. Subscription URLs often contain account credentials. Don’t post one in a public forum or submit the full URL to an unfamiliar online converter. If you need help, hide URL parameters, account details, and node authentication fields, and share only the error type.
After selecting Import, wait for the client to download and parse the configuration. On success, a configuration card usually appears with its name, source, or last update time. Select the card or choose Enable or Use This Profile from its menu. Adding a configuration to the list doesn’t always make it active. Confirm that the card is selected, then open Proxies and check that policy groups and nodes are listed.
To import a local YAML file, choose Import from File, open the file in your system’s file picker, and enable it as you would a subscription. Local files may not have a remote update source; automatic updates depend on how the configuration was provided. Keep a copy of the original file, and avoid changing rules, DNS, and ports all at once before your first connection. This makes it easier to spot configuration issues.
No Nodes Listed? Check the Import First
If a configuration card appears but the Proxies page is empty, return to Profiles and confirm that the imported configuration is selected. Then check notifications or logs for parsing errors. The client may fail to load if the link returns a login page, has expired, or contains an incompatible configuration. Toggling the system proxy won’t fix this; start by checking the configuration source. If a remote subscription is temporarily unavailable, you can import a local configuration if your provider offers one. Don’t install tools from untrusted sources.
The goal at this stage isn’t just to paste the URL. The configuration must be enabled, and the Proxies page must show an available node. Once that’s confirmed, continue to the next step. For details on subscription updates and merging configurations, see the handbook after your connection is working.
Step 2: Choose a Proxy Mode
Open Overview or Proxies and find the Mode setting. Common options include Rule, Global, and Direct. For your first setup, choose Rule: the client uses the configuration’s rules to decide whether each request goes direct, through a proxy, or gets rejected. This setting determines how requests that reach the core are handled; it does not make every app send its traffic to the client automatically.
After selecting Rule mode, check the policy groups on the Proxies page. Group names come from your subscription and may include Node Selection, Proxy, or a service-specific label; they aren’t always called PROXY. Expand the main group and select a node. Confirm that the selection indicator moves to that node. If the group points to another group, expand it too and check the final proxy. Otherwise, the top-level group may appear selected while traffic actually goes DIRECT or through an unavailable subgroup.
Some configurations have separate policy groups for video, messaging, or other sites. For your first connection, change only the main group used by your rules and leave the others as they are. Don’t set every group to the same node just to make the page look tidy; some groups are designed for direct connections, automatic selection, or failover. Changing them can alter how the configuration is meant to work. For an overview of group relationships, see Clash Policy Groups.
Test Node Latency and Choose a Proxy
On the Proxies page, look for a button labeled Latency Test, Test, or represented by a refresh-style icon. Run a test for the current group, wait for the results to settle, then select a responsive node. These tests typically measure response time to a specified test URL, not download speed, and they don’t guarantee that every site will load. If a low-latency node can’t reach your target site, check the service, proxy location, and connection log.
If a node times out, try another node in the same group before reinstalling the client. If all nodes time out, first confirm that your regular internet connection can reach everyday sites, then check your subscription status and whether the configuration loaded successfully. Some automatic groups test nodes on a schedule and switch proxies for you; with manual groups, you must select a node yourself. For your first test, choose a specific node so the result is easier to reproduce.
Global mode can help with a quick comparison: it sends requests that reach the core to the global policy, but you still need to select an available proxy in that policy. Direct mode usually sends requests without a proxy. Neither mode is a substitute for troubleshooting your rules. Stay in Rule mode, note the selected node, and then route traffic so you have a clear baseline for the next step.
Step 3: Connect
Return to Overview or Settings and check that the core is running. Some clients start it automatically; others require you to select Start or Connect. If the status is Stopped, check the startup error shown in the interface. If a port is already in use, the configuration failed to parse, or the service is unavailable, enabling the system proxy won’t help: there’s no local proxy service to handle requests.
Desktop: Enable the System Proxy First
In the desktop client, enable System Proxy. This points your system’s proxy settings to the local address and port the client is listening on. Only apps that support and honor those settings will use it. A common mixed port is 7890, but use the value shown in your client; the port in a guide isn’t universal. For your first test, use a browser that normally follows the system proxy, then close and reopen the test page.
Leave TUN off for now, and don’t run another proxy client at the same time. Multiple apps can compete to control system proxy settings, while two traffic-routing methods can interfere with each other and make results hard to interpret. If you or your browser previously set a manual proxy, check whether it still points to an old port. Browser extensions can also override system settings. A clean test window is a better way to isolate issues than changing every network option at once.
The system proxy doesn’t route traffic from every app on your device. Some command-line tools, games, and apps with their own network stack may ignore it. If a browser works but one of those apps doesn’t, that doesn’t necessarily mean the node is down. First complete the browser test on this page, then learn about TUN setup in the handbook if needed. Virtual adapters, routing, and DNS add variables, so it’s best not to change them while importing your first subscription.
Mobile: Approve the System VPN Prompt
When you tap Start or Connect on mobile, the system may ask for permission to create a VPN connection. Make sure the prompt is for the client you just installed, then approve it as requested. Return to the client and check whether its status has changed; you may also see a VPN icon in the status bar. If another VPN is running, check for a conflict: in most common setups, two VPN connections can’t be active at the same time.
A VPN icon alone doesn’t confirm that a node is working. It usually means only that the system tunnel is up; successful requests also depend on your configuration, proxy, and network. After connecting, keep the client in the foreground and open a browser to run the next test. Once that works, check that the connection remains stable with the screen locked and the app in the background. This helps distinguish battery-management issues from first-time setup problems.
Step 4: Verify It Works
Keep Rule mode and the node you selected, then open a site that should use the proxy under your current configuration. Once it loads, open the client’s Connections page and search for the domain. Check the matching rule, policy group, and final proxy. Some interfaces show only part of the policy chain; expand the connection details if needed. Seeing the expected proxy policy in the log tells you more about the request’s actual route than the status icon on the home screen.
Next, open a familiar site that should connect directly and check its connection log too. If each request uses the expected route, basic rule-based routing is working. Rules vary by subscription, so a site’s name alone doesn’t tell you whether it should be proxied or direct; check your active rules. With the system proxy, some bypassed requests may never reach the core, so interpret missing entries alongside the system’s bypass list.
An IP lookup can provide a useful extra check, but it isn’t conclusive on its own. The lookup site may itself match a Direct rule, and the reported location depends on its database. For a more reliable picture, consider the page result, connection log, and matched rule together. If you just switched nodes, refresh the page or reconnect before checking again; existing long-lived connections may still use the previous proxy.
No Internet Access? Troubleshoot in This Order
First confirm that the configuration is enabled and nodes still appear on the Proxies page. Next, check that the mode is Rule and that the main policy group hasn’t selected Direct or Reject by mistake. Then try another responsive node. Check that the core is running and that the system proxy or mobile connection is enabled. If your test request never appears on the Connections page, first find out whether traffic is reaching the client instead of repeatedly changing nodes.
If the request appears but fails, expand its entry and check the logs. For a DNS resolution failure, start with the DNS path. A connection timeout may involve the node, network route, or destination service; an authentication error means you should check your subscription. Treat log errors as clues, not as a diagnosis based on the last English word alone. Change one setting at a time, retry the same request, and note what changes. Otherwise, if you change the node, mode, and DNS together, you won’t know which one fixed the problem.
To compare with your regular network, turn off the system proxy before stopping the core on desktop. On mobile, disconnect the client first. Check whether everyday sites work on your original connection, then restore the configuration and try again. Don’t reset all network settings as a first step; that can affect other saved configurations. For UWP apps, virtual adapters, or more advanced routing issues, see UWP loopback and system traffic routing and the troubleshooting chapters in the handbook.
Everyday Use After Verification
For everyday use, follow the same order: start the client, confirm the configuration, choose a proxy, and route traffic. Update subscriptions on the Profiles page, then check that the current policy group still has a valid selection. If your provider removes or renames a node, the previous selection may no longer work. Subscription update time, client update time, and core update time are separate; you don’t need to reinstall the software just to refresh your nodes.
Keep this verified baseline, then enable background operation, automatic updates, or launch at startup one at a time. Before customizing rules or enabling TUN, back up your configuration and follow the relevant section of the Clash handbook. You’re done when the configuration loads, you can select a proxy, requests reach the client, and the connection details show where a proxied request and a direct request actually went.