When Clash Verge is opened for the first time, the Profiles, Proxy, Connections, Logs, and Settings sections in the sidebar may seem separate. In practice, they follow a clear sequence: start by loading a usable profile, choose a node in the relevant proxy group, enable the system proxy or TUN mode, then use Connections and Logs to confirm that traffic is reaching the mihomo core. Looking at only one page often makes it difficult to tell whether a profile failed to load, a node is unavailable, or application traffic is bypassing the proxy.

Clash Verge Rev generally provides the graphical interface for managing profiles and core status, while mihomo handles rule matching, protocol connections, DNS processing, and traffic forwarding. Menu names, icon placement, and settings groups may vary slightly between versions, but the underlying flow of information remains much the same. Understanding how the pages relate to one another matters more than memorizing where a particular button appears.

Understand the traffic flow through the interface first

A complete connection passes through several stages. The Profiles page supplies runtime data such as nodes, proxy groups, rules, and DNS settings; the Proxies page determines which node each proxy group currently uses; the system proxy or TUN mode sends device traffic into the core; the rule system decides which proxy group should handle each domain, IP address, port, or process; and the Connections and Logs pages show the outcome.

  1. Import a profile: Create a profile from a subscription URL or local YAML file, then complete its first update.
  2. Activate a profile: Select the target profile in the list so it becomes the active runtime profile.
  3. Choose a node: Open the Proxies page, review the main proxy groups, and select an available node.
  4. Take over traffic: Enable the system proxy for ordinary use, or turn on TUN mode when broader traffic capture is needed.
  5. Verify the result: Visit the target site while watching the connection list, matched rules, and log entries.

Profiles: Import a subscription and confirm the active profile

The Profiles page is the starting point for the entire workflow. It stores subscription profiles, local profiles, and any available merge or script-processing options. A subscription URL is not a node; it is the entry point for retrieving profile data. Only after an update succeeds does the client receive nodes, proxy groups, rules, and other configuration details.

Which profile states should you check after importing a subscription?

Paste the complete URL into the subscription field and start the import. A profile card appearing does not guarantee that its contents are usable. Check the profile name, last update time, and whether the update completed successfully. If the profile provider requires a specific user agent, authorization parameters, or access from a particular network, follow its published instructions.

  • Make sure the pasted value is a complete HTTP or HTTPS URL with no extra spaces at either end.
  • After updating, open the Proxies page and check that the expected nodes and proxy groups were created.
  • When multiple profiles are present, check the active indicator so you do not edit one profile while running another.
  • After the subscription changes, run an update and check that node names, proxy groups, and other details have refreshed.

When is a local YAML profile useful?

A local profile is useful for debugging rules, maintaining nodes manually, or testing DNS settings. YAML is sensitive to indentation and data structure: list nesting, spaces after colons, and field ownership all affect parsing. A profile can be imported without every field being accepted by the current mihomo version. When parsing fails, start by checking the field name and line number in the logs.

proxies → proxy-groups → rules
          ↑
          Proxy groups reference nodes
rules ultimately send connections to a proxy group, DIRECT, or REJECT

Rules are normally evaluated in order, and the first matching rule determines the strategy. If a broad rule appears too early, more specific domain rules later in the list may never apply. The interface editor is suitable for checking small changes; for larger edits, keep the original file and validate the changes section by section.

Proxies: Understand proxy groups, nodes, and latency

The Proxies page displays the proxy groups and candidate options defined by the active profile. The top of the page often lets you switch between Rule, Global, and Direct modes, while the main area shows proxy groups as cards or lists. Clicking a node usually changes the current choice for one proxy group; it does not switch the entire profile to that node.

How common proxy groups differ in the interface

select groups let you manually choose a node or child proxy group; url-test automatically selects an eligible candidate based on test results; fallback prioritizes availability and moves to the next candidate when the current one fails; load-balance distributes connections across candidates according to its configured strategy. Actual behavior also depends on the test URL, interval, tolerance, and hashing strategy.

