Connectivity Troubleshooting · Clash Technical Blog

Clash Verge Rev SSH key error: service fix

Does an SSH private-key file stop the Clash Verge Rev service core or TUN from starting? Check the first path error, app config directory and v2.5.10 fix; preserve your key and Profile, then verify the original node.

Read the articleBack to blog
  • Clash Verge Rev
  • SSH
  • private-key
  • Service mode
  • v2.5.10
On this page
Published
Estimated reading time
About 8 minutes

After you add an SSH private-key file to a configuration, enabling service mode or TUN may fail to start the core. Check the earliest file-path error first; a startup failure does not automatically mean insufficient permissions.

Why does the core fail after adding an SSH key file?

Official issue #8445 reports that TUN would not start on Windows 11 with Clash Verge Rev v2.5.8 after an SSH key file was configured. A relative path could not find the file, while an absolute path hit SAFE_PATHS restrictions. The later code 1006 only reports that the core was not ready.

The official v2.5.10 release includes a fix for SSH key files in service mode. This guide addresses handing that file to the service core. It does not promise to resolve every TUN failure or present one Windows report as testing on all three operating systems.

Use the first error to check whether this fix applies

What you observeWhat to check next
The configuration uses type: ssh and a file-based private-key, followed by a path or SAFE_PATHS errorCheck the file location and the application fix
Only code 1006 or an IPC-not-ready error appears, with no private-key errorKeep the earlier core logs and identify the underlying cause
The core starts, but SSH authentication or host-key verification failsCheck the SSH credentials, server and host key; this is a separate connection problem
The configuration does not use an SSH key fileInvestigate the actual service, network or configuration error

A different path base means an absolute path may still fail

Mihomo accepts either private-key contents or a file path. This guide covers file paths only. Do not work around a path error by pasting a complete private key into a subscription, public configuration or support screenshot.

The service core has its own runtime directory; it cannot be assumed to read files relative to the app directory directly. In v2.5.10, eligible local key files are staged in the service runtime directory, and the configuration sent to the service is rewritten. You do not need to add files there manually.

The fix has limits: the file must exist, and its resolved location must remain inside the directory containing the app's runtime configuration. Relative paths start from that directory. Absolute paths have the same boundary; the fix does not permit reading arbitrary files elsewhere on disk.

SSH entries in top-level proxies and in proxy-providers payload are handled. This does not guarantee recursive scanning of arbitrary nodes inside remote provider files. Inline keys, Windows UNC paths and device paths are also outside this ordinary local-file staging path.

Keep the original configuration and key, then check the file location

Save the current Profile, custom overrides and original proxy mode, including a recoverable copy outside the app. Preserve the original key file separately: a configuration ZIP does not necessarily contain external SSH files. Keep backups under your control and make a separate redacted copy for support.

Open Settings → Verge Advanced Setting → Open Conf Dir. This opens the app configuration directory, which also contains the runtime configuration file. Do not use the profiles subdirectory as the relative-path base or manually add files to the service runtime directory.

Inside the directory you opened, keep a copy of the trusted key in an ssh subdirectory with access restricted. In the Profile or persistent override you maintain, set private-key: 'ssh/id_ed25519', adjusting the filename to match. Leave the original key untouched so you can undo the change.

Confirm that the target is a regular file the app can read, not a symbolic link pointing outside the directory. Renaming an extension does not restore a missing file. Do not edit the generated runtime YAML directly, add the key to a public repository or remove its existing protection.

Record before updating

  • The full application version, operating system, and whether service mode and TUN are in use.
  • The directory containing the actual runtime configuration, the private-key value and file location. Redact usernames and sensitive paths before posting publicly.
  • The earliest file or safe-path error and the order of the subsequent core-startup errors.
  • The original configuration, original key file, and previously working node and traffic-capture settings.

Install v2.5.10 so the app can prepare the service files again

The fix is in Clash Verge Rev's code that prepares service runtime assets. Updating only Mihomo, refreshing a subscription or repeatedly toggling TUN cannot replace an application update. If a later stable release has documented evidence of the same fix, there is no need to downgrade to v2.5.10 for this guide.

Use the official v2.5.10 Release in the references, matching your operating system, processor architecture and existing installation method. This maintenance run does not replace the site's hosted installers; an older package being downloadable does not establish that it contains this fix.

Update using the existing installation method, then reopen

  1. Save your work and quit normally

    When you can interrupt networking, record the original settings and stop the current traffic capture using the app's supported controls, then quit fully from the tray. Keep the configuration and key; do not delete the data directory or replace internal service files manually.

  2. Complete the official application update

    Use the stable installer for your operating system and architecture, retaining the existing installation method. If installation or signature checks fail, resolve the specific error instead of disabling system security checks to continue.

  3. Reopen and verify the version actually running

    Confirm that the app is v2.5.10 or a later stable release with evidence of this fix, and that the original Profile and persistent overrides remain. Save path changes in the source configuration and activate it again, then inspect the SSH entry in the final configuration.

  4. Start the service core and TUN as originally required

    Keep the traffic-capture method you actually need and inspect the earliest logs after restarting. Avoid changing DNS, node credentials and several switches together, which would prevent a useful comparison.

After the core starts, verify traffic through the original SSH node

First confirm that the core is ready and no longer exits because of a key-path or SAFE_PATHS error. Select the SSH node you intended to use and make a new real request. On the client's Connections page, check that this request uses the expected SSH exit and that the actual task succeeds.

A running core does not establish successful SSH login. A latency value or an enabled TUN switch alone cannot prove authentication, host-key verification and real traffic all work. If authentication then fails, continue with the SSH server and credentials; do not remove host-key to bypass verification.

Verify the repair

  • The application version includes the service-mode key-file staging fix, and the final configuration uses the intended SSH entry.
  • The key file exists within the permitted app configuration directory and remains readable after restarting.
  • The service core becomes ready and no longer exits because of this file-path error.
  • A new connection uses the intended SSH node, the real request completes, and the original task works.
  • Restore the everyday mode, original selection and necessary traffic-capture settings, then check the result again.

We have not installed a real client or reproduced this issue on a device. This guide is based on official user reports, the stable release, fixed-version source code and SSH configuration documentation. Website translation, source-level and browser checks cannot replace an actual connection test on your device.

If it still fails, follow the first error and preserve file protection

The log says private key is unavailable below the config root

Recheck the runtime configuration's parent directory, file existence, resolved location and the app's read access. Files outside that directory, escaping symbolic links and remote paths are not guaranteed to be staged by this fix. Do not change SAFE_PATHS blindly.

The file error is gone, but code 1006 or another exit remains

Keep the new first core error and actual application version, then investigate that error. The final IPC error alone is not a reason to reinstall the system service.

The updated app or original configuration no longer works

Stop adding changes and save the current state. First restore a configuration and node you know work. If you need to roll back the app, follow the project's supported method with a matching backup; do not let old and new programs contend for the only data directory.

If you cannot update yet, restore a verified working non-SSH node or original configuration so you can resume work. This does not fix the old service-mode key-file problem. Do not allow whole-disk reads, grant write access to everyone or move keys into the service directory as a permanent workaround.

For support, provide the operating system, full app version, service mode, whether private-key contains a file path or key contents, redacted directory relationships and the first error. Do not upload private keys, passwords, subscription tokens or a complete configuration archive.

References