Clash Verge Rev How to Use: Add Subscriptions and Switch Nodes

What You Need Before Using Clash Verge Rev

Clash Verge Rev is designed to make a subscription-based proxy workflow visible: profiles hold your provider configuration, proxy groups expose the available nodes, and the dashboard gives you a place to test or change the active route. You do not need to understand every YAML field before starting, but you do need to understand which parts come from your subscription provider and which parts are controlled locally by the client. A subscription URL supplies profiles, node names, group definitions, rules, and sometimes DNS or TUN settings. Clash Verge Rev displays and runs that configuration; it does not create a working service by itself.

Start with a valid subscription URL supplied by a provider you trust. It normally begins with https:// and may contain a long token after the domain. Treat that URL like a password. Anyone who obtains it may be able to download your profile or consume your account quota. Do not paste it into public issue trackers, screenshots, team chats, or browser-sync notes. If you accidentally expose it, revoke or regenerate the link from the provider panel before continuing.

Before importing anything, close other desktop proxy clients, VPN applications, and browser extensions that may control the same traffic. Two clients can both appear connected while competing over the system proxy, DNS requests, or local ports. This creates misleading symptoms: Clash Verge Rev may show a healthy node, while the browser still follows a different PAC file; or a second application may occupy the mixed port and prevent the core from starting correctly. A clean baseline makes every later test easier to interpret.

You should also decide what “working” means for your setup. A node that answers a latency probe may still be unsuitable for video, large downloads, gaming, or long-lived WebSocket sessions. Conversely, a node with a higher measured delay can feel more stable if it has less packet loss. The first goal is not to chase the smallest number in a test column. The goal is to build a repeatable workflow: import the profile, refresh it, identify the correct proxy group, test a few candidates, choose a node, and confirm that the intended application is actually using it.

How to Add a Subscription Profile

Open Clash Verge Rev and go to the Profiles or profile-management view. The exact label can differ slightly between releases, but the workflow is consistent: find the field for a profile URL, paste the subscription address, and submit it for download. If the interface offers a name field, use a descriptive name such as Primary Provider, Work Network, or Travel Backup rather than leaving several profiles with identical timestamps. Clear names matter later when you are comparing providers or troubleshooting a failed refresh.

1. Copy the complete URL. Do not copy only the visible domain or truncate the token after a question mark. If the provider presents a “copy subscription” button, use that instead of manually selecting a wrapped line.
2. Paste it into the profile importer. Check that the address begins with https:// whenever your provider supports encrypted delivery. Avoid replacing a subscription URL with a local file path unless you intentionally maintain a local YAML profile.
3. Download and inspect the result. A successful import should produce a profile entry, node groups, or both. If the entry appears but contains no usable proxies, the provider may have returned an error page, an expired account notice, or a format that the current core cannot parse.
4. Activate the intended profile. Importing a profile does not always mean it is the active configuration. Look for a check mark, active indicator, or “use” action, then wait for Clash Verge Rev to load the profile before opening the proxy dashboard.

A profile download error should be investigated in layers. First, open the subscription URL in a normal browser only if you understand that the URL is sensitive; confirm whether it returns structured configuration text rather than a login page or “expired” message. Second, check the computer clock. Incorrect system time can break HTTPS certificate validation even when ordinary sites appear reachable. Third, test the same URL without another proxy client running. Finally, ask the provider whether your account has reached a device, traffic, or request limit. Repeatedly clicking refresh rarely fixes an invalid token and may trigger provider-side rate limiting.

After the profile loads, examine the visible groups before changing anything. Common group names include Proxy, 节点选择, Auto, Fallback, or provider-specific labels. The top-level group is usually what rules send traffic to, while its child entries are individual nodes or nested groups. Selecting a node in an unrelated group may have no effect on the application you are testing. This is one of the most common beginner mistakes: the interface shows a selected item, but the active rule path points somewhere else.

Refresh the Profile and Test Available Nodes

Subscriptions change over time. Providers may remove expired nodes, add new endpoints, rotate certificates, update routing rules, or change a group from a static selector to an automatic test group. Use the profile’s refresh or update action when the provider tells you that the configuration has changed, when many nodes stop responding, or when your current profile is noticeably older than the provider’s published update interval. Do not refresh repeatedly while diagnosing a single failed website; first determine whether the problem is the profile, the selected node, the application, or the destination itself.

The proxy dashboard normally presents a group tree and a node list. A latency test may display milliseconds, an icon, or a status color. Read that result as a narrow measurement, not a complete quality score. The test may measure a lightweight HTTP request to a fixed URL, while your real application uses another domain, another protocol, and a much longer connection. A green result proves that the test endpoint answered through that node. It does not guarantee that every destination will behave identically.

For a practical manual test, select one node from the primary proxy group and wait for the dashboard to apply it. Open a simple HTTPS page that you are authorized to access, then repeat the same page after choosing a second node. Keep the test conditions consistent: use the same browser, disable unrelated VPN extensions, and avoid judging a node while a large download is already consuming the connection. If the first page works but a particular application fails, check that application’s own proxy settings and certificate policies before blaming the node.

