Before You Begin: Prepare the Client and Subscription
The Clash client reads your configuration and handles traffic, but installing it does not provide a working proxy service. Before continuing, get a subscription URL from your service provider or a local configuration file with usable outbound settings. The subscription must also be compatible with the client’s core. A share link, webpage URL, or account login page alone does not mean you have an importable Clash configuration.
Keep your regular network connection available. Open a website you normally use and make sure your device’s date and time are correct. If another proxy or VPN is running, disconnect it first to prevent multiple apps from changing system proxy settings, routes, or DNS at once. You can leave other clients installed, but enable only one network-traffic entry point during this test. That makes it easier to pinpoint where something goes wrong.
Subscription URLs may contain account-identifying parameters, so treat them like account credentials. Don’t post the full URL in public comments, screenshots, or online conversion tools. If you need help, describe the error and redact the subscription URL, node credentials, and controller details. The steps below don’t require you to share this information or change advanced configuration fields.
01 Import a Subscription and Enable the Configuration
Find the subscription option for Clash or your current client on your service provider’s account page, then use the copy button to copy the full URL. In the client, open “Configuration,” “Subscription,” or a similarly named page and look for “New,” “Add,” or “Import from URL.” Paste the address into the subscription URL field. If there’s a separate name field, you can enter a label for easy identification; it won’t affect the connection. Make sure the URL has no leading or trailing spaces or line breaks, and that you haven’t copied any surrounding instructions. Then submit the import.
Some service pages offer one-click import. When you click it, your browser may ask whether to open the local client. Confirm that it’s the app you installed before allowing it. If the client doesn’t respond, don’t keep clicking; switch to manual paste instead. Manual import makes it easier to check the URL and review download errors, and avoids confusion if the browser hasn’t registered the app link. Whichever method you use, check the result in the client rather than relying on the browser’s confirmation.
Wait for the client to download the configuration. A successful import usually adds a configuration entry, and the “Proxy” page should show policy groups or nodes. Select the new entry and choose “Enable,” “Set as current,” or the equivalent option. Adding a subscription to the list doesn’t always make it the active configuration, so confirm that the current-configuration indicator points to the entry you just imported. Some clients automatically enable the first configuration, but it’s still worth checking.
If you have a local .yaml or .yml file, choose “Import from file,” open it in the file picker, and enable it the same way. A local file won’t automatically receive subscription updates; if your provider changes the nodes, you may need to download the file again. Simply changing a text file’s extension doesn’t make it a valid configuration—the client must be able to parse its contents.
When an import fails, first identify where the error occurred: a download timeout means the content couldn’t be retrieved over your current network; an authentication error calls for checking the URL and service status; a parsing error means you should confirm the subscription format and core support. Don’t delete unfamiliar fields just to get the import to work. Copy the URL again in the correct format from your service page, then try a manual update. For more help, see installation, setup, and troubleshooting in the Help Center.
Before moving on, confirm at least two things: the configuration is selected, and the Proxy page shows an outbound group or node to choose from. If the page is still empty, fix the import first. Enabling the system proxy won’t add missing nodes or make an incompatible subscription work.
02 Choose a Rule Mode and an Outbound Node
After enabling the configuration, open the client’s home page, Proxy page, or mode selection in Settings. For a first setup, choose “Rule” mode. Requests are routed directly or sent to a proxy group according to the rules in the active configuration. Rule mode doesn’t send every website through the proxy automatically; it follows the subscription’s routing rules. When you verify the connection, check both the page load and the rule that matched.
“Global” mode generally sends requests handled by the core to the global policy selection, making it useful for a temporary comparison while troubleshooting. It doesn’t mean every app’s traffic is routed through the client. “Direct” mode sends requests handled by the core straight to their destination, so it can’t verify that a proxy node works. Distinguish between whether traffic reaches the client and how the client chooses an outbound route; switching to global mode does not enable the system proxy.
Keep rule mode selected, open the “Proxy” page, and expand the main selection group in your configuration. Group names depend on whoever created the configuration; you might see “Proxy,” “Node Select,” or another name. Find a group that lets you choose manually and select a specific node. If the group contains other policy groups, check the next level too until you can tell which actual outbound route the target request will use. DIRECT is not a remote proxy node; it means a direct connection.
If the client offers a connection or latency test, run it once to see whether the selected node responds. The result only reflects that node’s response to the specific test address at that time. It doesn’t guarantee that every website will load or indicate your actual download speed. If one node times out, try another. If they all time out, check that the subscription is valid, the system clock is accurate, and the client supports the protocol used by the subscription.
Nodes in an automatic selection group may be chosen based on test results, while a manual group keeps the node you select. For your first test, a specific manual choice makes issues easier to reproduce. Once everything works, switch to an automatic group if that better suits your needs. For now, leave the original rules and DNS settings unchanged. For more on policy group types, rule order, and overrides, see the advanced configuration guide—you don’t need to master all of it before your first connection.
03 Enable the System Proxy or Mobile VPN
After choosing a node, route the target app’s traffic through the client. On Windows, macOS, and Linux desktops, find and enable the “System Proxy” switch. This updates the operating system’s proxy settings so browsers and apps that follow them send requests to the local proxy port. The switch may be on the client’s home page, in the tray menu, or in Settings. After turning it on, confirm the interface shows that it’s enabled, and keep the client running—quitting and minimizing are not the same thing.
The first time you enable it, the system may ask for permission to change network settings or allow firewall access. Grant only the permissions required for the client’s current features; don’t open all network access just to connect one browser. If the system proxy switch turns itself off or the client reports that it can’t listen on a port, check the logs for the specific error. If the port is already in use, quit the other proxy app using it rather than repeatedly switching modes at random.
Some Linux desktop environments and apps don’t follow the shared system proxy settings. Having a system proxy button doesn’t guarantee that a particular app will use it. For your first test, use a browser known to support system proxy settings. Leave command-line tools, games, and apps that manage their own network connections until the basic route is working. Don’t assume a subscription has failed just because one app isn’t using the proxy.
Android and iOS typically start a system VPN tunnel from the client’s home screen using the Connect button. Tap it, then approve the system prompt to establish a VPN or add a VPN configuration. Check which app initiated the request before allowing it. Return to the client and wait for the connection status to stabilize, then check the status bar or the VPN section in system settings. Here, VPN refers to the device’s local traffic-routing mechanism; you still need a valid configuration and a working outbound route. A VPN icon alone doesn’t confirm that the remote node connected successfully.
If your phone is connected to another VPN, disconnect it before starting the current client. Android’s always-on VPN, block connections without VPN, or work profile settings may affect switching. Check those options in system settings only if you run into a connection restriction; there’s no need to change your network policies before a normal first setup. If the system pauses the client in the background and the connection drops, first confirm that it works in the foreground, then check the client’s background operation instructions.
TUN mode routes traffic through a virtual network interface, which works differently from the desktop system proxy and typically requires coordination with permissions, routes, and DNS. This guide uses the desktop system proxy or the mobile client’s default VPN connection; there’s no need to enable desktop TUN. If a target app doesn’t support the system proxy, see Advanced Config for when to use TUN and Fake-IP. At this point, the configuration, outbound selection, and traffic entry point should form a route you can test.
04 Test Website Access and the Actual Outbound Route
Keep the client running and open a browser that follows the system proxy. In a new tab, visit the target website. First check that the page actually loads, then open the client’s “Connections” or “Logs” page and look for the request you just made. A new tab reduces interference from an existing page, but may still reuse a connection or cache. If you don’t see a new log entry, refresh the page or, if needed, close and reopen the browser before trying again.
Check the target domain, matched rule, and outbound route in the logs. A log entry alone isn’t enough: confirm that the request used the expected proxy group and node. If the log shows DIRECT, the request was routed directly; a successfully loaded page doesn’t prove that the proxy route works. If the proxy group points to a different node, return to step two and check the group actually referenced by the rule—not just a similarly named group.
Next, open a website you can normally access directly to confirm that regular browsing still works in rule mode. This can reveal broader network problems after connecting. Don’t rely only on an IP lookup site: rule mode can route different sites through different exits, and the lookup site may be set to connect directly. Browser cache and existing connections can also affect what you see. Website access, the target request log, and the actual outbound route should all agree; that’s more reliable than checking for a change in one address.
If the target site won’t load and the client shows no corresponding request, go back to step three. Check that the system proxy is enabled, the browser isn’t using its own proxy settings, and no other VPN or proxy extension is interfering. If a request appears in the logs but fails or times out, check the current node and subscription status. If the connection is established but some domains keep failing, investigate DNS, rules, or the target site itself. Don’t reset everything at once.
You can briefly switch to global mode for comparison: try the target page again with the same node and browser. If it works in global mode but not in rule mode, focus on routing rules and group selection. If both modes fail, check the traffic entry point, node, or DNS. Switch back to rule mode when you’re done. For a step-by-step diagnosis, see the Help Center. Don’t leave a temporary test setting as the default by mistake.
Finish with a disconnect check. On desktop, turn off the system proxy, quit the client normally, and confirm that regular websites still load. If the network stops working after force-quitting, check your system network settings for a leftover proxy pointing to localhost. On mobile, disconnect the VPN in the client and check your regular network connection. Then restart and connect again to confirm that the configuration and node selection were retained. This can catch problems such as “works while running, but no internet after quitting” or “configuration isn’t enabled after restart.”
After Setup: Keep a Known-Working Configuration
Once you’ve completed the four steps, note the current configuration name, mode, and main proxy group selection. There’s no need to save a public screenshot containing credentials. When updating the subscription, use the client’s update button and confirm the update succeeded and the original configuration is still enabled. Then test the target website again. If the client supports automatic updates, enable them after the connection is stable. Automatic updates don’t renew a subscription or fix nodes that have stopped working on the service side.
Change only one setting at a time and keep a working configuration you can restore. For DNS optimization, rule sets, TUN, or local overrides, see the advanced configuration guide. If an import fails, a node times out, or a connected client can’t load a webpage, use the Help Center to troubleshoot the specific symptom. A successful first setup means you can explain which configuration is active, where traffic enters the client, and which outbound route a target request takes—not that every switch is turned on.