FAQ and Troubleshooting
This page focuses on Windows-side issues involving interface components, TUN behavior, permissions, system proxy residue, startup failures, subscription errors, and update-related problems. The goal is fault isolation and recovery, not feature overview.
Problem scope and troubleshooting order
Most recurring issues on this page fall into four groups: interface and runtime dependencies, permissions and system services, traffic capture and proxy residue, and update or subscription-side failures. Similar symptoms can come from very different causes. A tray-only launch, for example, is usually a component problem, while broken connectivity after TUN is enabled is more likely tied to adapters, routing, permissions, or firewall behavior.
A more reliable troubleshooting order is to start with the system layer before changing application settings: confirm the operating system state, component availability, service health, and proxy status first, then review client behavior, subscription state, and startup entries. This reduces the chance of masking the original failure by changing several unrelated settings at the same time.
This page stays focused on diagnosis and recovery. Download paths, configuration structure, routing logic, and usage flow belong to other sections of the site and should remain separate from fault isolation whenever possible.
Possible causeCommunication between the interface and the running core has failed, or a local component is being blocked.
Handling pathCheck firewall and security software first, then confirm that the core process is running and that local networking components are not being interrupted.
Possible causeMultiple adapters, route conflicts, missing permissions, or security software interference.
Handling pathReview active adapters, default routes, firewall state, and TUN permissions before changing rules or provider settings.
Possible causeThe selected package does not match the device architecture.
Handling pathConfirm the system architecture first and then choose the matching build. Most desktop environments use x64 rather than arm64.
Possible causeWebView2 is missing, disabled, incomplete, or blocked by component-level changes on Windows.
Handling pathConfirm WebView2 availability and system component state first. If the runtime remains unavailable, a build marked with fixed_webview2 may provide a more stable fallback.
Possible causeSecurity software is blocking service-mode installation or a required driver path.
Handling pathCheck whether real-time protection or installation blocking is active before retrying service-mode setup.
Possible causeWindows Update is disabled, or the component installation path is incomplete.
Handling pathRestore the system update path first. If the runtime still cannot be installed, use a build that includes the required WebView2 fallback.
NoteCurrent client and runtime dependencies generally do not target Windows 7 anymore.
Handling pathUse a still-supported desktop environment for more predictable compatibility and security updates.
Possible causeStartup entries are inconsistent across permission levels, or old entries were not removed cleanly.
Handling pathToggle the auto-start setting again under the actual permission mode being used, then check for old installs or duplicate paths.
Possible causeThe system proxy stayed enabled after the client stopped.
Handling pathCheck the Windows proxy settings and confirm that manual proxy use is no longer enabled.
SymptomThe logs report restricted socket access permissions.
Handling pathCheck the Host Network Service state first, then restart it if necessary:
net stop hns
net start hnsThe same service can also be restarted from the Windows Services panel.
Possible causeLegacy install paths or older versions are still interfering with update detection.
Handling pathRemove old installations and duplicate paths first, then reinstall the current build to restore a cleaner update path.
Possible causeLoopback restrictions prevent UWP apps from reaching the local proxy endpoint.
Handling pathUse the available UWP loopback tool to allow the affected applications to access the local proxy path.
NoteThe default host value is usually 127.0.0.1, which may not fit cross-host use.
Handling pathDefine CLASH_VERGE_REV_IP as a user environment variable, then restart the client before copying the PowerShell variable again.
SymptomThe operating system reports the proxy as enabled while the application shows a different state.
Handling pathStart with the current build, then inspect the related proxy registry path if the inconsistency remains.
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ConnSystem and components
Troubleshooting usually starts with the operating system, WebView2, service state, firewall behavior, and local networking components.
Quick commands and paths
- Host Network Service:
net stop hns/net start hns - UWP loopback: allow the affected app in the UWP tool
- Proxy residue: Windows Settings → Proxy → disable manual proxy