Clash Verge Keeps Crashing on Startup: Logs, Corrupt Settings, and Port Conflicts

First, tell a UI crash from a core failure or a background process

“Clash Verge won’t open” can point to three different problems: the desktop app fails to create a window, the mihomo core fails to start, or the app is already running in the tray but its main window is hidden. A port conflict usually affects the core first; it doesn’t necessarily close the entire desktop process. Check the process state before deciding whether to reset settings or repair the runtime.

This guide focuses on troubleshooting Clash Verge Rev on Windows. The original Clash Verge and Clash Verge Rev are maintained in different branches, so their data folders and menu names may differ. Don’t identify the version by the desktop shortcut alone. If the window opens, go to Settings → About and note the full version number, along with your Windows version, system architecture, and most recent changes. Port numbers below are examples; use the values in your own configuration.

Restore a network path that doesn’t depend on the proxy first

If webpages stop loading after the client exits, first check Windows Settings → Network & internet → Proxy → Manual proxy setup. If the client set the proxy and its local listener has stopped, turn off “Use a proxy server.” For example, if Windows still points to 127.0.0.1:7890 but nothing is listening on that port, apps that use the system proxy may fail to connect.

Find the logs: start with the first error at the time of launch

If you can open the app, use the configuration and log folder shortcuts in Settings. Button names may vary slightly by release. This is more reliable than guessing from folder names. If the app won’t start at all, locate its data directory through the operating system.

Common Windows data folders

The following is a common user data directory for Clash Verge Rev. Press Win + R, paste the path, and press Enter. If the folder doesn’t exist, open %APPDATA% and check folder modification times to find the data directory for your installed branch.

%APPDATA%\io.github.clash-verge-rev.clash-verge-rev

You’ll typically find logs, profiles, and several YAML files in this directory. Log subfolders and filenames vary by version, so sort by the time you just launched the app; don’t assume every release uses the same log filename. The original Clash Verge may use io.github.clash-verge.clash-verge as its data directory, though this can vary by installation method.

• App logs: Look for UI initialization, file access, service communication, and backend startup errors.
• Core logs: Look for YAML parsing errors, rule provider loading failures, DNS listener issues, and port binding errors.
• System events: If the app logs haven’t updated, press Win + R, enter eventvwr.msc, then open Windows Logs → Application. Find errors from the same time and note the faulting application and module.

On macOS, app data is usually under ~/Library/Application Support/. On Linux, start with ~/.config/. Confirm the exact location using the client’s folder shortcut, app identifier, or package documentation; don’t apply Windows paths to other platforms.

Classify errors by keyword; don’t focus on the last line

Reproduce the issue once, then find the first clear error from that launch. A later “failed to connect to core” message may simply result from an earlier parse error or port conflict. Keep about 20 lines before and after the error; that’s usually more useful than a one-line screenshot.

• address already in use or bind: Check the listening address and port first.
• yaml, unmarshal, or parse: Check the config syntax, field types, and merged result first.
• permission denied or Access is denied: Check which file, service, or device operation was denied.
• WebView2 or a runtime error in System Events: Troubleshoot the UI runtime; don’t start by changing proxy rules.

Stale settings and corrupt files: back up, then test with a clean profile

If the app still crashes after reinstalling, its user data may have been left intact. The installer updates program files but may not reset subscription indexes, UI state, or override configs. The safer approach is to isolate the old data and test, not delete everything outright.

Back up everything, then isolate the config folder

1. Quit the client from the tray. In Task Manager, confirm that its desktop processes have exited. If it runs a background service, stop it using the method provided by the client. Don’t end system processes you can’t identify.
2. Copy the entire user data directory to a separate backup location. It may contain subscription URLs and keys, so restrict access to the backup.
3. Rename the original data directory, for example by appending .backup-20260915 to its name. Keep the original files so you can restore them.
4. Restart the same client. It should create fresh data. Don’t import subscriptions or enable TUN yet; first check whether the window and basic core start normally.

If the app starts with fresh data, the issue is likely in the old config or state. If it still exits, keep the newly generated logs and continue checking the runtime environment. Don’t copy the entire old folder back right away, or you may reintroduce the same problem.

Restore subscriptions, overrides, then TUN—in that order

Restore one trusted subscription and confirm that the core starts. Then restore rules, config merges, and scripts one at a time. Restore TUN and service settings last, restarting to test after each change. A subscription file that parses on its own doesn’t guarantee the final merged config is valid.

• Use spaces, not tabs, for YAML indentation. Check the hyphens before list items and the spaces after colons.
• Check for text accidentally entered in port fields, arrays written as strings, and policy groups that reference missing nodes or groups.
• Check the policy group names at the end of custom rules and make sure they match the current subscription exactly.
• When migrating an old core config, check each field against the current mihomo version. A config accepted by an older release isn’t necessarily compatible with the current one.

