Clash Verge Setup Guide

Before You Begin: Prepare the Client and a Valid Subscription

This guide assumes the client opens normally. After launching it for the first time, check that it is not stuck on errors such as core startup failed, configuration load failed, or port in use. If the client is not installed yet, install it before continuing. There is no need to enable TUN, change DNS, or add custom rules upfront; leaving the defaults in place makes later troubleshooting easier.

The client reads the configuration and handles traffic; it is not a proxy service by itself. You need a subscription URL from your service that explicitly supports Clash or Mihomo, or a YAML configuration that works with the current core. An account login page, payment page, and subscription URL are different things. Pasting a regular webpage URL into the client will usually result in a format error.

Before you start, close other proxy or VPN apps that are handling network traffic, and note any manual proxy settings already in place. A subscription URL may contain account identifiers, so treat it like a password. Do not include it in public screenshots, group chats, or online conversion tools. When troubleshooting, record only the error type. Before sharing a configuration, remove subscription URLs, credentials, and other private fields.

Step 1: Import a Subscription and Enable the Configuration

In Clash Verge Rev, open Subscriptions from the left sidebar and find the field for pasting a subscription URL or the option to add a remote subscription. Copy the full URL from your service and make sure it has no extra spaces, line breaks, or punctuation added by a chat app. Paste it into the field. If the interface asks for a name, use something easy to recognize; it is just a display label and does not change the subscription.

Click Import and wait for the client to download and parse the configuration. When it finishes, the Subscriptions page should show a configuration card or entry—not an error message. Select the configuration and set it as the active one. Some versions indicate activation through the selected card, while others have a separate enable action. A successful download alone does not switch the active configuration, so the core may still be using the previous one.

Next, open the Proxies page and check that the proxy groups defined in the subscription are there. Group names come from the configuration, so they may not match this guide. Identify them by their purpose and available options rather than looking for a specific name. Seeing the groups and their options means the import and configuration load have mostly succeeded. You still need to choose an outbound and enable a way for traffic to enter the client; this alone does not mean the connection is working.

If you have a local YAML file, use the local-file import option on the Subscriptions page and set the imported file as the active configuration. Local imports are useful when you already have a configuration, but the file does not become a remote subscription: if your service updates its nodes, you will need a new configuration or a remote URL that supports updates. Renaming a file with the .yaml extension does not convert its contents.

If the import fails, read the error before trying again. For a timeout, check whether your current network can reach the subscription service. If the response is a webpage or the format is unsupported, ask your service which subscription type to use. For an authentication error, check whether the URL has expired or your account status has changed. If the subscription URL itself requires a proxy to access, use an already working network path to retrieve it; a connection that has not been configured yet cannot solve this prerequisite.

After the first import, familiarize yourself with the Update option on the configuration card; there is no need to set up frequent automatic updates yet. A remote update fetches the content published by your service and may overwrite local edits made directly to the subscription file. For persistent custom rules, use the client’s supported override or merge options. See the configuration reference for details; for now, use the subscription’s original configuration to connect.

Step 2: Choose Rule Mode and a Proxy Group

Once the configuration is active, open the Proxies page and find the controls for Rule, Global, and Direct modes. For a first setup, choose Rule: the core uses the configuration’s rules to decide whether a request goes direct, through a proxy group, or to another outbound. This mode suits everyday use, but the actual routing depends on the current configuration. The client does not generate rules for every need just because Rule mode is selected.

Next, expand the proxy group responsible for general proxy traffic. A manual group usually lets you select a node as the outbound; an automatic group maintains its selection according to the checks defined in the configuration. Keep the subscription’s default structure and choose an available option only if you need to set one manually. If groups are nested, check the next level too: selecting a proxy group does not guarantee that the final outbound is not still Direct.

You can use the connection test beside a proxy group to check whether a candidate can reach the test URL specified in the configuration. A failed test does not necessarily mean the node cannot handle all traffic, and a successful test does not guarantee that every website will load. It reflects only that test target and the network conditions at that moment. There is no need to test every node repeatedly; choose a candidate, then verify it with a real browser request.

Global mode sends regular requests that enter the core through the global proxy group. It can help troubleshoot routing, but check which option that group actually selects. Direct mode connects traffic that enters the core straight to its destination, so it is not proof that a proxy connection works. Switching modes does not automatically route every app through the core; the traffic entry point is controlled by System Proxy or TUN in the next step.

If you are unsure what the proxy group names or options mean, stay in Rule mode and note the current selection. Avoid changing rules, DNS, and group types at the same time. If you need to switch to Global temporarily for a test, return to Rule mode afterward and repeat the test. For rule priorities, nested proxy groups, and custom routing, see rule syntax in the configuration reference. For common questions about choosing a mode, see Troubleshooting.

Step 3: Enable System Proxy and Send a Test Request

