On this page
First determine whether the UI has lost contact or the core is actually stopped
A “core communication error” on the home page and an empty current node often make it seem that proxying has stopped completely. Do not delete the subscription or change DNS yet. Open the Logs and Connections pages, visit a new webpage, and see whether its domain and egress appear.
If the webpage still opens and the log continues showing TCP or UDP connections, Mihomo may still be forwarding traffic while the desktop UI cannot read policy groups or the current node. A recent official issue recorded this exact state: the local port used by the system proxy continued to work, and the runtime configuration contained nodes, but the home and proxies pages could not read control information.
Group by observed behavior first
| What you see | More likely issue | Where to start in this article |
|---|---|---|
| Webpages work, the log keeps updating, and the proxies page is blank | Abnormal control communication between the UI and core | Update first, then inspect service mode |
| Webpages do not work, and the log shows no new connections | The core did not start, or requests do not enter the client | Check configuration validation, the service, and local ports |
| The node count becomes zero after a subscription update | Subscription content or parsing failed | Return to the subscription update error; do not troubleshoot the control channel |
| Only one website fails | A rule, DNS, or destination-site compatibility issue | Pin a node and inspect the match record for that domain |
Install an official release containing the communication-status fixes first
Official Clash Verge Rev v2.5.2 release notes list fixes for the home proxy card incorrectly showing a communication error, the current proxy state occasionally failing to synchronize, and rule-page data not refreshing promptly after reloading the Clash configuration. If the issue occurs on v2.5.1 or earlier, updating the official release is more direct than changing the controller port.
Choose an installer matching the Windows architecture from the project's official Release or a download page here with a stated source. Export logs and record the current subscription name before updating. After installation, quit the client completely once and reopen it. Do not change the subscription, TUN, DNS, and service mode together, or you will not know which step worked.
One verifiable update
Record the current version and error
Note the version on the About page, capture the home-page message and proxies-page state, and export a log without subscription links.
Download the official package for the matching architecture
Most Windows PCs use x64. Choose ARM64 only for an ARM Windows device, and download only from a traceable release source.
Install after closing the client
Quit Clash Verge Rev from the tray first, wait for the installer to finish, then launch it as a standard user.
Test only the original Profile
Keep the original node, Rule mode, and system-proxy setting while checking whether policy groups return.
If the proxies page remains blank, check whether two core processes are competing for the same port
If the error remains after updating, open the Details tab in Task Manager. Normal service mode shows the desktop app, service process, and one Mihomo core. If two verge-mihomo.exe processes exist, an old one may hold mixed-port or the named pipe, preventing the new core from starting completely.
Do not force-end every process whose name contains Clash. Quit the client from the tray, wait several seconds, and check whether two verge-mihomo.exe processes remain. Focus on a stale process, port conflict, or service state only if the log contains bind, Only one usage, Access is denied, or pipe listen error.
Get-Process clash-verge, verge-mihomo -ErrorAction SilentlyContinue
Get-NetTCPConnection -State Listen |
Where-Object LocalPort -eq 7897 |
Select-Object LocalAddress, LocalPort, OwningProcess
Get-Process -Id (Get-NetTCPConnection -State Listen |
Where-Object LocalPort -eq 7897 |
Select-Object -First 1 -ExpandProperty OwningProcess)The command only identifies the listener; it does not end a process. The Mixed port may not be 7897, so use the actual value from client settings or the log. If one verge-mihomo.exe is listening normally and the log already contains proxied requests, stop treating the issue as a port conflict.
The first log error determines the next step
In service mode, the client generates and validates the runtime configuration, asks the service to start the core, and finally reads policy groups through the control interface. Looking only at the final “communication error” hides the actual failure point. Restart once, then scan from the top of the log for the first error.
Configuration validation failed, Invalid YAML, or unsupported field
The problem is in the Profile or override. Switch back to the unmodified subscription, temporarily disable Merge, scripts, and custom fields, then validate again.
mixed port bind failed、Only one usage
A local port is occupied by an old core or another program. Quit the client, identify the listening process, then restart Windows to clear stale state.
pipe listen error、Access is denied
The service failed to create the control channel, or permissions do not match. Restart the client service first, then reinstall service mode if it still fails.
Configuration validates, the port and pipe are listening, but the UI still reports an error
This more likely means the desktop UI cannot read control information. Confirm that the official release is installed and export logs for a project issue; stop changing nodes.
The core starts successfully, but no new connection appears
Check whether the Windows system proxy still points to the current Mixed port. If using TUN, confirm that the virtual adapter is actually enabled.
Refresh the Windows firewall once in a reversible way
The official Clash Verge Rev Windows FAQ attributes a blank proxies menu to failed core communication and recommends turning the Windows firewall off and back on. The purpose is to reload firewall rules, not to leave protection disabled.
Open Firewall & network protection in Windows Security and record the current network type. Briefly turn off Microsoft Defender Firewall for that network, turn it back on immediately, then quit and restart Clash Verge Rev. On a company PC managed by administrator policy, do not bypass the policy; give the logs to the administrator to inspect app and local-communication rules.
Confirm after refreshing the firewall
- Microsoft Defender Firewall is enabled again
- No internet-facing inbound port was added for testing
- Clash Verge Rev and the service process were not quarantined by security software
- After reopening the client, policy groups appear and nodes can be switched
Nodes in the configuration do not guarantee that the UI can read them
Subscription download, runtime configuration, and proxies-page display are three separate stages. A timestamp on the subscription page proves only that the address was saved and processed once. proxies and proxy-groups in runtime YAML show that the core received nodes. The proxies page must still read those groups over the control interface.
In a recent official diagnostic record, the runtime configuration contained proxies and policy groups and the Mixed port forwarded traffic, but external-controller was empty, leaving only a named pipe for the desktop UI. Opening an HTTP controller yourself is not the preferred fix and can expose the management interface more broadly. Update the official release, restart the service, and refresh the firewall first.
How to validate the three stages
| Stage | Valid evidence | What not to do when it fails |
|---|---|---|
| Subscription download | The update succeeds and displays a real node count | Do not look only for the subscription name |
| Core runtime | The log shows successful configuration validation, listening ports, and real connections | Do not use the home card alone to conclude that the core is dead |
| UI control | Policy groups are visible, the current node can be read, and switching takes effect | Do not expose external-controller just to restore the UI |
Reinstall service mode only after confirming that the service is abnormal
Handle service mode only when the log explicitly points to the service, pipe permissions, or a duplicate core and both updating and refreshing the firewall fail. Disable the system proxy and TUN first, confirm that ordinary networking recovers, then uninstall the service through Service Mode in client settings, restart Windows, and reinstall it.
Reinstalling the service does not fix an expired subscription and should not become the default response to every blank proxies page. If administrator rights are unavailable after restarting, the button is disabled by policy, or security software blocks service installation, stop retrying and retain the exported app and service logs.
Safe recovery order
Restore direct Windows connectivity first
Disable the system proxy and TUN, then use the browser to confirm that ordinary webpages still open after the client exits.
Back up the Profile and logs
Do not expose the subscription URL, node passwords, or controller secret. Attach only redacted excerpts to the problem report.
Uninstall and restart
Uninstall through Service Mode in the client instead of manually deleting system-service files, then restart Windows.
Reinstall service mode
Request administrator rights through the normal client entry point. After startup, enable only the original Profile for validation.
Stop changing the configuration if it still fails
Submit the version, system architecture, first error, process results, and port results to the official issue.
The fix must pass five checks together
The proxies page returning does not mean the problem is completely resolved. Complete one end-to-end request with the same Profile and node to confirm that the service, control channel, and forwarding all recovered.
Completion criteria
- The home page no longer shows a core communication error, and the current proxy mode and node name are readable
- The proxies page shows every policy group, and the selected state updates immediately after switching nodes
- Task Manager shows only one working verge-mihomo.exe
- When the browser opens the test site, Connections shows the domain, rule, and egress
- After the client exits, the Windows system proxy turns off and ordinary networking recovers