Automatic groups require a different interpretation. A url-test group may periodically compare members and choose the fastest response, while a fallback group usually follows an ordered list when the current member fails. A manual selector preserves your explicit choice until you change it. If you want predictable behavior while learning, use the selector first. Once you understand which group controls your traffic, automatic testing can reduce maintenance, but it may also change the active node without an obvious notification.

Switch Nodes and Choose the Right Proxy Mode

To switch nodes, open the group that your rules actually use, select another child node, and wait for the selection state to update. Some versions apply the choice immediately; others require clicking an apply, save, or reload control. After switching, watch the connection log for a new outbound connection rather than assuming that existing sessions moved instantly. Long-lived browser tabs, downloads, and WebSocket connections may remain attached to the previous path until they reconnect.

If switching appears to do nothing, inspect the group hierarchy. You may have changed a child selector while the top-level rule still points to a different nested group. Another possibility is that the profile uses a rule such as DOMAIN-SUFFIX or GEOIP to send the destination to a separate policy group. In that situation, the node you selected can be healthy while the requested domain follows another group entirely. The dashboard’s rule or connection view is more useful than repeatedly clicking nodes without checking the selected policy.

Clash Verge Rev also exposes a proxy-mode choice, commonly represented by Rule, Global, and Direct. In Rule mode, the configuration decides whether a connection uses a proxy group or goes directly. This is the best starting point for most users because it respects the profile’s intended routing policy. In Global mode, traffic is generally directed through the global proxy selection, which can be useful for controlled testing but may send local services, banking pages, printers, or intranet resources through an unsuitable route. Direct mode bypasses the proxy and is useful as a diagnostic comparison, not as proof that a provider node is working.

Use this short procedure when a site behaves unexpectedly:

1. Select Rule mode and reproduce the problem once.
2. Open the connection or log view and identify the destination domain and policy group.
3. Test the relevant group with a different node instead of changing unrelated groups.
4. Compare with Direct only when it is lawful and safe to do so.
5. Return to the intended mode after testing, then close and reopen the application connection if it remains cached.

Do not confuse proxy mode with TUN mode. Rule and Global determine how the Clash core classifies traffic that reaches it. TUN creates a virtual network interface so applications that do not understand HTTP or SOCKS proxy variables can be captured at the network layer. TUN can be powerful, but it introduces system permissions, DNS interactions, route conflicts, and possible interference with corporate VPN software. Learn the normal system-proxy workflow first. Enable TUN only when you have a specific application that cannot use the ordinary proxy path and you are prepared to troubleshoot virtual-interface behavior.

Enable System Proxy and Configure Startup Behavior

The system proxy switch connects Clash Verge Rev to the operating system’s proxy settings. When enabled, supported desktop applications can discover the local HTTP or mixed proxy automatically. This is convenient for browsers and many standard networking libraries, but it is not universal. Some applications ignore system proxy settings, use their own proxy configuration, rely on a separate VPN API, or send traffic through a service process that does not inherit the desktop settings.

Turn on the system proxy only after the core is running and a valid profile is active. Then open a permitted website and verify that a connection appears in Clash Verge Rev’s dashboard. If nothing appears, check whether the browser has a manual proxy, PAC script, or extension that overrides the operating-system setting. If ordinary browsing works but a game, terminal tool, or media application does not, that may be expected rather than a failed system-proxy switch. Configure that application separately or evaluate whether TUN is appropriate for your legitimate use case.

When troubleshooting, check the local listener values shown by the client, such as the HTTP, SOCKS, or mixed port. A port number is not a remote server address; it is a local entry point on your computer. Avoid changing ports without a reason, because scripts, browser extensions, and application settings may still reference the old value. If another program already occupies the chosen port, Clash Verge Rev may fail to bind, or traffic may reach an entirely different service. Logs usually reveal this with messages containing terms such as address already in use or failed to bind.

Startup settings control whether Clash Verge Rev launches when you sign in and whether it starts with the system proxy enabled. Automatic launch can be useful on a personal machine, but automatic system-wide routing is not always desirable on shared, managed, or travel devices. A safe beginner arrangement is to launch the client at startup while leaving system proxy disabled until you deliberately need it. If you enable both, confirm after a reboot that the correct profile is active, the core has started, and the local proxy is not left enabled when you close the client.

Remember: “The app is open,” “the core is running,” “a profile is active,” “a node is selected,” and “the operating system is using the proxy” are five different states. Check them separately instead of treating one green icon as proof of the entire chain.

A reliable daily routine is therefore simple: start Clash Verge Rev, confirm the intended profile, refresh only when necessary, select the correct policy group, test the chosen node, enable the system proxy when required, and inspect one or two connections. When you shut down, decide whether the operating-system proxy should be disabled first. Leaving a system proxy enabled after the client exits can make every browser request appear offline until the operating system settings are restored.

Compared with lightweight browser proxy extensions, Clash Verge Rev gives you clearer profile management, rule-aware groups, node testing, logs, and a consistent local proxy for multiple applications; compared with older all-in-one VPN clients, it exposes more of the routing decisions instead of hiding them behind one connect button. The trade-off is that you must understand profiles, groups, modes, and system settings. For this workflow, Clash V.CORE provides a maintained foundation for importing subscriptions, switching nodes, checking connections, and applying proxy rules with less guesswork than fragmented per-browser tools, so if you want a cleaner starting point, visit the download page and set up Clash V.CORE for your next profile test.