On this page
After Windows starts, Clash Verge Rev may freeze for about two minutes and then report a service fallback. Toggling the system proxy or updating a subscription during the wait can also report that the core is not running. Check the service start type before changing nodes or reinstalling repeatedly.
Separate a startup wait from a connection failure
This guide covers Clash Verge Rev service startup on Windows 10/11. An official issue documents a wait followed by a fallback to the regular core after the service was set to manual. The v2.5.8 release lists a fix and a repair action. A wait of about two minutes is a clue to this case, not an explanation for every slow launch.
Choose the next check from the symptom
| What you see | What to check first |
|---|---|
| A long wait after boot, followed by a service fallback | Check the start type and current state of clash_verge_service, together with the application log. |
| The service is missing or its path belongs to another installation | Check service installation and version compatibility. Setting automatic startup does not install a service. |
| The service works, but node tests or websites fail | Check the node, DNS and rules. Do not keep changing the service start type. |
| The log explicitly reports a core file security check failure | Use the relevant security check guide. A start type change cannot repair a file or its permissions. |
Service startup and application autostart are separate
The Clash Verge Rev service helps launch the core with elevated privileges so the application can use TUN while its main interface runs with normal permissions. Opening the application at login and starting its Windows service automatically are separate settings. Enabling application autostart does not verify the service type.
Automatic, manual and disabled are different Windows service settings. A manual service does not become ready just because the computer boots; a disabled service cannot be started directly. Check its actual state instead of treating the application icon or one successful connection as proof of recovery.
A maintainer in the official issue noted that startup optimization tools can change the service type. That does not establish the same cause on every computer, and an upgrade does not guarantee that another tool will stop changing the setting.
The dedicated message in the v2.5.8 release build has a further condition: the service is stopped and its start type is not automatic. A running service can still be set to manual without immediately triggering that message. Whether it will be ready after the next boot needs a separate check.
Record the service configuration and state first
Save a comparison before repairing
Record the version and logs
Note the full client and Windows versions, the approximate wait and the final message. Keep the application log from startup, not just its last line. Use the existing log directory entry in application settings to find it.
Query the actual service
Run the two read-only commands below in Command Prompt or PowerShell. Use the full sc.exe name to avoid an ambiguous command name. Save the output before deciding whether to change anything.
Check identity and state
Read START_TYPE, BINARY_PATH_NAME, STATE and PID. Confirm the name is clash_verge_service and the path belongs to the current trusted installation. Manual commonly appears as DEMAND_START and automatic as AUTO_START. A running service is not proof that it will start at the next boot.
sc.exe qc clash_verge_service
sc.exe queryex clash_verge_serviceIf the service is missing, access is denied or the path does not match the current installation, keep the complete error. A missing service needs the proper installation or repair flow. On a managed computer, follow the administrator's process instead of guessing a path or deleting the service.
Restore automatic startup only after confirming the change
Back up the configuration and verify that the v2.5.8 release and its matching current service component are installed. In the Repair service prompt, Reinstall service reinstalls the service and then restarts the core. Check the actual result afterwards. Handle old services or an unknown security state through the official channel before enabling them.
The manual route below is for a trusted service confirmed to match v2.5.8, where restoring automatic startup is allowed. A familiar installation source and directory do not verify the service version or security state. If uncertain, use the application's service reinstall flow first.
Manual recovery order
Exit the current client first
Record the original system proxy and TUN settings and the previously working network path first. Save the configuration, temporarily turn those switches off and exit normally. Repairs can interrupt networking, so choose a suitable time. Do not run several versions and repeatedly install their services.
Change the type with administrator rights
Open an administrator Command Prompt and run only the first command below. Keep the space after start=. It changes the service start type; it does not start the service immediately.
Start the service, then reopen the application
After the first command succeeds, run the second and query the state again. If the service is already running, verify that state instead of repeatedly changing the configuration. Then open the client normally.
sc.exe config clash_verge_service start= auto
sc.exe start clash_verge_serviceStop at any failed step and keep the original error and configuration output. Do not also change binpath, the service account or permissions, or disable security software. Security check failures, leftover cores and incompatible service protocols have separate diagnostic paths.
Verify reopening and rebooting before calling it fixed
Post-repair checklist
- START_TYPE from sc.exe qc matches the intended setting, and BINARY_PATH_NAME still points to the trusted path checked before the repair.
- sc.exe queryex reports the service running. Reopening the client no longer produces this long wait or service fallback message.
- Restore the required system proxy and TUN settings. Check the application log and real HTTPS requests, rather than only latency tests or switch colors.
- At a suitable time, reboot Windows and query the type and state again. Confirm that recovery was not just the result of starting the service manually this time.
- If it becomes manual or disabled again after reboot, retain the relevant Service Control Manager events and timestamps. Identify the policy or tool that changed it instead of reinstalling every day.
When checking startup optimization settings, change only a rule clearly tied to this service and keep the original configuration. Follow the administrator's process on managed devices. Verify application autostart, service start type and whether TUN should be enabled separately.
Roll back or investigate a different startup failure
To undo the manual change, use the saved START_TYPE. Manual corresponds to demand and disabled to disabled. Use the same sc.exe config syntax, replacing only the type after start=. Changing the type does not stop a running service; restoring these types may leave it unready at the next boot again.
Until the service works, restore the previously working network path from your notes rather than assuming TUN has recovered. Save your work, exit the client and use the supported flow when disabling or reinstalling a service. Do not experiment by deleting it or changing its executable path.
If an upgrade causes compatibility problems, retain configuration backups and current logs, then restore the appropriate version and service component through the project's supported process. Do not let old and new versions share the only data directory. A downgrade does not restore another tool's startup policy; avoid builds with unresolved known security problems.
If the service starts automatically but the failure remains, record any old service or leftover core, the actual path and the complete error. Continue with the security check or core communication guide. An automatic startup command is not a universal service repair.
References
- Clash Verge Revv2.5.8 release: fix the wait for a manual service and provide a repair action
- Clash Verge RevOfficial issue #8129: maintainer explanations of start type, waiting and the service's role
- Microsoft LearnMicrosoft: query and configure Windows services with SC
- Microsoft LearnMicrosoft: sc.exe config start types and required spacing
- Microsoft LearnMicrosoft: service state and process information with sc queryex
- Clash Verge Revv2.5.8 source: detect a stopped Windows service and its automatic start type
- Clash Verge Revv2.5.8 source: service repair prompt, reinstall and core restart