How do I confirm the correct file?

Compare repository owner, tag, filename, size, and checksum with official Releases. A mirror must not change those identifiers.

Should I choose x64 or arm64?

Use the architecture reported by the operating system. Intel/AMD PCs are usually x64; Apple Silicon and some Windows devices use arm64; Android users inspect ABI.

Does a security warning prove the file is unsafe?

Not necessarily, but never bypass it blindly. Verify source, signature, and hash first, then use the platform-specific review flow.

dl-clashverge.org · macOS

Clash Verge Rev for macOS: download, install, and first-run guide

One release can contain many files. Confirm the operating system, CPU architecture, and package format before installation to avoid most compatibility failures.

platform and architecture choice

Project relationship and intended users

Mihomo is the core, while graphical clients such as Clash Verge Rev provide subscription, rule, system-proxy, and TUN controls. Most desktop users need a graphical client rather than a raw core archive.

Check system and architecture

Use About This Mac to distinguish Intel from Apple Silicon. Intel normally uses x64/amd64; M-series systems use arm64/aarch64; Universal packages support both at a larger size.

Package formats and filenames

If Gatekeeper blocks first launch, verify source and signature before using the Privacy & Security workflow. Do not disable Gatekeeper globally.

Verify the release source first

Confirm the release through the official repository, release page, or platform store. A mirror can change delivery speed, but filename, tag, and checksum must still match the official record. Search snippets labeled latest can be stale.

Open the official Releases page and confirm the owner
Choose operating system and CPU architecture
Compare filename, tag, and publication date
Calculate SHA-256 when supplied
Keep the release page and verification result

Before installation

Close old instances, back up required configuration, and confirm disk space and system time. Before an upgrade, record the old version and data path so a program change can be separated from a configuration change.

Installation steps

Run only a package traced to the verified release. Grant necessary permissions through normal platform prompts and do not permanently disable protection. Launch once and confirm the interface, version, and data path.

Download the correct platform build
Back up configuration or recovery data
Install and launch once
Prepare one configuration or account
Validate one explicit function
Enable advanced options one at a time

The smallest first-run loop

Import one known-good configuration, select an available endpoint or policy group, and enable the system proxy. Evaluate TUN only for applications that do not honor the system proxy.

Verify the result

Test one explicit outcome: the app opens, configuration loads, the required feature is enabled, and real behavior matches the status. A colored button alone is not evidence; compare logs and the target application.

Enable advanced settings in order

Complete one working loop on defaults, then change TUN, DNS, rule overrides, background behavior, or autostart one at a time. Record each result so the last change can be reversed.

Updates, backup, and rollback

Back up before updating. Afterward, check app and core versions before reusing configuration. Preserve logs and return to the last known-good state instead of deleting all data.

Security and privacy

Subscription URLs, recovery phrases, private keys, credentials, and debug logs may contain secrets. Redact them before screenshots or support requests and never paste them into unknown checkers.