Clash Subscription Setup and Connection Test

Step 1: Import a Subscription and Select the Configuration

Before you begin, get a subscription link from your provider or a usable local YAML configuration file. The client reads the configuration and routes traffic; installing it doesn’t mean you already have a working node. Treat subscription links like passwords because they often contain personal access credentials. Don’t post the full link publicly or import configurations from unknown sources just to test them.

Paste the Link and Wait for the Import Result

Open the client and go to Subscriptions or Config. Find the link field or add option, paste the full subscription link, then click Import or Save. Don’t include quotation marks, explanatory text, or line breaks from a chat message. If your provider offers multiple formats, choose one explicitly marked for Clash or mihomo rather than a subscription intended for another app.

After submitting, wait for the result instead of clicking repeatedly. A configuration card should appear in the list, possibly with its name, last updated time, or an update button. Some clients select the new configuration automatically; others require you to click the card or choose Enable from its menu. Confirm that the configuration is selected, then open Proxies. The import is complete only when you can see its policy groups and available nodes.

If the card appears but the Proxy page is still empty, return to the subscription list and check that the configuration is selected and updated successfully. For 401 or 403 errors, check your subscription access and make sure the link hasn’t expired. For a timeout, check whether your current network can reach the subscription URL. Don’t repeatedly delete the entire client configuration. For more guidance, see troubleshooting subscription update failures.

Importing a Local File and Checking for Success

If you have a file, use the client’s file import option and select a configuration ending in .yaml or .yml. Don’t paste a local file path into the subscription URL field. Select the configuration after importing it. A local file may not have a remote update source, so clicking Update doesn’t necessarily refresh its node information.

For now, don’t edit YAML fields or add DNS snippets found online. Check just three things: the import completed without a parsing error, the configuration is selected, and the Proxy page shows the policy groups defined in it. Then move on to choosing a mode. Seeing node names means the configuration was read; it doesn’t prove the remote nodes can connect.

Step 2: Choose a Rules Mode and an Outbound Node

Once the configuration has loaded, find Proxy Mode. In Clash Verge Rev, it’s usually under the Clash settings section in Settings; other clients may put it on the Proxy page or home screen. For your first setup, choose Rules. This mode uses the configuration’s rules to decide whether requests connect directly or go through a policy group, preserving the subscription’s default routing behavior.

Choose a Mode, Then Select a Policy Group

Rules, Global, and Direct serve different purposes. Rules mode routes each request according to the matching rule. Global mode typically sends requests handled by the core to the global policy group. Direct mode connects those requests straight to their destination. Global mode does not route all traffic from the entire device, nor does it automatically capture apps that ignore the system proxy. Don’t confuse Global mode with TUN mode during your first test.

After selecting Rules, open the Proxy page. Policy group names come from your current configuration and vary by subscription, so don’t look for a specific name from a tutorial screenshot. Expand the group responsible for proxy traffic and select a node your provider lists as available. If that group points to another policy group, follow the chain until you can identify the actual outbound route. An automatic group may test and switch nodes on its own; a manual group requires you to select one.

If the client offers a latency test, run it once as a rough guide. A response doesn’t guarantee that every website will be reachable, and a timeout may be caused by the test endpoint. Choose a node and test it in your browser instead of switching repeatedly to chase a particular number. If every node fails, save the log from one attempt, then use the troubleshooting guide to check the connection and your local network.

Keep the Default Rules and Change One Setting at a Time

For your first connection, leave the existing rules, DNS, and sniffing settings unchanged. The goal is to verify one complete connection path, not optimize everything at startup. Don’t switch modes, import an override file, and change DNS addresses all at once. If the connection starts working, you won’t know which change made the difference.

If your subscription has policy groups for specific apps or websites, check whether each group currently selects a node, another group, or DIRECT. A website may still connect directly simply because its group is set to Direct; that doesn’t mean the system proxy is broken. Read the advanced troubleshooting guide for rule order, persistent overrides, and custom policies after your basic connection works. For now, keep Rules mode and one clearly selected outbound option, then enable the connection.

Step 3: Enable the System Proxy or Connect on Mobile

Selecting a node isn’t enough; the client still needs to receive requests from your apps. On desktop, start by testing a browser through the system proxy. On mobile, traffic goes through a system-authorized VPN connection. Disconnect any other active proxy or VPN first to prevent multiple apps from competing to change your network settings. If your work device is managed by an organization, follow its network policies instead of overriding them.

Desktop: Make Sure the Core Is Running, Then Enable the System Proxy

