Clash Verge Rev Interface Guide: Proxies, Profiles, Logs & More

Understand Profiles, Proxy Selection, and Traffic Routing

When you first open Clash Verge Rev, start with three questions: where does your profile come from, which node handles requests, and how does app traffic reach the client? These correspond to the Profiles page, the Proxies page, and either System Proxy or TUN mode in Settings. Selecting a node on the Proxies page alone doesn’t mean your browser is using the proxy. Importing a subscription successfully doesn’t mean that profile is active.

Clash Verge Rev is a desktop client. It provides profile management, system integration, and interface controls, while the mihomo core handles connection forwarding and rule matching. When troubleshooting, distinguish between an interface action that didn’t take effect and a connection failure after the core received a request. You’ll need to check different places for each.

The sections below explain each of these areas. Sidebar order, button placement, and settings groupings may vary between releases, so look for the relevant feature name in your version. Check the port values shown in your settings; example values aren’t universal defaults.

Proxies: Choose an Operating Mode and Proxy Group

Open Proxies and check the current operating mode, then review the proxy groups. In Rule mode, the core selects a policy according to the rules in your profile. In Global mode, traffic typically uses the GLOBAL policy. Direct mode sends regular requests without proxy nodes. Global mode is useful for a quick comparison test, but it’s not a substitute for troubleshooting your rules.

A Proxy Group Isn’t a Subscription—and It May Not Be a Single Node

A profile can define multiple proxy groups, such as “Proxy Selection,” “Auto Select,” or “Streaming.” The profile author chooses these names; they aren’t fixed client features. A group can contain nodes, other proxy groups, or built-in policies such as DIRECT.

• A select group is typically for manual selection. Choose an item in the interface to use it for new connections through that group.
• A url-test group evaluates nodes automatically using the test URL, interval, and tolerance defined in the profile. It doesn’t necessarily pick whichever node shows the lowest latency every time.
• A fallback group primarily selects an available route according to availability and profile order; it shouldn’t be treated as a lowest-latency group.

What Does the Latency Reading Tell You?

Testing the latency of a node or proxy group checks its connection to a specified test URL. For example, a result of 180 ms is not a download speed and doesn’t guarantee that every website will be reachable. Results vary with the test URL, route, and destination. If a test times out, check the logs to determine whether the node is unreachable, DNS resolution failed, or the test destination itself is unavailable.

Profiles: Import a Subscription, Update It, and Activate the Profile

The Profiles page manages the sources the client loads. Remote subscriptions typically fetch YAML content from a URL; local profiles come from files. The client needs a compatible profile, not just any node-sharing text. If an import fails, first confirm that the provider offers a format supported by Clash or mihomo.

Four Checks for Your First Import

1. Open Profiles, paste the full URL into the subscription field, and import it. Don’t use the URL of a web page describing the subscription.
2. Wait for the profile card to appear, then check for download or parsing errors. A card appearing only means the profile was added to the list.
3. Activate or select the profile on its card, then confirm that the active profile has changed.
4. Go back to Proxies and check that the expected groups and nodes appear. Then select a node and test the connection.

“Update subscription” fetches the remote content again; “Switch profile” tells the core to use a different profile. These are separate actions. If the node list doesn’t change after an update, first check whether you updated the active profile card, then look in the logs for fetch or load errors.

Before Editing a Profile, Check Whether Your Changes Will Persist

Edits made directly to a downloaded remote subscription may be overwritten the next time it updates. For lasting rule or field changes, use an override or extension configuration mechanism supported by your version, and verify the final effective configuration. Avoid maintaining the same fields in multiple places, or interface toggles, the original subscription, and the final profile may not agree.

Subscription URLs often contain access credentials. Remove tokens from URL query parameters, node passwords, and private server details before sharing screenshots, reporting issues, or sharing profiles. Field names and error line numbers are usually enough to help diagnose a problem; most interface issues don’t require publishing the full subscription.

Connections: Check Whether Requests Reach the Core and Where They Go

Use the Connections page to answer the question, “Is this site actually going through the proxy?” With the page open, make a new request in your browser and check the destination domain or IP, upload and download data, and any rule or proxy-chain details shown. Some process fields depend on OS permissions and the traffic-capture method, so an empty field doesn’t necessarily mean the request is abnormal.

Troubleshoot Based on Whether the Request Appears

• Can’t find the request: Check whether the browser or app uses the system proxy, or whether TUN is capturing its traffic. Also check the page filters in case the connection is hidden.
• The request appears, but goes DIRECT: Check the matched rule and current operating mode. If a direct-connection rule matches, changing nodes on the Proxies page usually won’t change where that request goes.
• The request appears and uses the expected node: Check the logs for the destination, DNS, and timeouts. Reimporting the same subscription repeatedly won’t help.

