What to Do When Clash Verge Rev Blocks Windows Shutdown or Restart

This article addresses one specific symptom: when Clash Verge Rev remains running, Windows shutdown or restart stops at the “This app is preventing shutdown” screen. After canceling shutdown, the client may show a blank window or fail to exit normally, while fully exiting it from the system tray before shutdown restores normal behavior.

Official repository issues #7725, #7755, #7794, and #7841 contain multiple similar reports covering Windows 10, Windows 11, stable v2.5.2, and later AutoBuilds. Some reports still reproduce after TUN and system proxy are disabled, so turning off TUN alone does not prove that Service has exited.

First confirm that Clash Verge Service is installed, Running Mode in the diagnostics shows Service, the app remains in the tray after the main window is closed, and shutdown is blocked only while the app is running. This article does not apply when the blocker is an unsaved document, Windows Update, another VPN, or a differently named background process.

For the first test, leave Clash Verge Rev running, save all work, and restart once. If the blocking screen appears, cancel the restart instead of choosing “Shut down anyway,” and note the time.

For the second test, choose “Exit” from the system tray instead of only clicking the window's Close button. Wait for the tray icon to disappear, confirm in Task Manager that the Clash Verge Rev GUI has ended, and then perform the same restart.

Inspect the Service only if you can consistently reproduce the difference between “blocked while running” and “normal after a full exit.” If both tests are blocked, use the Windows prompt and Task Manager to identify the actual blocking process first.

After canceling shutdown, open the latest application log and read from the exit phase onward. Similar reports first save the configuration, disable TUN, and stop the core, then stall at “Stopping core through service (IPC).”

If the log never reaches “Service successfully stopped the core,” cleanup completion, or Application exited, while a manual tray exit records those completion messages normally, you can narrow the fault boundary to the Service stop request or its completion wait during the system shutdown path.

The reporter in issue #7794 used process dumps to conclude that the Service had returned to an idle state while the client-side IPC completion wait never returned. This is useful diagnostic evidence, but it is not an official root-cause conclusion from the maintainers.

Before disabling the Service or changing versions, record the current version, Running Mode, subscription name, active Profile, and whether the system proxy and TUN are enabled. Turn off TUN and the system proxy, confirm Windows can reach the LAN or basic network without relying on a local proxy port, and then fully exit from the tray.

Do not delete the AppData configuration directory or publicly upload complete logs containing subscriptions, node passwords, controller secrets, or tokens. If you need to submit a dump, understand first that process memory may contain sensitive information.

The lowest-risk temporary workaround is to choose “Exit” from the system tray before shutdown or restart, wait for the GUI, Mihomo core, and cleanup process to finish, and only then shut down Windows. Closing the main window usually only hides the app in the tray and does not prove that exit is complete.

This step does not modify the configuration, uninstall the Service, or change subscriptions. Start Clash Verge Rev normally after the next boot to restore operation. It is the best default workaround while the issue is still awaiting an official fix.

If manually exiting before every shutdown is impractical, you can temporarily leave Service Mode. First disable TUN and the system proxy and confirm normal network access, then use the Service Mode control in the current client settings to disable or uninstall Clash Verge Service. Button labels can differ between builds, so prefer the in-app control.

Do not directly delete Windows service registry entries, virtual network adapters, or service files in the installation directory. Restart Windows after uninstalling, then open the client and confirm that Running Mode has returned to Sidecar or another non-Service state.

Verify basic connectivity with the system proxy alone first. TUN may be unavailable without the Service or administrator privileges; this is an expected tradeoff and should not be bypassed by repeatedly toggling TUN.

Reporters in issues #7725 and #7794 identified v2.5.1 as the last working version on their own devices, but this is not a general rollback guarantee from the maintainers. Consider a controlled comparison with the official v2.5.1 Release only after reproducing the same log boundary, confirming that a full exit resolves it, testing with the Service disabled, and establishing that you genuinely need Service Mode.

Before rolling back, keep the current stable installer, record the version and configuration, and download v2.5.1 for the correct device architecture from the project's official Release. Do not delete user configuration. On first launch, keep TUN and the Service off, confirm the subscription and system proxy work, then install the Service and change only that one variable for the shutdown test.

Older versions lack later fixes and should not be used long term. If v2.5.1 still blocks shutdown, stop treating the version as the cause. Reinstall the current stable v2.5.2 or a later stable release that officially confirms a fix, and initially leave the Service uninstalled.

Do not repeatedly choose “Shut down anyway” or hold the power button. Do not delete the entire AppData configuration directory, manually remove unknown Windows services or virtual adapters, or download an AutoBuild from an unverified source for testing.

Force-ending a process can clear one block, but it may skip configuration saving and proxy cleanup. Use Task Manager to end the GUI only as a last resort to recover the current desktop after canceling shutdown, saving all work, and confirming that the client cannot exit on its own. Check the system proxy afterward.

After choosing one workaround, complete two consecutive restarts at a controlled time. Save your work before each test, record whether the blocking screen appears, and check the system proxy, subscription, Profile, and rules after signing in again.

An unblocked shutdown is only the first result. Also confirm that the log completes the core stop before exit, Windows has no leftover proxy after restart, the configuration remains intact after reopening the client, and the system proxy can complete a new HTTPS request.

As of 2026-09-01, the available evidence shows that Clash Verge Rev blocking Windows shutdown is not an isolated user report. The behavior has been reported multiple times when Service Mode is active and the GUI remains running, and an official collaborator also reproduced it in issue #7755.

However, it would be inaccurate to say that “Service IPC has been officially confirmed as the sole root cause.” Issue #7725 was closed after a maintainer requested retesting following the Service refactor; it was not an official fix announcement. Issue #7794 later reported that a post-refactor AutoBuild still reproduced the problem, and #7841 recorded the same behavior with v2.5.2 on Windows 10.

Stable release notes have not yet announced a fix. A follow-up report should include redacted logs, the version, Running Mode, a manual-exit comparison, and whether the Service is installed. Do not publish full process dumps, subscriptions, or node credentials.