Clash Verge Rev Interface Guide: Proxy, Profiles, Connections & Logs

Start with the main window: separate interface controls from core behavior

Clash Verge Rev is a desktop management interface. The Mihomo core handles proxy connections, DNS, and rules. If the window opens, the graphical interface is running—but network access also depends on whether a configuration is loaded, traffic is routed into the core, and the request uses the intended outbound path.

Proxy, Profiles, Connections, Logs, and Settings each serve a different purpose in the sidebar. Their order, icons, and button placement may vary between versions. This guide explains what each page does rather than treating any icon's position as a fixed standard.

Page	Main purpose	What to check afterward
Proxy	Choose a mode, proxy group, and node	The proxy path used by new connections
Profiles	Import, update, and activate configurations	Active profile indicator and load logs
Connections	Inspect requests, rules, and traffic	Destination domain, rule, and outbound path
Logs	Check core activity and error details	When the error occurred and what caused it
Settings	Configure the system proxy, TUN, and ports	Whether app traffic reaches the core

Proxy page: Modes, proxy groups, and latency tests

What Rule, Global, and Direct modes do

The mode on the Proxy page determines how the core selects an outbound route. For everyday use, start with Rule mode, then check the match on the Connections page. A mode describes how traffic is handled once it reaches the core; it does not route every app into the core automatically.

Rule mode: Matches traffic against the configured rules in order and applies the policy from the first matching rule. Direct and proxied traffic can coexist.
Global mode: Sends traffic that reaches the core through the global policy. Useful for quick comparisons when troubleshooting. You still need to select an available outbound in the relevant policy group.
Direct mode: Connects traffic that reaches the core directly to its destination. It does not turn off the system proxy or TUN.

A proxy group is not a node—and selecting a group does not guarantee a request will use it

A proxy group can contain nodes or reference other groups. Manual selection groups commonly use the select type; automatic latency-test groups often use url-test, while failover groups commonly use fallback. Whether an automatic group allows manual selection and when it changes routes depends on the group type and configuration.

Selecting a node in a manual group only changes that group's selection. A request matched to DIRECT or another proxy group will not be affected, even if a different node is highlighted in the current group. To troubleshoot, follow the chain: “matching rule → policy group → actual node.”

Using latency tests, filters, and expand controls

Latency test: Probes a test address and shows the result in milliseconds or as a timeout. It does not measure download bandwidth, and a low result does not guarantee access to a streaming service.
Search or filter: Helps find node names. It does not change rules or the current selection.
Expand or collapse: Changes how much of the list is displayed. It does not disable any nodes in the group.

For example, if node A shows 85 ms and node B shows 160 ms in the same test, that only means A responded faster under those test-address and network conditions. These figures are illustrative, not results measured by this site. Batch tests generate extra connections, so there is no need to run them repeatedly when you have many nodes.

Profiles page: Import, activate, update, and use local overrides

After importing a profile, make sure it is active

Open the Profiles page, paste the Clash-compatible subscription URL from your provider into the address field, and import it. The field expects a configuration URL the client can read, not your account dashboard URL. Subscription links often contain access credentials, so never show them in full in screenshots, public logs, or support posts.

After importing, check that a profile card appears and review its name and last-updated time.
Select the profile you want to use and make sure the interface marks it as active. Whether a newly imported profile activates automatically depends on its actual status in the interface.
Go to the Proxy page and check that the expected proxy groups and nodes are available.
If parsing fails, note the specific error on the Logs page. Repeatedly trying to activate the profile will not resolve the error and may make it harder to diagnose.

What update, edit, and delete actions change

Updating fetches the remote configuration again; activating applies the selected configuration to the core. These are separate actions. Some profiles reload automatically after an update, but check the active indicator and logs to confirm the new configuration took effect.

A profile card's menu may offer options such as update, edit profile details, edit file, open file location, and delete. Editing the name or update interval usually changes management details; editing the file may directly modify the local YAML. Deleting removes the local profile record. It does not cancel your provider account or subscription plan.

For example, before keeping local rules, confirm where they will be inserted and how they will be merged. Rule order matters: appending a custom rule after the catch-all MATCH rule usually will not work as intended. Do not assume Merge automatically appends every array item. For configuration details, see Advanced Usage.

Connections page: Trace traffic with rules and proxy chains

The Connections page lists connections observed by the core. Common fields include the destination host and IP, source address, network type, rule, proxy chain, upload and download totals, and duration. Process details depend on system permissions and process detection; a missing process name does not necessarily indicate a connection problem.

Trace a web request using four fields

