Step 1: Import a Subscription
Open the client and go to Config or Subscription. Look for an option such as New, Add, or Import from URL. Paste the full Clash-compatible URL from your subscription provider, then give it a recognizable local name, such as “Daily config.” This name only helps you identify the config on your device; it does not replace the subscription URL. Make sure you haven't copied any spaces, line breaks, or punctuation from the end of a message, then import or download it.
A subscription URL is not the same as a website login URL. An account homepage that opens in your browser usually can't be imported as a config, and a standalone node share link may not work in the subscription field. On your provider's site, choose a config format specifically labeled for Clash or compatible clients. If you have a different format, first read the subscription and config overview in Concepts at a Glance; don't try random URL changes.
Once the request finishes, the page will usually show a config card or entry, possibly with an update time, file name, or parsing result. Click Use, Enable, or the selection button to make it active. Downloading a config doesn't automatically switch to it: if the client has multiple subscriptions, the new one may still be inactive. Check for a selected indicator, then open the Proxies page and confirm that nodes or proxy groups are listed.
Local Files vs. Remote Subscriptions
If you have a local .yaml or .yml file, use Import from File, select it in the system file picker, and set it as the active config. Importing a file is useful for migrating an existing config, but it won't automatically receive remote updates. A remote subscription usually retains its source URL, so you can fetch the latest version with Update. For your first setup, use just one import method to avoid adding the same config twice and accidentally selecting an old copy.
If the client reports a download failure, first check your internet connection and make sure the URL is complete. Then look for messages about expiration, access restrictions, or authentication errors. A failed subscription update and a failed proxy connection happen at different stages: in the first case, you don't have a config yet; in the second, you have a config but the proxy exit isn't working. Some subscription services aren't directly accessible from your current network. Use an access method supported by the provider; a client with no working proxy nodes can't download through a proxy it doesn't have.
You're done with this step when: The config is selected and the Proxies page shows the expected proxy groups and nodes. If the list is empty, check the import results before proceeding; changing modes won't make missing config entries appear. Once the config loads correctly, you can choose how traffic should be routed.
Step 2: Choose a Proxy Mode
Find Mode on the client's home or settings page. For a first setup, choose Rules. Rules mode uses the current config's rules to decide where each connection goes; traffic may use a proxy group or connect directly. This keeps the subscription's existing routing behavior in place. For now, don't change the rules file, DNS mode, or sniffing options. Keeping other settings unchanged makes problems easier to isolate.
Global mode usually sends connections that reach the core through the global proxy policy, making it useful for a quick comparison test. Direct mode connects directly by default. These modes only control traffic that has already reached the core; they don't enable the system proxy or a mobile connection. So choosing Global doesn't mean every app is using the proxy.
Choose an Exit in the Proxy Group
Next, open the Proxies page. You may see groups such as Proxy, Auto, or groups named for specific uses rather than a flat list of nodes. Open the group most commonly referenced by the rules and choose an available node. If it points to another group, check that group's selection too. Don't assume the active exit based on a card's position; look for the selected indicator or expand the proxy chain.
Manual selection groups usually use select, so you choose a member explicitly. Automatic test groups usually use url-test to choose an exit based on the configured probes. Click Test Latency or a similar option, wait for the results, and start with a node that responds. A latency result reflects only a specific probe; it isn't a download speed test and doesn't guarantee access to every site. A node with no test result isn't necessarily down.
If a group includes DIRECT, selecting it usually makes that group connect directly; it does not enable the proxy. For your first test on a site that should use the proxy, select an actual proxy node or a subgroup that contains proxy nodes. A subscription may use different groups for different sites, so changing one group may not change every site's exit. For details on routing, see Proxy Group Fields and Rule Syntax.
You're done with this step when: Rules mode is active and the proxy group expected to handle proxied traffic has an exit selected. The config and exit are ready, but apps on your device may not be using them yet. Next, route app traffic to the client's core.
Step 3: Connect
Check the client's home page for its status. Some desktop clients start the core when the app opens; others require you to click Start or Connect. If the status is Stopped, start the core and check for any specific errors before enabling traffic routing. An open app window only means the interface is running; it doesn't confirm that the core loaded the config or is listening on a local port.
Desktop: Start with the System Proxy
Find and enable the System Proxy switch in your desktop client. It usually points the operating system's proxy settings to the local address where the client is listening, so browsers and other apps that honor system settings send requests through the client. You don't need to enter a port manually for your first setup. If you've configured another proxy in your system or browser, note the existing settings before changing them to avoid conflicts.
After enabling it, check that your browser uses the system proxy. Browsers with their own proxy extensions or custom network settings may bypass the system setting. Temporarily disable conflicting extensions or restore the browser's default system proxy setting, then test in a new tab. System proxies may not work with terminal tools, games, or some built-in network components. Once browser testing works, configure those apps individually rather than treating them as one test.
TUN is a separate routing method and usually requires a system service, virtual network adapter, or additional permissions. It can capture some traffic from apps that ignore the system proxy, but you don't need it for your first browser test. To keep things simple, use the system proxy alone for now. If you need to route traffic from more apps, first verify this setup, then read the TUN Mode Guide and check permissions, routing, and DNS one at a time.
Mobile: Approve the System VPN Request
In the Android or iOS client, make sure the config and exit are selected, then tap Connect or Start. The first time you connect, the system usually asks to add a VPN configuration or allow a VPN connection. Check which app is making the request and follow the system prompts to allow it; some devices require you to unlock the screen to confirm. Return to the client and check that it shows Connected, then verify the VPN status in system settings.
A VPN icon on mobile only confirms that a local tunnel or interface has been created. It doesn't confirm that the remote node is reachable or that every request uses the proxy exit. If another app is using the VPN interface, stop it before connecting this client, then check the status again. Keep the client in the foreground during your first test so background restrictions and battery settings don't get confused with proxy issues.
If the Connect button immediately switches back to Disconnected, open the logs and look for the first error. Config parsing failures, port conflicts, and missing permissions each need a different fix. Don't repeatedly tap Connect or change nodes and DNS before checking the error. If the interface or system permission prompt is unclear, look for platform-specific setup help in the Help Center.
You're done with this step when: The core is running, the desktop system proxy is enabled, or the mobile VPN connection is active. The routing path is in place; next, check whether requests actually reach the core and use the expected exit.
Step 4: Verify the Connection
In your browser, open a site that should use the proxy. Choose a page you know and expect to be accessible right now. Then return to the client's Connections page and find the request you just made. Clients show different fields, so focus on the target domain, matched rule, and proxy chain. If there's a filter, enter the domain to narrow the list. Short-lived connections may disappear quickly, so check connection history or the logs if needed.
Success isn't just a Connected icon: the test page should load, the connection log should show the site you visited, and the rule and proxy chain should match what you expect. For example, if a rule points to a proxy group, the chain should end at the selected node. A request expected to connect directly should show a direct connection. If the page loads but the log says Direct, that proves the page is reachable—not that it used the proxy.
Use a Comparison Request to Separate Routing from Connection Issues
Visit a site that should connect directly and compare its connection log. In Rules mode, the two requests using different exits is expected; it doesn't mean the connection is intermittent. You can also check your exit IP on a trusted site, but check which rule the IP lookup request matched: if it was routed directly, seeing your regular network's IP is expected. An IP lookup only shows the route for that request, not for every app on your device.
If your first test fails, keep the troubleshooting steps in order. Turn off traffic routing and make sure your local network can still reach regular sites. Turn it back on and confirm that the active config, mode, and proxy group haven't changed. Then check whether the failed request appears on the Connections page. If there's no entry, check the browser's proxy settings, core status, and routing switch first. If the request reaches the core but times out, check the selected node, destination, and specific error in the logs.
If the group has other available nodes, switch only the node and repeat the same test. Don't update the subscription, change DNS modes, enable TUN, and switch browsers all in one go; even if access starts working, you won't know which change fixed it. If you suspect a rule-routing issue, temporarily switch to Global, explicitly select a global exit, and run a comparison test. Switch back to Rules afterward; this still doesn't replace checking that traffic reaches the core.
DNS leaks, apps bypassing the proxy, and failures with specific protocols each need a separate investigation once you know what is happening. A single page loading doesn't prove or rule out any of them. Note the app, destination domain, current mode, and log error, then continue troubleshooting in the Help Center. For config changes, see the DNS Config Reference; don't replace your current setup with a full config from another platform.
You're done with this step when: The site expected to use the proxy is accessible, the client log shows the expected rule and exit, and the site expected to connect directly follows its rule too. Keep these simple comparison tests so you can repeat them after changing networks or updating the config.
Save Your Setup and Use It Day to Day
After your first successful test, note the active config name, proxy mode, and main proxy group. Subscription updates can change node names or group members, so your previous manual selection may no longer work. If access fails after an update, first check the selected config and proxy group, then repeat step four; you don't need to reinstall the client right away. When editing rules, prefer the client's separate override feature. Check the client documentation for how to save it.
When you're done, turn off the system proxy on desktop before exiting the client. On mobile, tap Disconnect and confirm that the system VPN has stopped. If your browser can't access regular sites after you exit, check whether the system still points to a local proxy port. Restoring network settings and deleting a config are separate actions; don't delete your subscription just to turn off the proxy.
That completes the basic first-connection setup. From here, choose the next guide based on what you need: read Concepts at a Glance if you're unsure how nodes, proxy groups, and rules work; visit the Help Center to troubleshoot specific errors; or use the YAML Handbook to edit YAML, DNS, or overrides. Change one thing at a time and retest with the same requests to keep your config changes traceable.