Clash Verge Rev Interface Guide: Proxies, Profiles, Connections, Rules & Logs

First, understand the difference between the interface, configuration, and mihomo core

Clash Verge Rev is a desktop client for importing subscriptions, managing settings, and displaying connection status. mihomo is the core that handles proxy connections, DNS, and rule matching. Seeing nodes in the interface does not mean app traffic is reaching the core. Enabling the system proxy does not mean every connection will use a remote node. Keep these distinctions in mind as you explore the sidebar.

This guide uses the common Chinese-language interface in Clash Verge Rev 2.x as a reference. Button placement and some labels may vary by minor version, window size, and operating system; follow what you see in your installed version. The sections below follow this sequence: Proxies → Profiles → Connections → Rules → Logs → Settings. The sidebar may use a different order.

Proxies: choose a policy group, select a node, and check latency

Nodes and policy groups are different levels

Open Proxies and you’ll usually see several policy groups, not one list of nodes shared by every request. A policy group is an outbound selector that rules can reference. It can contain nodes, other policy groups, or both. Names such as “Node Selection,” “Auto Select,” and “Streaming” come from the subscription configuration; they are not fixed client sections.

1. Find the policy group you want to use and expand its options.
2. If the group type is select, click a node or nested policy group and confirm that the selection changes.
3. Run a latency test for the group and wait for the results; avoid triggering repeated tests back to back.
4. Make a new web request, then check its policy chain under Connections instead of relying only on the node card.

url-test automatically selects an outbound based on probe results; fallback checks candidates in order for an available outbound; and load-balance distributes connections according to its configured strategy. Their behavior depends on the configuration, so don’t assume every group is a manually selected node that stays fixed.

Rule, Global, and Direct modes

• Rule mode: Routes traffic according to the active rule set. Start here for everyday use when you need to distinguish direct connections from proxied ones.
• Global mode: Connections entering the core are generally routed through the GLOBAL policy. When troubleshooting, also check which outbound that policy actually selects.
• Direct mode: Connections entering the core go direct. This mode is usually useful for comparison tests.

In some versions, the mode selector is at the top of the Proxies page; in others, it’s in the global quick-access area. Wherever it appears, the mode selector does not send app traffic into the core. If an app bypasses the system proxy and isn’t captured by TUN, switching to Global mode does not mean its traffic is being proxied.

Profiles: import a subscription, update it, and activate a profile

Profiles manages the configuration sources used by the core. Remote subscriptions typically provide nodes, policy groups, rules, and related settings; local profiles come from files on your device. A successful import means the client received configuration content it could save. You still need to confirm that the profile is active and that the core loaded it successfully.

First import: the steps

1. Go to Profiles, paste the complete URL provided by your service into the subscription field, and import it. The URL may contain access credentials, so don’t post it in public forums.
2. Wait for the profile card to appear, then check its name and update time. If the import fails, read the error message first. Don’t enter a subscription URL manually as if it were a node address.
3. Select the card as the active profile and confirm the interface shows it as enabled. The selection indicator varies by version.
4. Return to Proxies and check that the policy groups and nodes have appeared. If you still see old content, go back to Profiles and make sure a different card isn’t active.

Updating a subscription doesn’t switch profiles

Updating fetches the configuration again from the same source; activating a profile makes that configuration part of the current session. If two subscription cards are present, updating one doesn’t necessarily make it active. Node counts, plan usage, and expiration dates depend on whether the subscription service provides that information; the client cannot generate it on its own.

Before changing rules, identify what you’re editing: the remote source file, a local profile, or a merge or script feature provided by the client. Changes to a local copy of a remote profile may be overwritten on the next update. If you use a merge feature, check that the final runtime configuration contains the intended changes. YAML indentation, field types, and policy group names must be valid; a successful save in the editor doesn’t prove the core accepted the configuration.

Connections: verify the actual route for a request

Connections shows records for connections that have entered the core, making it the most direct place to verify routing. Common fields include the destination host and address, network type, upload and download volumes, matched rule, and policy chain. Whether a process name appears depends on system permissions, traffic capture method, and core settings; its absence alone does not indicate a problem.

Verify with a new request

1. Leave Connections open and load a new target page in your browser, minimizing background requests from other apps if possible.
2. Filter records by domain. If only an IP address appears, use the request time and destination address to identify it.
3. Open the connection details and note the matched rule, policy group, and final node. A policy chain may include nested groups, so don’t rely on the first group name alone.
4. If it shows DIRECT, check the Rules page to find out why. If it uses the expected node, verify the result using the page response or an exit IP lookup.

After switching nodes, existing long-lived TCP connections or HTTP/2 sessions may continue using the old outbound. Start a new request for testing; if needed, close the relevant connections and try again. Closing a connection from this page interrupts that session, which may disconnect downloads, meetings, or remote terminals. Check what will be affected first.