A proxy group can reference another proxy group, so the interface may show a hierarchy such as “the entry group selects the automatic group, which then selects a node.” When troubleshooting, start with the group ultimately matched by the rule and verify the current choice at each level. Do not rely only on whether a particular node card changes color.

How should latency values be interpreted?

A latency test usually accesses the test URL specified by the profile, so the result reflects the response time along that particular probe path. A lower value helps compare candidate nodes, but it does not directly indicate download speed, peak-hour stability, or connection quality for every destination. A timeout may result from the node, the test URL’s reachability, DNS resolution, or local network restrictions.

  • Rule mode: Rules decide whether connections use a proxy, go direct, or are rejected. This is suitable for everyday use.
  • Global mode: Most connections are handed to the global proxy group, making it useful for briefly testing basic node connectivity.
  • Direct mode: Connections prefer direct access, which can help compare behavior before and after proxy interception.

If access works after switching from Rule mode to Global mode, the node’s basic connectivity is probably fine. The issue is more likely related to rule matching, proxy-group selection, or DNS handling. If Global mode also fails, continue checking the node, network, core status, and traffic-capture method.

Connections: Confirm which rule handled a request

The Connections page records active connections passing through the core. Common fields include the destination host, destination IP, upload and download totals, connection time, network type, matched rule, and final route. It is the most direct way to determine whether an application has actually entered Clash.

After opening the target webpage, filter the connections by domain. If the domain appears with a proxy group and node route, its traffic has reached the core. If the connection exists but access fails, inspect its rule, destination, and route. If no entry appears at all, first check the browser’s proxy settings, the system proxy switch, TUN status, and whether the application bypasses the system proxy.

What do the arrows in a connection route mean?

Some interfaces display proxy selection as a route, such as “Media Policy → Auto Select → Node A.” This means the rule first assigned the connection to the Media Policy group, that group references Auto Select, and Node A ultimately created the outbound connection. The route shows where each selection occurred and explains why changing a different proxy group may not affect the current request.

When is it useful to close a connection?

Many applications reuse existing TCP, QUIC, or WebSocket connections. After switching nodes, an old connection may remain on its original route, making the test appear unchanged. In that case, close the relevant connection on the Connections page and reload the page. Closing a live communications or download connection will interrupt the current transfer, so check the task status first.

Logs: Distinguish profile, DNS, and connection errors

The Logs page shows events such as core startup, profile loading, DNS queries, rule matching, and outbound dialing. When the first connection fails, logs are more useful than simply watching a browser error page. Keep the log level readable for everyday use, reproduce the issue once, note the time, and inspect entries around that point.

How to interpret common log messages

  • Profile parsing error: Check YAML indentation, field spelling, data types, and whether the current core supports the field.
  • DNS query timeout: Check the nameserver, network reachability, DNS hijacking settings, and the domain resolution mode.
  • Connection refused: The destination port or node service may not be accepting connections, or an intermediate network policy may be blocking them.
  • Connection timeout: Check node address resolution, server reachability, transport parameters, and local firewall rules.
  • Proxy or node not found: This usually indicates a name mismatch in the profile references, missing subscription content, or an issue with the merged result.

A warning in the logs indicates an anomaly or compatibility notice that deserves attention; an error usually means the current operation failed. Context still matters. For example, one fallback DNS query may time out while another resolver returns a result successfully. Isolating a single line can hide what happened next. Keep several lines before and after the error and confirm that they correspond to the request you just made.

Logs may contain domains, node addresses, and local network details. Before sharing a screenshot or text extract, keep only the relevant lines and remove subscription URLs, authentication parameters, and personal network identifiers. Subscription links often contain access credentials and should not be published directly.

Settings: System proxy, TUN, and core status

The Settings page manages client behavior, launch at startup, the system proxy, TUN, the core, and network parameters. For first-time users, the key distinction is between the system proxy and TUN mode: both hand traffic to the core, but their coverage and system permission requirements differ.

The system proxy is suitable for browsers and standard desktop applications

