Clash Setup Guide
Import a subscription → choose a proxy mode → connect → verify routing. If you already have a client and a valid subscription, set aside about 10 minutes to complete these steps before fine-tuning anything.
Before You Begin: Get a Client and Subscription Ready
The Clash client reads your configuration, matches rules, and forwards connections. It does not provide a working proxy endpoint by itself. Before you start, you need a subscription URL you’re authorized to use and that hasn’t expired, or a local YAML configuration containing node details. If you only have an account page, order URL, or web login, find the subscription option in your provider’s dashboard that’s explicitly labeled for Clash or a compatible core. Don’t use an ordinary webpage URL as a subscription.
Before your first setup, quit any other proxy or VPN tools that are managing network traffic to prevent them from repeatedly changing system settings. Keep the client’s default ports and DNS settings, and leave LAN sharing and custom rules off for now. This keeps troubleshooting focused on three things: the subscription, the proxy node, and the connection switch.
Subscription URLs may contain account identifiers or access credentials, so treat them like passwords. Hide the full URL, node passwords, and other identifying details before sharing screenshots or logs. The steps below take place in your local client; there’s no need to submit your subscription to an unfamiliar online converter.
Step 1: Import and Enable a Subscription
Paste the URL and wait for the configuration to download
Open “Profiles,” “Subscriptions,” or a similarly named page from the client’s sidebar or bottom navigation. Find “Add,” “Import,” or a plus button. Choose an option such as remote subscription or import from URL, then paste the full link. If there’s a name field, enter a label that’s easy to recognize; it only affects how the item appears in your list, not its nodes. Check for spaces or line breaks at either end of the URL, then select Save, Download, or Import.
Wait for the client to finish loading. A successful import usually adds a profile card showing its name, last update, or other details from the subscription. Some clients download the configuration when you save it; others require you to select “Update.” Don’t keep adding the same subscription to retry, or you may end up with duplicate entries. If the download fails, first make sure your device can reach the subscription URL, then check with your provider that the link hasn’t expired.
“Update via proxy” requires an existing working proxy connection. During your first import, you haven’t connected yet, so enabling this option may not help. Try downloading over your current network first. If your provider requires a specific network, follow its instructions. Being able to open the URL in a browser doesn’t guarantee that it returns a valid configuration: if you see a login page, error page, or expired-subscription notice, get a valid URL instead of repeatedly restarting the client.
Select the Profile and Check That Its Policy Groups Appear
After the download finishes, select the new profile card or choose “Use” or “Activate” to make it the current configuration. Some clients show a checkmark; others display “In use.” Then open the “Proxies” or “Policies” page and check that the policy groups and their nodes are visible. A successful import doesn’t mean the profile is active. If you still see groups from the old configuration, return to the profile list and confirm which one is selected.
If you have a local .yaml or .yml file, choose “Import from file,” open it in the system file picker, and activate it as above. Local files usually don’t receive remote subscription updates automatically. A single-node URL or Base64 node list is not necessarily a complete YAML configuration; use a dedicated import option only if your client explicitly supports that format.
Before moving on, make sure the profile is selected and its proxy groups are visible on the Proxies page. If the logs show a YAML parsing error, restore the original file or download the configuration again; don’t remove indentation at random. See the configuration fields documentation for field meanings and format differences. You don’t need to write a full configuration by hand to connect for the first time.
Step 2: Choose a Mode and Proxy Node
Start with Rule Mode
Find the mode selector on the home page, in Settings, or at the top of the Proxies page. Look for “Rule,” “Global,” or “Direct”; some clients show these English labels. Choose Rule mode for your first setup. It uses the rules in the current configuration to decide how each request is routed: some connect directly, while others go through a specified policy group. It doesn’t proxy every request, and the configured rules may not match everyone’s needs.
Global mode typically sends requests that reach the core through the global policy group. It can be useful for a quick comparison, but it won’t automatically route traffic from apps that never reached the core in the first place. Direct mode connects requests that reach the core straight to their destination. Don’t assume the selected mode just because the client is running: tap the mode you want and confirm that its selection indicator changes.
Choose a Node in a Policy Group Used by Your Rules
Return to the “Proxies” or “Policies” page and expand the main outbound group. Its name may be “Proxy,” “Select,” or something else, depending on the subscription. Select a node and make sure the checkmark appears beside it. If the group points to another policy group, expand that too until you’ve identified the final outbound node. Changing a node in a group that your rules don’t use may not affect the sites you visit.
If the client offers a group speed test, run it once to rule out candidates that clearly can’t connect. Results depend on the test URL, network, and implementation. A lower number doesn’t mean every site will be faster, and a timeout needs to be checked against real-world browsing. For your first setup, just choose an outbound node that completes the test; there’s no need to compare every node repeatedly.
Policy groups such as Auto Select and Failover may switch nodes according to their own criteria. Running a test on the group doesn’t necessarily pin a specific node. For a reliable comparison, choose a node in a manual selection group if your subscription provides one. The mode and policy are now ready, but app traffic may not be reaching the client yet. The next step connects your desktop or phone traffic.
Step 3: Connect and Route Your Traffic
Enable the System Proxy on Desktop
On the desktop client’s home page, make sure the core is running. If there’s a separate Start button, click it first, then turn on “System Proxy.” Some clients start the core automatically when you enable the system proxy; check the status and logs to confirm. Leave the client running in the background and reload a browser page. Most browsers and apps that follow the system proxy settings will now send new requests to the local proxy port.
If your browser has a proxy-switching extension, set it to follow system settings or temporarily disable its proxy rules. Some developer tools, terminal apps, and games have their own network settings and won’t use the system proxy automatically. For your first test, use a regular browser so an app-specific behavior isn’t mistaken for a client-wide problem.
Don’t copy a port number from someone else’s screenshot. The client’s listening port must match the port used by the system proxy. 7890 is a common example, not a value that applies to every device. If you see a port-in-use warning, check for another proxy core running, quit any duplicate instance, and try again. If you still need to change the port, see the port configuration documentation.
Approve the System Connection Request on Mobile
Android and iOS clients usually route traffic through the system VPN interface. Return to the client’s home page and tap “Connect,” “Start,” or the corresponding switch. The first time, the system will ask you to approve a VPN connection or add a VPN configuration. Confirm that the request came from the client you just installed, then approve it. Return to the app and wait for its status to show Connected. The VPN icon in the status bar varies by OS version, so don’t rely on that icon alone.
If your phone is connected to another VPN, disconnect it and try again. Multiple VPN connections on one device may replace one another. On Android, if app-based routing is enabled, make sure the browser you’re testing isn’t excluded. If iOS still won’t connect after you approve the request, check the client’s error message and confirm the configuration is active instead of repeatedly adding system configurations.
Step 4: Verify Requests and Routing
Check the Connection Log to Confirm the Outbound Route
Keep the client connected and open “Connections,” “Active Connections,” or a similar page. In your browser, visit a site you expect to access through the proxy, preferably in a new tab to trigger a fresh page load. Return to the client, find the site’s domain, and expand the entry to check the matched rule, policy group, and actual outbound node. Some clients call these details “Rules,” “Chain,” or “Chains.” If an entry appears and disappears quickly, open the Connections page before making the request or check the logs for that time.
Confirm the request reached the core before checking how it was routed. A single page may request several domains in Rule mode, and the main page, images, and APIs may match different rules. Don’t judge by the first row, or assume the proxy is off just because you see DIRECT. Find the entry for the request you’re testing, confirm it went through the expected policy group, and check which node was actually selected.
Next, visit a site that should connect directly according to your current configuration and check that it matches a direct-connection rule. Testing both a site expected to use the proxy and one expected to connect directly is more reliable than testing just one page. A changed exit IP only shows that the specific lookup used that route; it doesn’t prove that every app and protocol is being routed.
Run a Comparison, Then Troubleshoot Layer by Layer
If you’re using the desktop system proxy, briefly turn it off and make a new request to see whether the client still logs it. On mobile, briefly disconnect the client instead. Restore the connection and repeat the test, then compare the results. Don’t reuse an existing download or long-lived connection; it may continue using its original route. A cached page may not generate a new request at all.
If no new connections appear, first check the connection switch, browser proxy extensions, and app routing settings; the request may not have reached the core. If you can see the request but it used the wrong route, check the current mode, matched rule, and policy group selection. If the route is correct but the connection times out, try another node and check the logs for DNS resolution failures, connection refusals, or remote timeouts. Working through these checks in order helps separate routing issues from connection issues.
If connecting makes sites that worked before stop loading, first turn off the system proxy or disconnect the phone. Confirm that your regular internet connection works, then check the configuration and node selection one at a time. Don’t start by deleting every profile. Keep only the log lines around the failure. For a more detailed guide, see how to read Clash runtime logs.
Everyday Use: Update and Disconnect
Once everything checks out, everyday use usually means keeping the current profile and Rule mode, then switching nodes as needed. When your subscription changes, update it from the Profiles page and check whether your policy group selection is still in place. Some clients preserve the selection; others may revert to a default if a node has been renamed. Set the auto-update interval to suit your needs. Refreshing a subscription doesn’t verify the connection or reactivate an expired account.
Before quitting the desktop client, turn off the system proxy, then exit normally. When you reopen the client, check that the switch is in the expected state. If the app quits unexpectedly and your browser can’t connect, check whether the OS proxy settings still point to a local port that’s no longer listening. Clear any stale settings before starting the client again. On mobile, disconnect from within the client when you’re done, and check whether the OS is set to always-on VPN or to block connections without a VPN.
You’ve completed the first-time setup: the profile is active, the mode is set, traffic is routed, and the connection log confirms the results. To adjust DNS, custom rules, or subscription overrides, work through the Clash configuration fields documentation. Change one setting at a time, reload the configuration, and repeat Step 4 to keep a clear path back if needed.