If no destination appears in Connections, first check whether traffic is reaching the core rather than assuming the node is unavailable. Your browser may have its own proxy settings, or an app may ignore the system proxy. Conversely, a cached page may load without generating the new request you expected.

Rules: inspect match conditions, order, and the resulting policy

Rules shows the rules loaded by the active configuration. Common types include exact-domain DOMAIN, domain-suffix DOMAIN-SUFFIX, IP range IP-CIDR, rule-set references RULE-SET, and the catch-all MATCH at the end. Ordinary rules are generally checked in order, so an earlier match can determine the result.

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH, Node Selection

This example sends requests for example.com and its subdomains direct, then routes everything else to “Node Selection.” It illustrates rule order and is not a complete configuration. The policy group referenced on the second line must exist, and its name must match exactly.

Compare the Rules and Connections pages

• Rules shows the definition: the conditions, their order, and the policy they reference.
• Connections shows the result: what matched for a specific request and which node it ultimately used.
• Profiles changes the source: for lasting changes, find the active profile or the merge-rule entry point.

If the interface shows only a destination IP and no usable domain information, domain rules may not match as expected. Check DNS handling, whether the app resolves domains itself, and whether domain sniffing is enabled. Seeing a rule on the Rules page doesn’t mean every request has the information needed to match it.

Logs: pinpoint the stage of an error by time

Logs shows runtime events and error context; it isn’t another latency leaderboard. Common levels include info, warning, error, and debug. Keep a reasonable level for everyday use. Temporarily increase detail while troubleshooting, then restore it after reproducing the issue. Excessive logging makes records harder to read and may expose browsing details.

Reproduce the issue clearly, then review the surrounding errors

1. Note the current time, active profile, selected node, and whether you’re using the system proxy or TUN.
2. Open Logs and reproduce the failed action once, such as refreshing the target page.
3. Find the entries from that time and read the surrounding lines. Don’t look only at the final timeout.
4. Classify the error as a configuration load, local listener, DNS, remote connection, or protocol handshake issue, then change only the relevant part.

The same type of error can have several causes. For example, a timeout when dialing a remote host could mean the node is unreachable, or that your local network is blocking the connection. Compare one variable at a time by trying another node or local network; this is more useful than changing DNS, ports, and modes all at once. If you share logs, keep the error type and timestamps, but remove subscription URLs, credentials, and unnecessary domain names.

Settings: system proxy, TUN, and ports each serve a different role

The settings most easily confused are the system proxy and TUN. The system proxy writes a proxy address to the operating system settings and works with apps that follow those settings. TUN creates a virtual network interface and captures traffic through routing and DNS configuration; its coverage depends on the actual setup. The difference isn’t “standard” versus “high-speed” nodes, and neither option improves the remote server’s network quality.

How to check the system proxy

In Settings, find the System Proxy toggle. The listening port is usually listed on the same page under ports or Clash settings. Some versions put these options under Settings → Clash Settings. Menu labels may change between versions, so follow the fields shown in your current version rather than looking for another client’s menu names.

For example, if your local mixed port is set to 7897, apps configured to use a proxy should use 127.0.0.1:7897. If the current port is different, use that value instead. Neither 7890 nor 7897 is a universal default for every installation. A mixed port accepts HTTP and SOCKS proxy connections, but the app must still use a protocol it supports.

TUN and service permissions

Enabling TUN may require the client to install or start a service and request administrator privileges. Complete the service steps shown in the interface, then check the toggle and logs. A switched-on button alone doesn’t confirm that traffic capture succeeded if virtual network adapter, routing, or DNS setup failed. Corporate VPNs, other proxy apps, and security software can also affect routing, so note your original network settings before troubleshooting.

A complete workflow: from import to verified connection

1. Profiles: Import the subscription, activate the profile, and confirm it loads without errors.
2. Proxies: Select Rule mode, choose a node in a manual policy group, and test its latency.
3. Settings: Enable the system proxy and check the local listening port. Leave other network settings unchanged for now.
4. Connections: Visit a target page and check the new connection’s matched rule and final outbound.
5. Rules: If the outbound isn’t what you expected, find the relevant rule and any earlier matches.
6. Logs: If the connection fails, locate the error by time and troubleshoot that stage alone.

Keep the relationships between pages in mind: Profiles determines which nodes and rules are available; Proxies controls policy selection; Settings determines how traffic enters the core; Connections shows what happened; Rules explains routing conditions; and Logs provide context for failures. Follow this chain to investigate issues such as “nodes are available but there’s no internet,” “the exit didn’t change after switching nodes,” or “a website is still going direct.”

For first-time installation and platform selection, see the Getting Started guide. For help with DNS, ports, and system proxy issues, see the FAQ. If terms such as policy groups, core, and rule sets are unfamiliar, check the glossary before changing your configuration.