When the system proxy is enabled, Clash Verge points the operating system’s HTTP and HTTPS proxy settings to local listening ports. Browsers and applications that follow system proxy settings send requests to the core. Some applications use their own proxy configuration, while some command-line tools require environment variables, so confirm through the Connections page that the target program’s traffic is actually entering after enabling the switch.

TUN mode is suitable for broader traffic capture

TUN mode handles IP traffic through a virtual network interface, covering more applications that do not read system proxy settings and commonly supporting UDP or transparent interception. It involves the virtual adapter, routing, and DNS settings, and may require system permissions. If other VPNs, virtual adapter tools, network filtering software, or corporate network components are running, watch for route and interface conflicts.

Using both the system proxy and TUN is not automatically better. For everyday browser traffic, start with the system proxy to establish the smallest verifiable path. Test TUN only when an application bypasses the system proxy or when gaming UDP or transparent proxying is required. After switching modes, check the connection list and DNS behavior again.

Treat the core and interface versions separately

Clash Verge Rev is the management interface, while mihomo is the core that executes proxy logic. The Settings page usually shows the core’s running status or related version information. The interface may open normally even when the core fails to start; in that case, proxy ports, rules, and the Connections page cannot work properly. If all nodes fail at once, the connection list is empty, and the logs lack normal startup entries, check the core status first.

Interface troubleshooting order for a failed first connection

The goal is to narrow the problem down one layer at a time, not to change the node, DNS, rules, and TUN simultaneously. Change one variable per step and verify the result through Connections or Logs so you can identify which adjustment actually helped.

  1. Check the Profiles page: Confirm that the subscription update finished, the target profile is selected, and its update time matches expectations.
  2. Check the Proxies page: Choose a node with a clear status, run a latency test for the main proxy groups, and confirm that the proxy chain ultimately points to that node.
  3. Temporary test mode: Use Global mode to test basic connectivity. If access returns, switch back to Rule mode and inspect the matched rules.
  4. Confirm traffic capture: Enable the system proxy and open a test page. If no connection is recorded, check the application’s proxy settings or evaluate whether TUN is needed.
  5. Check connection records: Verify the destination domain, matched rule, proxy group, and final node. After switching nodes, close old connections and test again.
  6. Read the logs: Around the test time, look for DNS, timeout, refused, and parse messages, then use the surrounding context to identify the affected stage.
  7. Restore a minimal profile: Temporarily disable extra scripts, complex overrides, and experimental DNS settings. Confirm the core route with a basic profile, then restore changes one at a time.

How to diagnose three common symptoms

The webpage will not open, but a connection is listed: Traffic has reached the core. Check the matched rule, node route, DNS result, and log errors. If the route shows DIRECT, check whether the rule sends the domain directly; if it shows a proxy node, focus on the connection between that node and the destination.

The browser works, but one application does not: The browser may follow the system proxy while the application uses direct access, its own proxy, or a specialized network stack. First check whether the application’s request appears on the Connections page, then configure its proxy or test TUN mode.

The node test succeeds, but the actual request times out: The latency-test URL differs from the destination, and the request may also involve rules, DNS, the transport protocol, or a reused connection. Close the relevant connection, check the destination domain’s proxy chain, and read logs from the same time instead of repeatedly running the latency test.

Which pages matter most in daily use?

Once the profile is stable, there is no need to adjust every setting frequently. Check Profiles when subscription content updates; open Proxies when changing regions or routes; review Connections and Logs first when access behaves unexpectedly; and after an operating system upgrade, core update, or network change, check TUN, the system proxy, and service status again.

In Rule mode, node selection is usually concentrated in a few main proxy groups. Note which groups handle general proxy traffic, streaming media, instant messaging, or other services so you can find the right control quickly. If the profile is maintained by a subscription provider, group names may change; recheck their hierarchy and current selections after an update.

Mastering the interface is not about clicking every feature. It is about understanding the question each page answers: Profiles tells you “what was loaded,” Proxies tells you “what is selected,” Connections tells you “where traffic actually went,” Logs tells you “what happened during processing,” and Settings tells you “how traffic enters the core.” These five questions cover most first-installation, subscription-import, and connection-troubleshooting scenarios.