Choose the right log before taking a screenshot

When startup, subscription updates or a connection fail, someone may ask for a log. That does not mean uploading your whole configuration folder. Clash Verge Rev application logs and Mihomo core logs cover different parts of the process; the wrong file may contain nothing relevant to the failure.

This guide covers the official Clash Verge Rev v2.5.2 release on Windows 10/11, x64 or ARM64, using its English interface. Rev is maintained separately from the discontinued Clash for Windows. The steps collect existing logs and assume you can open Settings. If the application cannot open at all, or you use another version or development build, do not guess a fixed directory from these instructions.

The sidebar Logs page displays core messages. Its filtering, pause and clear controls are not an application-log export button. Export Diagnostic Info is also separate from the file-copy workflow below. Keep the current logging level and start with existing records; do not immediately enable Debug or delete old logs just to find the files.

Open the actual folder from Verge Advanced Setting

  1. Open Settings and find Verge Advanced Setting.
  2. Select Open Logs Dir to open the log folder used by this application instance.
  3. Check that it is the logs directory. Inspect it without moving or renaming files.
  4. Note the failure's local time and time zone. Avoid mixing in logs from another account or an old installation.

The application's own action is more reliable than copying somebody else's absolute path. Data locations can differ with the Windows account or portable setup; logs are not necessarily next to the installed executable. Paths below are relative to the log folder just opened, not directories you should create at the root of a drive.

Match filenames to the version: the official export guide still describes selecting date-named files with the highest sequence number. The v2.5.2 implementation uses latest for current logs and keeps rotated files. Missing that older naming pattern does not establish that your logs are lost.

Application logs and core logs are different files

Relative pathMain purposeWhat to check
latest.logClash Verge Rev application logRelevant startup, configuration handling and application errors
service/service_latest.logCore log in service modeCore output corresponding to the failure
sidecar/sidecar_latest.logCore log in sidecar modeWhether it is being written and contains the relevant time range

A folder's existence does not establish the current running mode. Changing modes in the past can leave both folders behind. Compare the failure time, file modification time and records inside the file. If you cannot identify the mode, say so and keep both categories locally for comparison; do not switch service or TUN settings just to produce a log.

latest identifies the current write target, not a guarantee of the complete failure history. Rotation can move earlier records into adjacent older files. For an earlier incident, check the relevant rotated files in the same directory and copy the necessary surrounding records, not just the final error line.

Record the time, reproduce once and copy privately

Save your work first. If it will not make a payment, submit data twice or cause another side effect, repeat the failing operation once. Note the time, action, expected outcome and actual result. If reproduction is unsafe, use existing records and explain the limitation instead of repeating a risky action for logging.

  1. Allow the relevant records to appear, then choose files covering that time range.
  2. Copy them to a private, non-public folder on your computer. Leave the originals where they are.
  3. Open the copies in a trusted local text editor. Confirm their dates, contents and error context; rule out empty files and unrelated old incidents.
  4. Make separate sharing copies for redaction and retain untouched copies for your own reference.

A copy of an actively written log includes only what was read during copying; it is not a complete session snapshot. If the relevant event has not appeared yet, copy again and check it. Do not clear the original to “start fresh.” These steps do not change logging levels or retention, so there are no such settings to restore afterward.

Remove secrets without removing useful context

Inspect full subscription URLs, tokens, passwords, UUIDs, authentication headers, cookies, node addresses, IP addresses and paths containing your Windows username. Not every log contains every item, but any present value needs review before publication. Sensitive URLs may recur across lines or inside error messages; hiding one token in a screenshot is not enough.

Use [REDACTED] for hidden values and consistent aliases such as NODE_A for the same node. Keep timestamps, event order, error types and necessary context. Do not delete the entire useful error line or describe an edited copy as an untouched original. Search again for sensitive values and check filenames, screenshots and the paste preview.

Logs are not automatically safe to publish: do not upload the entire profiles folder or an unchecked data directory, and do not send originals to an unknown online redaction service. If a credential or authorized link was exposed, revoke or reset it through its provider. Deleting a post cannot guarantee nobody copied it.

Check the current template before reporting to the official project. The template inspected here requests pasted log content rather than uploaded log files. Prepare a redacted relevant time range together with the application version, OS version, time zone and reproduction steps. Existing logs may not satisfy a maintainer's request for Debug records; follow any additional request separately instead of sending all your configuration as a substitute.

Official sources and version scope

Version numbers, filenames, and interface labels can change. Confirm them in the linked project documentation before making changes.