Host or destination: Search for the domain you just visited. The domain may come from request data, DNS mapping, or sniffing; some entries show only an IP address.
Rule: Check whether the expected domain or IP rule matched, or whether the request fell through to MATCH.
Proxy chain: Check the policy group and final node used—not just the highlighted selection on the Proxy page.
Traffic and duration: Check whether data is still being transferred. An open connection with no increase in downloaded bytes does not prove the destination is responding normally.

Upload and download figures are usually totals for the connection; the interface may also show a live rate. Check the units: KB/s is a rate, while MB is a data total. A web page may connect to its main domain, image hosts, and API domains at the same time. Seeing one request use a proxy does not mean every resource on the page follows the same route.

Close one connection or close all connections

Closing a connection ends the current session; it does not permanently block the destination domain. The app may reconnect immediately. Existing long-lived TCP connections usually do not switch nodes automatically. Close only the relevant connections, reload the page, and check whether new connections use the new node.

Use “Close all connections” when you specifically need to rebuild sessions, but be aware that it can interrupt file transfers, meetings, and remote terminals. For routine troubleshooting, search first and close only the relevant entries to limit disruption.

Logs page: Levels, error details, and reproduction steps

The Logs page shows core events. The interface may also provide application logs or a shortcut to the log directory. A failure to start the graphical interface and a failure to connect to the network are different issues; do not assume every problem is caused by a node.

Start with info; switch to debug briefly if needed

Common log levels include info, warning, error, and debug. Start with info for connection and runtime details. If that is not enough, enable debug briefly. Debug logs contain more detail and are more likely to include private information such as domains and addresses.

Log message	Common meaning	Check first
`timeout`	A stage timed out	Use the surrounding entries to tell whether it was DNS, dialing, or a handshake
`connection refused`	The destination port refused the connection	Destination address, port, and service status
`address already in use`	A listen address or port is already in use	Duplicate client instances and port settings
`yaml` or parsing error	Invalid configuration syntax or field structure	Error line, indentation, and override result

What pause, clear, and copy do

Pausing scrolling or display usually affects only how logs appear; it does not pause the proxy service. The Clear button typically clears the current view, not necessarily the log files on disk. Before copying or exporting logs, redact subscription URLs, tokens, account details, and any network addresses you should not share.

Note the current time, clear the display, or jump to the latest log entries.
Reproduce the issue once—for example, reload one page that fails.
Keep relevant logs from about 10–20 seconds before and after the failure, not just the final line.
Also note the current mode, selected proxy group, and whether TUN is enabled so you can compare them with the logs.

Settings page: System proxy, TUN, and ports

System proxy and TUN are two different ways to route traffic into the core

Go to Settings → System Proxy and check the toggle, or use the shortcut in your version. The system proxy directs apps that honor the operating system's proxy settings to a local proxy port. Apps that ignore this setting may need to be configured individually or routed through a suitable TUN setup.

Go to Settings → TUN Mode and check the toggle and related options. TUN routes traffic through a virtual network interface and routing table, and usually requires service mode or the appropriate system permissions. If it fails to start, check the service, permissions, and logs instead of repeatedly clicking the toggle. Running multiple VPN or TUN tools at once can cause routing and DNS conflicts.

Do not confuse a local port with a proxy node's server port

Port settings are usually under Ports or Port Configuration in Settings; the exact label varies by version. mixed-port is a local combined HTTP/SOCKS entry point, not a remote node port. The example below explains the field only; it is not a complete configuration to import:

mixed-port: 7897
allow-lan: false
mode: rule
log-level: info

If your local mixed port is set to 7897, manually configured apps can use 127.0.0.1 as the address and 7897 as the port. Do not assume every installation uses this example port—check the actual settings. If the port is already in use, resolve the conflict and update any apps configured manually to use it.

“Allow LAN” lets other devices connect to your local proxy entry point. It is unrelated to whether your own browser can use the proxy. Before enabling it, consider the listen address, firewall, and authentication. Do not expose proxy ports or the controller interface directly to an untrusted network.

Run a basic check from the interface

After setting things up or making a change, verify each step in a consistent order. This makes issues easier to isolate than changing several toggles at once. The process below changes only what is needed along one traffic path and is useful when the client is running but pages will not load.

Profiles page: Confirm the profile imported successfully and is active, and check that the logs show no configuration load errors.
Proxy page: Use Rule mode, select a node in the manual proxy group used by the request, and run one latency test.
Settings page: First confirm how the app's traffic enters the core. Test the system proxy with a browser; configure TUN only if you need it to capture traffic.
Connections page: Open a destination page, find the new connections, and check the matching rule and final node.
Logs page: If it fails, check the error at the same time as the request, then change one related setting and test again.

A simple way to read the window: Profiles tells you “what is loaded,” Proxy tells you “how traffic is routed,” Connections shows “which path it actually took,” and Logs tell you “where it failed.” For full first-time setup and subscription instructions, see Quick Start.