Clash Crashes on Startup: Check Logs, Roll Back Config, and Reinstall

1. First, determine whether the window or the proxy core is closing

A disappearing window does not always mean the app has crashed. Clash clients typically have two components: a graphical interface for buttons, config lists, and settings, and a proxy core that handles connections and applies rules. mihomo, also known as Clash Meta, is the proxy core used by some clients. Either component can fail independently, so identify which one is affected before troubleshooting.

1. Check whether the client icon is still in the system tray. On Windows, it may be hidden in the taskbar's overflow area. If the icon is still there, reopen the main window from the tray and check whether the app is set to minimize on startup.
2. Press Ctrl + Shift + Esc to open Task Manager, then check the client and core processes under Details. Note their process names; don't rely on the icon alone.
3. If the window opens but reports that the core isn't running, start with the core logs. If the GUI process also disappears immediately, check the client logs and system crash records first.
4. Exit any other proxy clients, then launch the affected client again. Running two at once can cause conflicts over local ports or virtual network adapters.

2. Find the logs and capture the first error after launch

Log locations vary by client; “Clash” is a general name, not a path.The installation folder, user data folder, and core working directory may all be different. Don't assume your logs are in a folder just because you found that path online.

If the window stays open for a few seconds

Use the client's Open Logs Folder or Open Config Folder option, if available; names and menu locations vary. Copy the entire log folder and note the launch time, such as 9:42:10 AM. Restart the client once, then check for new log entries after that time instead of repeatedly reading an old error.

If the window won't open at all

• Legacy Clash for Windows:A common data location is %USERPROFILE%\.config\clash. Check whether it contains logs. For portable installs or relocated folders, use the actual file modification times as a guide. Don't assume this path applies to other clients.
• Other Windows clients:Enter %APPDATA% and %LOCALAPPDATA% separately in File Explorer's address bar, then look for folders named after the client or project. Inspect and back them up for now; don't delete anything.
• Windows system records:Press Win + R, enter eventvwr.msc, then go to Windows Logs → Application and look for errors around the time of launch. You can also run perfmon /rel and check for application failures in Reliability Monitor.
• macOS:Open Console and check the crash reports; user-level reports are often in ~/Library/Logs/DiagnosticReports. If only the core exits, look for the client's own core logs first.
• Linux:Launch the actual client executable from a terminal and save the output. If you use a systemd user service, check that service's logs too. Don't assume every distribution uses the same service name.

Look for the first error that stops startup, then review the 20 lines before and after it. A final “connection refused” message may simply mean the core has already exited. Even if the faulting module points to a graphics runtime, that alone doesn't prove the graphics driver is at fault; check the client logs too.

3. Port conflicts: find what's using ports 7890 and 9090

A port conflict usually prevents the core from starting, but doesn't necessarily crash the entire interface.7890 is often used for the local proxy, and 9090 for the controller API, but both can be changed. Check the logs and active config; if the error mentions port 7897, check 7897.

Run the command below in Windows PowerShell to see which process is listening on the example TCP port. No output only means there was no matching listener at the time of the query; the process may have just exited.

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

If the output shows process ID 4321, look up the process details next. 4321 is an example; use the ID returned by your query.

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

1. If another proxy app is using the port, exit it normally from its system tray menu. Don't terminate an unknown system process.
2. If the port is held by a leftover core from the same client, exit the client and its background service first. Make sure no connections are using it before handling the remaining process.
3. If you need to run both apps, change one to an unused proxy port such as 7893 and an unused controller port such as 9093. Update any apps where you've entered the proxy address manually; changing the config alone leaves them pointing to the old port.

If no process is listening but Windows reports that access to the port is denied, run netsh interface ipv4 show excludedportrange protocol=tcp to check excluded TCP port ranges. Don't remove system-reserved ranges; choose an unused port outside them instead. For UDP bind errors, check UDP endpoints separately—TCP results aren't enough to diagnose them.

4. Roll back the config: test the YAML, then check client merge layers

Restore a known-good config instead of deleting fields at random.YAML uses indentation to define structure. Tabs, values with the wrong data type, or references to nonexistent proxy groups can all prevent a config from loading. A successful subscription download doesn't guarantee the contents are compatible with your core.

Narrow it down based on the most recent change

• Edited the config manually? Save a copy of the broken file, then restore the backup from before the change.
• Updated a subscription? Keep a copy of the updated file. If the client has saved snapshots, first restore one that was working before. Subscription contents can also change on the provider's end.
• Changed cores? Check whether the config uses fields or protocols supported only by the newer core. Classic Clash and mihomo support different features; the fact that both use YAML doesn't make them interchangeable.
• Enabled an override or script? An override adds to or replaces fields in the original config. Temporarily disable the new merge layer and test the original config.