To verify from the command line, test a copy of the final config with the core. The command below requires the corresponding mihomo executable and config.yaml in the current directory. It validates the config without starting a persistent proxy.

.\mihomo.exe -t -f .\config.yaml

Use the same core version that the client actually runs, if possible. Configs that include rule providers or external files also depend on the working directory and resource paths, so compare command-line results with the client logs. Don’t treat a successful test of the original subscription file as proof that the final merged config is valid.

Port conflicts: identify the listener before changing settings

Common conflicts involve the HTTP/SOCKS mixed proxy port, the controller API port, and the DNS listener port when local DNS is enabled. The examples below use 7890 and 9090 to demonstrate how to check ports; they aren’t defaults for every Clash Verge Rev release.

Find the PID and process name on Windows

Run these commands in PowerShell. The first lists TCP listeners on the specified port and their PIDs. After you get a PID, the second shows which process it belongs to. Replace 4321 in the example with the PID you found.

Get-NetTCPConnection -State Listen -LocalPort 7890,9090 -ErrorAction SilentlyContinue |
  Select-Object LocalAddress,LocalPort,OwningProcess

Get-Process -Id 4321 | Select-Object Id,ProcessName,Path

No output means there was no matching TCP listener at the time of the query. For DNS or other UDP conflicts, check UDP too. For example, if your config uses 1053:

Get-NetUDPEndpoint -LocalPort 1053 -ErrorAction SilentlyContinue |
  Select-Object LocalAddress,LocalPort,OwningProcess

If another proxy client owns the port, quit that client and its background service normally. If the listener belongs to this client’s own core, you may have a duplicate instance or a service that’s still running. Check the process path, start time, and logs; don’t kill a process just because its name contains mihomo. Without sufficient permissions, the process path may be blank in the results.

Update system proxy settings when changing proxy ports

If you need to run both clients at once, change one client’s mixed port from 7890 to an unused port, such as 7897. Make the change through the current version’s settings or a persistent override; don’t edit a file that gets regenerated at the next launch.

After changing the port, toggle the client’s system proxy off and on again. Check the proxy addresses used by your browser, command-line environment variables, and other apps. The controller API port can’t be used as an HTTP proxy port: pointing an app at 9090 won’t make it proxy traffic, even if that port is listening.

Check runtimes, permissions, and TUN services separately

If the UI exits before the core starts, check WebView2 and system events

The Windows version of Clash Verge Rev uses WebView2 for its UI. If the window is blank or the app exits while creating it, and the logs or event records point to WebView2, check Microsoft Edge WebView2 Runtime under Windows Settings → Apps → Installed apps. Repair or install it using Microsoft’s official installer and the current client release notes, then restart the app.

Only investigate Microsoft Visual C++ 2015–2022 Redistributable if the error explicitly reports missing files such as VCRUNTIME140.dll or MSVCP140.dll. Choose the installer that matches the faulting program’s architecture. Don’t copy individual files from DLL download sites or assume every crash is caused by the same runtime.

If normal startup works but enabling TUN fails, check the service layer

TUN mode involves a virtual network adapter, routing, and elevated permissions; it’s separate from the system proxy setting. If the UI and core work normally with TUN disabled, focus on the client service, virtual adapter initialization, and route conflicts with other VPNs—not on clearing subscriptions.

1. Turn off TUN and confirm that a connection works in normal proxy mode.
2. Check the service mode status in the client’s Settings and use the install or repair option provided by your current version.
3. Temporarily quit other VPNs or virtual adapter tools, while keeping any required corporate networking software configured.
4. Enable TUN again and check the first service or core error from that failed attempt.

Verify the fix and record details if the issue returns

Getting the window to open is only the first step. After a fix, verify the core, listening ports, restored configuration, and network state after quitting. Change one thing at a time to identify whether the cause was a subscription, override, port, or service.

• Cold start: Quit normally and reopen the app. Confirm the window and tray state match, and check the logs for repeated startup errors.
• Config loading: Confirm that your subscription, policy groups, and rules have loaded; don’t stop at the initial empty config.
• Listeners and requests: Check the actual proxy port, then review connection logs to confirm the destination, rule, and policy group are as expected.
• Test TUN separately: Enable it only if needed, then check connectivity and DNS behavior in relevant apps. A working system proxy doesn’t mean TUN has been verified.
• Restore on exit: After quitting, confirm the system proxy no longer points to a local port that’s no longer listening.

If the issue returns, gather the full client version, core version, OS version, installation method, reproduction steps, and redacted logs. State whether it happens with a fresh data directory, with TUN disabled, and who owns the listening port. These details are far more useful than simply saying “it crashes on launch.” For installation and setup, see the user guide; for terminology, see the glossary.