Once the active configuration and proxy group are set, open Settings and enable System Proxy. This usually points the operating system’s proxy address to the client’s local listening port, sending requests from apps that follow system proxy settings to the core. On desktop, this is often the main switch you need for a first connection; there is no need to enable every network feature just to follow this guide.

Before enabling it, make sure the core is running normally. If the logs show that a listening port is already in use, close the other program using that port or change the port in the client settings, then enable System Proxy again. The interface may show a mixed proxy port such as 7897, but use the value in your current settings. Do not enter a number from this guide manually in the system network settings while the client is listening on a different port.

After enabling the switch, open a browser that follows system proxy settings, start a new tab, and visit a site you want to test. An existing page may reuse an old connection, so a new request is easier to evaluate. If the browser has an extension that controls proxy settings, check that it is not overriding the system configuration. Some apps use their own networking stack or proxy options and will not automatically use the system proxy.

Consider TUN mode if an app does not follow the system proxy or you need to route traffic from more apps. TUN uses a virtual network interface and routing to capture traffic, and it usually requires a service component or elevated permissions. Follow the client’s prompts to grant permission before enabling it. If the system shows a network permission or virtual adapter prompt, make sure it was triggered by the client you just installed. Repeatedly toggling the switch before granting permission usually will not fix the issue.

For the first test, use System Proxy alone. Once browser access is stable, test TUN separately so you change only one variable at a time. TUN coverage also depends on routing, exclusions, DNS, and other VPNs; enabling it does not guarantee that every app will use the proxy. If you cannot connect, do not enable TUN, LAN access, and several DNS options all at once. Extra settings make it harder to identify the cause.

On mobile, the connection steps differ from desktop: select a configuration and proxy group, start the connection from the app’s home screen, then accept the operating system’s VPN permission prompt and return to the app to check the status. If permission is denied, check the system permissions and VPN settings rather than importing the subscription again. For in-depth help with System Proxy issues, TUN permission failures, or apps that cannot connect, see Troubleshooting. This guide continues with requests you have already sent.

Step 4: Check Rule Matches and Test the Results

First, test basic connectivity by visiting one site that should use the proxy under your current rules, then another that should connect directly. Check that each page loads. Know how each target is expected to route under the current configuration; if both load, that alone does not show whether traffic was routed as intended. Do not stop checking just because the client icon changed color or the switch appears enabled.

Return to the client’s Connections page and look for the matching domain or destination while you revisit the page. If the interface lets you expand connection details, check which rule matched, which proxy group was used, and the final outbound. The connection list may show only active connections, so short requests can disappear quickly. Open the Connections page before refreshing the target site; cached content may also mean a refresh sends no new network request.

If the connection log shows Direct, first check whether that is what the rule expects. Some sites are meant to connect directly in Rule mode, which does not mean System Proxy has failed. If a site that should use the proxy is routed Direct, check the rules and proxy group selection. If the browser keeps making requests but no related connections appear, check whether another program has overridden System Proxy, whether the browser has separate proxy settings, and whether the request is actually going through the client.

An egress IP lookup can provide supporting evidence, but it is not conclusive on its own. The lookup site is also routed by your rules, and the displayed address shows only the egress used for that request. Other sites, IPv6 requests, or apps not captured by the client may use a different path. For a more reliable check, compare the page result, matching connection log, and actual outbound. A screenshot of an IP lookup cannot prove that all traffic on the device is being routed through the proxy.

If the test fails, check in this order: confirm the active subscription and proxy group, check System Proxy and core status, then review the logs around the time of the request. Note the time, target domain, and a short error message to help distinguish a timeout, DNS failure, authentication issue, or rule selection problem. Change one setting at a time and send a new request. If the browser shows a certificate warning, stop entering sensitive information and investigate the cause; do not bypass the warning just to complete the test.

After verification, keep Rule mode for everyday use and leave the proxy group on a choice you have tested. Startup and silent-launch options control how the client starts; they do not guarantee that System Proxy will be in the desired state after every login. If you enable them, restart the device and check. When you exit the client, check whether System Proxy has been turned off. If the browser cannot connect after the client exits unexpectedly, check the system network settings for a leftover proxy pointing to localhost.

Next Steps: Update the Configuration and Preserve Your Changes

If your service changes its nodes or rules, return to the Subscriptions page and manually update the active remote configuration. After the update, check your proxy group selection again; a change in node names may invalidate the previous choice. If an update fails but the existing configuration still works, keep the working setup and check the subscription service before taking further action. There is no need to delete the entire configuration and start over.

For persistent domain-based routing, DNS changes, or local rules, read the configuration reference to distinguish service-provided settings, client-generated entries, and local overrides. For intermittent disconnects or an app that cannot connect, follow the symptoms in Troubleshooting. Keeping the basic setup you have already verified as a reference makes it easier to identify the cause than trying several advanced options at once.