Test the config with the current core

mihomo uses -t to test a config and exit, -f to specify a config file, and -d to specify a working directory. The example below assumes you've placed the core bundled with your current client and the config to test in D:\ClashRecovery, named mihomo.exe and candidate.yaml. Adjust the paths if yours differ.

Set-Location 'D:\ClashRecovery'
.\mihomo.exe -t -d 'D:\ClashRecovery' -f 'D:\ClashRecovery\candidate.yaml'

The working directory may also need geodata or rule resources. If the error reports missing resources, first add resources compatible with the config; don't assume it's an indentation problem. A successful test only means this core can load the config. It doesn't guarantee that nodes will connect, remote rules will download, or the GUI will work properly.

5. Missing core files, architecture mismatches, and runtime errors

Only troubleshoot program files when the logs explicitly report a missing file or load failure.“Core not running” can also be caused by a config error; it doesn't necessarily mean the core file is missing. Check the full path in the error, then verify that the file exists, hasn't been moved, and that your account has permission to read and execute it.

Check the installer against your device architecture

On Windows, go to Settings → System → About to check your system type. On Linux, run uname -m. Choose an x64 or ARM64 installer based on your device and the client's supported platforms. Don't rename and overwrite the core with one from another client; launch arguments, controller API, and bundled resources may differ.

Check security records and dependency errors

• On Windows, open Windows Security → Virus & threat protection → Protection history and check for a quarantine record for the file. Verify its source and the detection details first; don't disable protection globally just to get the app running.
• If the logs explicitly report that WebView2 or another runtime is missing, repair the dependency required by that client. Not every Clash client uses WebView2, so there's no need to install every runtime package.
• If macOS says the app can't be opened, first confirm that it's compatible with your macOS version, then read the specific message under System Settings → Privacy & Security. Don't copy commands that disable system security protections.
• If Linux reports a permission error, check the target file's permissions with ls -l. Only change permissions according to the project's installation instructions after confirming the file's source and path.

If the client starts normally until you enable TUN, check the virtual network adapter, service installation, and permissions. Temporarily turn off TUN to compare. Running the app as administrator at all times is not a universal fix for crashes.

6. Reinstall safely: verify the app and user data separately

Back up your data before reinstalling, and don't restore everything at once.Reinstalling over the existing files may leave faulty user settings in place; deleting the entire data folder could erase local rules and subscription records. Back up the data, set it aside, and restore items one at a time.

1. Record the current state:Note the client name and version, core version, OS version, last successful launch time, and any recent updates or config changes.
2. Back up your data:Once the app and related services have fully exited, copy your config, subscription records, local rules, override scripts, and logs. Backups may contain credentials, so store them in a protected local folder.
3. Set the old folder aside:Find the actual user data folder and rename it to a dated backup, for example by adding -backup-20261015 to the original name. If the folder is still in use, stop the background process first; don't force-delete it.
4. Reinstall:Uninstall the app according to its documentation. If it uses a service, remove that service as described in the project instructions. Install a stable version that matches your device architecture; don't mix files from different projects.
5. Start with a clean profile:Confirm that the new instance uses a fresh data folder, then open it without restoring old subscriptions, scripts, or TUN settings. Some clients won't start the core until a config is selected; that's different from the GUI crashing.
6. Restore items one at a time:Import a known-good config first, then start the client and check the logs. Next, restore local rules, overrides, the system proxy, and TUN. Change one thing at a time to identify what triggers the problem.

If the client still crashes with a clean data folder, focus on OS compatibility, runtimes, installation integrity, or a client bug. If the clean profile works but the crash returns after restoring old data, keep the new folder and restore the old files in batches. Don't overwrite the entire new profile with the backup.

7. Verify the fix and gather details for support

Getting the window to stay open is only the first step; make sure the config and connection work too.Leave the client open for 2 minutes and check whether the core keeps restarting. Verify the selected config, proxy mode, and proxy group. Rule mode chooses connections based on rules, so one website connecting directly doesn't necessarily mean the proxy is broken.

• Make sure the listening port matches the proxy port entered in your apps, especially if you changed 7890 while troubleshooting.
• Open the connection list and visit a test domain with a clearly matching rule. Check which rule and proxy group it uses—not just the latency number.
• If you need TUN, enable it last and check DNS resolution, regular websites, and everyday apps. If something stops working, revert to the last verified state.
• Exit and relaunch the client normally. Check that the selected config and port settings persist, and that the same startup error doesn't reappear in the logs.

Keep the troubleshooting steps simple: identify what exits, then read the logs. If there's a port error, check the port; if there's a config error, roll back the config; if there's a file error, repair the installation. Keep a recoverable backup at each step—it's usually faster to find the actual cause than to reinstall repeatedly.