How to Read Clash Verge Rev Logs: Common Errors and Troubleshooting

Reproduce the issue once, then check the logs from that moment

Clash Verge Rev logs help pinpoint where a failure occurs: whether the configuration loaded, the domain resolved, which rule matched the request, and whether the proxy node is reachable. A red error does not necessarily mean all connections are down, and one failed entry does not prove that a subscription is invalid. Start by identifying the action that failed, then review the entries around that time.

The client interface and the mihomo core handle different tasks. Subscription downloads, interface actions, and service management may generate client logs; proxy connections, rule matching, and DNS handling are primarily logged by the core. If a subscription update fails, first check the message for that update. If a website will not load in your browser, start with the core connection logs.

1. Open Logs in the sidebar, note the current time, and pause other downloads or speed tests.
2. Visit just one website that is having problems and refresh it once. Avoid opening a dozen tabs at the same time.
3. Find the target domain, port, and error text from that moment in the logs. If there is a search box, enter a keyword; otherwise, copy the relevant lines and search them in a local text editor.
4. Open Connections and check the destination address, matched rule, and proxy chain. Short-lived connections may disappear quickly, so use the logs you captured as your reference.

Changing the log level: use info day to day and debug for troubleshooting

The log level controls how much detail is recorded; changing it will not fix a connection. Look for the log-level selector at the top of the Logs page. Versions that provide this control may let you switch temporarily from info to debug. If the interface only offers filters, distinguish between filtering logs already received and changing the core log level: changing the display filter will not make the core provide details it did not record.

If the interface has no log-level control

mihomo uses the top-level log-level configuration field. If you need to change it in the configuration, make a backup first, then add the line below through an override or merge option supported by your version and reload the configuration. Do not edit the original subscription content if a later update will overwrite it, and do not assume the change has taken effect until you verify it.

log-level: debug

Reproduce the issue and check that more detailed entries appear. When you're done troubleshooting, set the level back to info. Debug logs may include visited domains, private network addresses, and proxy names, so avoid leaving debug enabled for long periods or publishing unredacted logs.

Connection timeouts: identify whether the node or destination is timing out

i/o timeout, context deadline exceeded, and connect: connection timed out all mean an operation did not finish in time, but they can occur at very different points. If dial tcp appears nearby, check the IP address and port it is trying to reach instead of changing DNS as soon as you see a timeout.

dial tcp 203.0.113.10:443: i/o timeout
context deadline exceeded

203.0.113.10 is a documentation-only example address, not a usable node for testing. If the address in your actual logs belongs to a proxy server, check the connection between your device and the node. If the request matched DIRECT, the address may belong to the destination website. With a multi-hop proxy chain, also identify which hop failed.

Compare results against the same destination

• Only one node times out: Switch to another known-working node in the same proxy group and visit the same URL. If that works, check the original node's address, port, service status, and network reachability.
• Multiple nodes time out: Check your local network, captive portal sign-in, firewall, and whether the proxy server addresses resolve correctly. If several nodes share a domain, their common entry point may also be the problem.
• Only one website times out: Check the rule and egress route. A destination-side outage, egress restriction, or routing problem can all look the same.
• Speed test succeeds but websites fail: A speed test usually connects only to its configured test URL. It does not guarantee that every website, UDP traffic, or every protocol will work.

Do not start by setting a much longer timeout. Waiting longer only delays the error; it will not fix an incorrect node address or restore a blocked connection.

DNS resolution failures: distinguish missing records from an unreachable DNS server

If you see no such host, DNS resolve failed, or a timeout that includes an upstream DNS address, first identify which domain failed to resolve. If the proxy server's domain cannot resolve, many websites may become unavailable. If only one website's domain fails, focus your checks on that domain.

A system DNS test is not the same as a core DNS test

For comparison, you can run a system command to look up the example domain below:

nslookup example.com

A successful system lookup only shows that the resolution path used by that command returned a result. mihomo may use its own dns.nameserver, encrypted DNS, domain policies, or a dedicated resolver for proxy servers, so the results are not interchangeable. Your browser's secure DNS may also use a separate path.

With TUN enabled, also check whether DNS hijacking is capturing the intended traffic. In Fake-IP mode, seeing an address from the configured synthetic range in connection details is not necessarily a problem; for example, 198.18.0.0/16 is commonly used as a Fake-IP pool. Check the domain mapping and matched rule to understand the resulting connection. Do not delete the entire DNS configuration based on the address alone.

Configuration errors: check indentation at the reported line, then check field references

Configuration load failures usually happen before a connection is established. Common messages include yaml: line 12: did not find expected key, field type mismatches, and references to policy groups that do not exist. Switching nodes repeatedly will not help; first make sure the configuration parses and passes core validation.

Indentation and field type errors

