Preparation
Before you begin: check the client, subscription URL, and system time
Before configuring anything, make sure the client starts normally. After launch, a desktop client should show the core status, configuration entry, or proxy entry. On mobile, the first launch may display a system connection permission prompt; you can postpone it until the subscription and policy are selected to avoid switching between screens. If the client reports an unavailable core file, insufficient permissions, or a port conflict, resolve the startup issue before importing the configuration.
Prepare a subscription URL provided by your service. It is usually a complete link beginning with https://. Copy the entire URL directly—do not copy only the webpage title, and do not retain spaces or line breaks before or after the link. Some providers offer multiple format options; choose one explicitly marked as supporting Clash, Mihomo, or Clash Meta. A regular share link is different from a subscription URL. If pasting it creates only one node with no policy groups, it is often not a complete subscription.
Next, check that the device date, time, and time zone are correct. Secure connections to the subscription server, some protocol handshakes, and configuration update times depend on the system clock. A significant time offset can cause update failures, connections that close immediately, or certificate-time warnings in the logs. Enable automatic time synchronization, then restart the client so the core reads the updated time.
The client opens normally, the configuration page is accessible, the full subscription URL has been copied, and the device time zone and clock are correct. With these conditions met, it is easier to determine whether a problem comes from the URL, configuration, or connection stage.
Step 1
Import the subscription and activate the configuration
Open the client’s “Configuration” or “Subscriptions” page and find an option such as Add, Import, or Add configuration. Desktop clients usually provide a URL field near the top of the page. On mobile, you may need to tap the plus icon in the upper-right corner and choose “Import from URL” or “Subscription.” Paste in the complete URL you copied earlier. Use a short, recognizable name if needed, such as one based on the device or purpose. If the client reads the name automatically, you can keep the generated name.
Click Save, Import, or Download and wait for the client to fetch the subscription for the first time. When successful, a new entry appears in the configuration list with an update time, update button, or configuration status. Opening the entry usually also reveals its policy groups. Do not connect just because one record appears in the list; select it so it becomes the active configuration. Desktop clients may use a highlighted border, checkmark, or “Enabled” status, while mobile clients may require opening the details and choosing “Use.”
Run one manual update after importing. This confirms that the subscription URL is still reachable and avoids relying on stale cached content. A successful update does not mean every node works; it only means the configuration file was downloaded and parsed correctly. Next, open the “Proxy” or “Policies” page and check whether multiple policy groups and selectable entries are present. If the page is empty, shows only DIRECT, or reports a parsing error, return to the configuration page and review the error instead of enabling the system proxy.
You can usually identify an import failure by when the error appears. If “Invalid URL” appears immediately after updating, copy the subscription link again and check for spaces at either end. If the request times out after waiting, confirm that the device’s current network can reach the subscription URL. If the download succeeds but format parsing fails, the subscription format may be incompatible with the current core. For more help with format detection, empty content, and update failures, see the installation and configuration section in FAQ; configuration syntax is outside this guide.
The configuration list contains the new subscription, a manual update completes successfully, the configuration is active, and the Proxy page shows policy groups with selectable entries. Once confirmed, continue to mode and node selection.
Step 2
Choose Rule mode and the main policy group
On the “Proxy” page, find the mode selector first. Common modes include Rule, Global, and Direct. For first-time setup, Rule mode is recommended: the client uses the rules in the current configuration to decide whether each connection should use a proxy policy or connect directly, so you do not need to switch manually for every website. Global mode sends most connections through one selected proxy policy and is useful for briefly testing whether a node can connect. Direct mode bypasses proxy handling and is mainly useful for comparison tests.
After choosing a mode, review the main policy group. Its name comes from the subscription configuration and may be “Node Selection,” “Proxy,” “Auto Select,” or something else. Open the group that controls the primary exit and choose a specific node, or select an automatic latency-test or failover policy. For the first connection, a clearly identified node is easier to troubleshoot because automatic switching will not affect the result. After verification, switch to automatic selection if needed.
The page may also contain policy groups for streaming media, messaging, software updates, or direct services. These groups may reference the main policy or use separate exits. There is no need to edit them individually during initial setup; keep the subscription defaults. Changing several groups too early makes the connection path difficult to trace. If the browser works but an app does not, it becomes harder to determine which group matched the app. Let the default rules run first, then adjust groups one at a time as needed.
Some clients provide a latency test button. Its result describes the client’s request to the test target, not whether every website or app will work, so it cannot serve as the only final verification. If every item times out, do not repeatedly run the test. Try another specific node, complete the connection steps, and then use real access results and logs to investigate. The url-test, fallback, and load-balance policy groups work differently. For long-term selection, read the protocol and core technical reference.
Rule mode
Routes connections according to the configuration rules. It is the recommended daily default and the mode used in the rest of this guide.
Global mode
Uses the selected policy for most connections. It is useful for briefly comparing node status, but should not be fixed long term without understanding the app’s requirements.
Direct mode
Bypasses proxy policies and can be used for before-and-after tests to confirm whether traffic is reaching the client.
The client is now in Rule mode, and the main policy group has a specific node or a clearly defined automatic policy selected. Other specialized policy groups remain at their configuration defaults. You can now start the core and take over system traffic.
Step 3
Start the core and establish the system proxy connection
Return to the client home page or “Settings” page and confirm that the core is running. Desktop clients such as Clash Verge Rev typically show core status at the bottom of the window, in a sidebar status area, or in the tray menu. After switching configurations, the core may briefly reload; wait for its status to return before enabling the system proxy. Log entries such as configuration loaded and proxy port listening usually indicate that the core has read the active configuration.
On Windows, macOS, and most Linux desktop environments, the next step is to enable the “System Proxy.” This points the system HTTP and HTTPS proxy settings to the local port listened to by the client, allowing browsers and apps that follow system proxy settings to send connections through it. Do not quit the client immediately after enabling the switch. The system proxy only forwards connections to the local process; once the client closes, the local port stops listening and apps may temporarily fail to connect. To exit, disable the system proxy first, then close the client.
On Android and iOS, the process usually means tapping the connection button on the main page. The system displays a network connection permission prompt; after confirmation, a connection indicator appears in the status bar and the client button changes to Connected. These platforms may not offer a separate switch named “System Proxy,” but the sequence is the same: the client loads the configuration and policies, then receives app traffic through system authorization. If another similar network connection service is enabled, disconnect it first because mobile operating systems typically allow only one such connection at a time.
Linux users should also check whether their desktop environment and apps read the system proxy settings. Common graphical desktops can be configured automatically by the client, but some terminal programs, container processes, and standalone network tools do not follow the desktop proxy and require a proxy address in their own configuration. For the first test, use a regular browser so the app’s own proxy mechanism is not confused with client connection issues. Port settings, environment variables, and transparent proxying are advanced topics covered in FAQ and the Protocol Reference.
If the client reports an error immediately after you enable the system proxy, first inspect the last few lines of the log. A port conflict usually means another program is listening on the same port; close the conflicting program or change the port in the client settings. Permission warnings may involve permission to write system proxy settings, service mode, or network-extension authorization. A configuration-loading error requires returning to Step 1 and selecting a valid configuration. Do not change the subscription, mode, port, and node at the same time. Change one item, test again, and keep the troubleshooting path clear.
The core is running, the desktop system proxy is enabled, or the mobile device has completed system connection authorization. The client is not continuously reporting configuration or port errors. Do not change other settings yet; proceed directly to verification.
Step 4
Verify the result with a browser, connection records, and logs
Once the connection is established, fully close and reopen a browser window, then visit a website you normally use. Reopening the browser reduces the influence of old connections, cached pages, and existing sessions. A page loading is only the first check. Return to the client’s “Connections” page as well: if refreshing the page creates a new domain, destination address, and policy entry, the browser request has reached the client and been processed by its rules.
Next, inspect the policy path for the new connection. In Rule mode, different domains may show DIRECT, the main proxy group, or another policy from the configuration; this is normal rule-based routing. Do not expect every connection to show the same node. Confirm that the target website’s main request matched the expected policy and did not repeatedly fail. If the connection list contains no new browser records at all, check whether the system proxy is enabled, whether the browser has independent proxy settings, and whether the app bypasses the system proxy.
The third layer of verification is the log. During normal browsing, new entries should continue to appear at times matching your actions, rather than repeating the same error. If DNS resolution fails, check the current network, DNS settings, and resolution fields in the configuration. If the connection times out, switch to another node in the main policy group and retry. If the connection is refused or the local port is unavailable, return to the connection step and check the core and port. When logs contain many fields, focus first on the time, destination, policy, and error reason; there is no need to interpret every core detail during initial setup.
Finish with one comparison test. Keep the browser page open, disable the system proxy or disconnect the mobile connection, then refresh the page and watch the client’s connection list. No new proxy connection from that browser should appear. Enable the connection again and refresh; the records should return. This before-and-after test is more reliable than checking the address shown on a webpage alone because it directly confirms whether app traffic enters the local client. After verification, restore Rule mode and keep the policy selection you need.
If webpages work but a store app, terminal program, or game produces no connection records, the issue is usually whether that app follows the system proxy, not the subscription import. Windows Store apps may involve loopback restrictions, terminal programs may need separate environment variables, and browser extensions may override system settings. For app-specific troubleshooting, visit the Troubleshooting section instead of deleting a subscription configuration that has already been verified.
Page response
The page loads normally after reopening the browser, ruling out a misleading result caused by an old cached page.
Connection records
The client shows a new connection matching the access time and displays the policy that was actually used.
Log status
The same error is not repeated continuously, and the result can be checked again after switching nodes.
Comparison after disabling
No proxy records appear after disconnecting; the records return when the connection is enabled again.
Finish setup
Configure automatic updates and startup behavior after the connection is stable
After completing all four verification steps, return to the subscription details and set an automatic update interval. Follow the service provider’s recommendation. Refreshing too frequently will not improve connection quality and may trigger request limits. Keep the manual update option available and use it when policy groups change or the node list is out of sync. If the current node disappears after an update, return to the main policy group and choose an available option.
Desktop clients can also be configured to launch at startup, start silently, and set the system proxy automatically. It is best to use the client for a while first and observe its behavior when quitting, waking from sleep, or switching networks. Pay particular attention to the difference between “launch the client at startup” and “automatically enable the system proxy at startup”: the former only starts the program, while the latter changes the system connection path. On public or office networks, or on devices that switch environments frequently, leaving activation manual usually makes the current state easier to understand.
After a mobile device switches from Wi-Fi to cellular data, check whether the client remains connected and review the connection records again. Battery-saving policies may restrict background activity, causing the connection to need reestablishment after the screen has been locked for a while. These issues involve the protocol, battery use, and system background policies and are beyond this basic guide. To compare protocol behavior, resource usage, and mobile performance, see the protocol and core technical reference.
Choose the Clash Verge client for your device
If the client is not installed or you need a version for another platform, visit the download page and confirm your operating system and processor architecture. Once the installer is ready, return to this guide and start from Step 1.