Make sure the desktop client isn’t reporting a core startup error, then open Settings and enable System Proxy. Clash Verge Rev commonly uses port 7897 for its mixed port, but check the value shown in your client; the example isn’t a fixed requirement. You usually don’t need to enter the proxy again manually in your system settings. The client configures the relevant system proxy for you.

Leave the client running after you enable the proxy. If you’ve installed a browser proxy extension, check whether it overrides the system proxy; you can temporarily switch the extension to use the system settings. Terminals, games, and some standalone apps may not follow the system proxy, so a lack of change in those apps doesn’t mean the configuration failed. Test in a browser first, then troubleshoot individual apps once the basic connection works.

TUN mode isn’t required for this step. It provides another way to route traffic and may require administrator permissions, service mode, or additional system network authorization. Leave it off during your first test so you don’t change the system proxy and virtual network adapter at the same time. If you need to route apps that ignore the system proxy, configure TUN separately using the manual’s TUN and permissions guide.

Mobile: Tap Connect and Approve the System Prompt

Android and iOS clients usually have a Connect button on the home screen. Once you’ve selected a configuration and node, tap Connect. When the system first asks to connect to a VPN or add a VPN configuration, check which app made the request and approve it through the system prompt. Some devices may also ask you to unlock the screen. After authorizing, return to the client, check its connection status, and make sure the system doesn’t immediately report that the connection has dropped.

Mobile operating systems generally allow only one standard VPN connection at a time. If you’re using another VPN, firewall, or VPN-based filtering app, disconnect it before connecting the current client again. If the Android client has per-app settings, make sure your test browser isn’t excluded. On iOS, keep the client’s default routing settings for now; don’t add complex on-demand connection rules during your first test.

Step 4: Verify That Requests Go Through the Client

Once the client shows a connection, open a new browser tab and visit a site you know requires a proxy and are authorized to access. Don’t rely only on a page that was already open: its content may be cached, or an existing long-lived connection may still use the route from before the proxy was enabled. Close old tabs and retry, or restart the browser if needed.

Check the Page and Connection Logs Together

While the page is loading, open the client’s Connections page and look for the new request by domain. If the client shows matched rules and policy chains, confirm that the request matched the expected rule and used the policy group or node you selected. In Rules mode, it’s normal for some requests to show DIRECT. What matters is whether that matches the configuration’s routing rules, not whether every request uses the proxy.

If the webpage loads but you can’t find a matching entry in the client, don’t assume the proxy is working. The site may be directly accessible, or the browser’s own proxy settings, an extension, or another network tool may be handling the request. Disable unrelated proxy settings, make a new request, and check the client logs again. On mobile, also check that the browser isn’t excluded by per-app settings.

Now open a familiar site that should connect directly and make sure Rules mode hasn’t disrupted normal browsing. An IP lookup site can provide a useful comparison, but it only shows the route your browser used to reach that site; it can’t prove that every app uses the same route. For a more reliable check, compare the page result with the matched rule and outbound entry.

Return to the Step That Matches the Problem

If there are no new connection entries, go back to Step 3 and check the system proxy, mobile VPN authorization, and app routing. If an entry shows an unexpected Direct policy, return to Step 2 and check the policy group selection and matched rule. If the request used the expected node but timed out, look for errors near that destination in Logs. Errors such as i/o timeout and connection refused indicate different problems; changing DNS won’t fix both.

If the subscription itself won’t update, go back to Step 1; there’s no need to reset your system network settings first. If you need to share logs, include only the lines around the failure and redact subscription links, credentials, and personal network details. For error categories and step-by-step checks, see the Clash troubleshooting guide. This page doesn’t cover advanced network diagnostics.

Finish Setup and Check That Your Network Recovers

Your first setup is complete when sites that require a proxy load, the connection logs show the expected outbound route, and direct sites still work normally. Keep a note of the configuration name, proxy mode, and selected policy group; there’s no need to copy the full subscription link. Update remote subscriptions from their configuration card when needed. Providers may change nodes and rules, so check the policy group selection again if things behave differently after an update.

Finally, test what happens when you disconnect. On desktop, turn off System Proxy—and TUN too, if you enabled it—before quitting the client. On mobile, tap Disconnect before leaving the app. Then open a regular webpage and make sure your network has recovered. This prevents the system from pointing to a local port that the client is no longer listening on.

Next time, restore your connection by checking the current configuration, confirming the node selection, and enabling the connection. Set up startup launch, auto-connect, or background operation only after a manual connection works, then check the actual state after restarting your device. If you lose internet access, have DNS issues, or the client crashes, go straight to the symptom-based troubleshooting guide instead of repeating the entire setup.