# Incorrect: nameserver is at the wrong indentation level
dns:
  enable: true
 nameserver:
    - 1.1.1.1

# Correct: align fields at the same level and place the list under nameserver
dns:
  enable: true
  nameserver:
    - 1.1.1.1

YAML uses spaces for indentation; do not use tabs. The reported line often marks where the parser noticed the problem, but the actual mistake may be on the previous line, such as a missing colon, an unclosed quote, or incorrect list indentation. When checking the reported line, read at least a few lines above and below it.

• Field types: mixed-port: 7897 expects a numeric port. A list field cannot be replaced with a single string.
• Name references: Policy names in rules must match an existing proxy or proxy group. After renaming a group, check its references in rules as well.
• Rule providers: Names referenced by RULE-SET must be defined under rule-providers. A download failure and a missing name are two different issues.
• Configuration source: If the problem only starts after a subscription update, keep the error message and previous configuration. Then determine whether the subscription returned invalid content or a local override conflicts with the new configuration.

Connection refused and address already in use: identify which endpoint the error refers to

connection refused means the connection was explicitly rejected. If the address is 127.0.0.1:7897, check the local proxy listener first, not the remote node. Open Settings in the client to check the current mixed port and confirm the core is running. Any proxy port entered manually in an app must match it.

connect to 127.0.0.1:7897: connection refused
listen tcp 127.0.0.1:7897: bind: address already in use

The second error means the listening port is already in use. On Windows, run the command below in a terminal to see the listening process and its PID:

netstat -ano | findstr :7897

On macOS and Linux systems with lsof installed, you can check which process is listening on the same TCP port:

lsof -nP -iTCP:7897 -sTCP:LISTEN

First identify which process owns the port; do not terminate an unfamiliar system process. If you change the client's mixed port to 7898, update your browser extensions, terminal environment variables, and other manually configured proxies as well. For apps using the system proxy, check its status again so it does not keep pointing to the old port.

If the refused connection is to a remote node address, check the node's port and service status. The same error keyword can point to different problems depending on the address.

How to tell TLS errors, connection resets, and TUN issues apart

TLS certificate and handshake errors

For x509: certificate has expired or is not yet valid, first check your system date, time, and time zone, then verify the server certificate's validity period. Messages such as certificate is valid for may indicate a hostname mismatch. Check the node's server address, TLS service name, and subscription parameters.

TLS handshake timeout is not the same as a certificate error. It may also be caused by a blocked connection, packet loss, or an unresponsive server. Disabling certificate verification is not a general fix: it will not resolve every handshake failure and will weaken identity verification.

Connection resets and EOF

connection reset by peer means the connection was reset by the remote peer or a device along the route. EOF and unexpected EOF mean the connection ended while data was being read. The cause could be the destination service, proxy server, or an intermediary network; these terms alone do not identify who is responsible.

If an entry appears only after you close a page or finish a download, and everything worked as expected, you can monitor it for now. If every attempt to reach the same address fails immediately, note the destination, node, and time, then compare results using a different node or network.

TUN creation failures and permission issues

For errors involving a virtual interface, route installation, or permissions, first check that the client's service mode is working and that your system allows virtual network interfaces to be created. TUN handles network traffic; it cannot fix a failed node. If the system proxy works but TUN does not, focus on the virtual interface, routes, and conflicts with other VPNs.

When testing, do not change TUN, DNS, nodes, and rules all at once. Record the original state, then change one variable at a time. For an overview of the two traffic-handling modes, see the client guide; for field definitions, see Advanced Config.

Narrow down the issue by keyword and keep reproducible troubleshooting notes

A useful record links the failed action to the relevant log entry. Search for the destination domain first, then check errors from the same time window. This is usually more helpful than filtering for every error entry. Background health checks, rule-set updates, and other apps also generate logs, so do not attribute every warning to the page you are testing.

1. Record your environment: Note the operating system, actual client version, actual mihomo version, and whether the system proxy and TUN are enabled. Check the versions shown by the client; do not infer them from the installation date.
2. Use a consistent reproduction: Record the URL, time, app name, and exact symptom, such as “the page keeps loading” or “proxy connection failed immediately.”
3. Keep the surrounding context: Copy about 10 to 20 relevant log lines from around the first failure, including timestamps, error keywords, ports, and rule details.
4. Run one comparison: Change only the node or only the network, and note whether the issue goes away. Do not rewrite the configuration at the same time and then attribute the result to a single setting.
5. Restore your normal settings: Set the log level back to info, undo temporary test changes, and save the final working configuration.

Use this troubleshooting order: did the configuration load → is the local port listening → did the domain resolve → did the expected rule match → can the node reach the destination? Fix the earliest failure in the chain first, then review any later errors. This reduces repeated changes and helps avoid mistaking multiple log entries from the same failure for separate issues.