For example, if a request’s proxy chain ends in DIRECT when you expected it to go through “Proxy Selection,” check which policy the rule selected and whether that policy points to a direct connection. The Connections page shows the actual result; the Proxies page shows the current selection in each group. Check both.

Closing a connection only ends an existing session; it doesn’t change routing rules. The connection list may not retain a complete history, and short requests can disappear quickly. To investigate, reproduce the issue while watching the logs rather than relying on a static screenshot of the connection list.

Rules: Check Rule Order and Matching Conditions

The Rules page shows which routing rules the core has loaded. In Rule mode, rules are typically checked in order, and the first match determines the policy. Focus on the conditions, order, and policy name—not just whether the destination domain appears somewhere in the list.

These are syntax examples, not instructions to replace your existing profile. Proxy Selection must be a proxy group that already exists in your profile. Before applying changes, account for existing rules and rule sets:

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

• DOMAIN matches an exact domain. The example.com in this example won’t automatically include all subdomains.
• DOMAIN-SUFFIX matches a specified domain and its subdomains, such as example.org and www.example.org.
• Use MATCH as a catch-all rule, after any rules that need to be evaluated first.

If your profile uses RULE-SET, also check whether the corresponding rule-providers loaded successfully. Seeing a reference in the rule list doesn’t mean the remote rule set downloaded successfully; check the Logs page for download errors. When editing rules, distinguish between temporary changes and persistent overrides that survive subscription updates.

Logs: Narrow Down Problems by Time and Keyword

The Logs page records core events and is the main place to investigate import failures, connection timeouts, and DNS issues. Note when the problem occurs, repeat the action, then look for related destinations and errors around that time. Background updates and requests from other apps also generate logs, so don’t assume every warning is related to the issue at hand.

First, Identify Which Layer Is Failing

Log levels typically include info, warning, error, and debug. Page filters only affect what’s displayed; the core’s log level controls how many records are generated. If the core is only recording errors, changing the page filter won’t restore information that was never logged.

For a deeper investigation, temporarily enable debug in the log-level settings available in your version. Reproduce the issue once, then restore your usual level. When sharing logs, include the time, error text, and relevant context, but redact subscription credentials and private addresses. A screenshot showing only “connection failed” usually isn’t enough to identify the failing layer.

Settings: What System Proxy, TUN, and Ports Control

Network toggles in Settings determine how traffic reaches the core. First confirm that the core is running, then choose System Proxy or TUN. They aren’t equivalent to “basic” and “advanced” nodes, and neither will fix an invalid subscription.

System Proxy and TUN Mode

• System Proxy: Sets the proxy address in your operating system’s proxy settings. It works with browsers and apps that follow those settings. Apps that ignore the system proxy may still connect directly.
• TUN mode: Uses a virtual network interface and routing to capture traffic. It’s useful when you need to handle traffic from more apps. Enabling it may require service mode or administrator privileges, depending on your system and installation method.
• Using both: Whether to enable both depends on your apps and profile. If something goes wrong, test one traffic-capture method at a time so you don’t change multiple variables at once.

If your browser works but a desktop app doesn’t, first check whether that app supports the system proxy, then consider TUN. If you’re also using another VPN or virtual network adapter, check for conflicts involving routes, DNS, and network interfaces instead of repeatedly toggling the same switch.

Mixed Port and LAN Access

Find the port settings and check the current mixed port. If the page shows 7897, apps that require manual proxy settings will typically need host 127.0.0.1 and port 7897. Select HTTP or SOCKS as required by the app. Here, 127.0.0.1 refers to the current device, not a remote node.

After changing the mixed port, update it in any apps you configured manually. Other devices can’t connect to this computer using their own 127.0.0.1. Sharing access over your LAN also involves the listening address, LAN access settings, and firewall rules. If you only need the proxy on this computer, there’s no need to expose it to your LAN just to troubleshoot a browser.

A Step-by-Step Workflow for Getting Started and Troubleshooting

Once you know your way around the interface, use a consistent short workflow. Change one thing at a time and test against the same destination. It’s easier to find the cause than when switching nodes, modes, DNS, and TUN all at once.

1. Profiles: Import and activate a profile, then check for parsing or update errors.
2. Proxies: Stay in Rule mode, choose the proxy group route you need, and run a latency test.
3. Settings: Check the actual mixed port and enable the traffic-capture method that suits your app.
4. Connections: Make a new request, confirm it appears, and inspect its rule and proxy chain.
5. Rules: If the request takes an unexpected route, check the matching conditions, rule order, and catch-all rule.
6. Logs: If the route is correct but the request still fails, use the timestamp to find DNS, connection, or destination-service errors.

Continue with the client setup guide. For DNS, rule sets, and overrides, see Advanced Config. Get one profile and one traffic-capture method working reliably before adding more complexity; it makes troubleshooting much easier.