Clash Verge Rev: names reset to auto

Project report #8365 describes names changing to auto after subscription updates in v2.5.9+autobuild.1020.9dd5aa6 on macOS. Maintainers linked it to the remote-name refresh change in #8360. This is not evidence that every platform or stable release is affected.

The request in #8348 was the opposite: a v2.5.8 user wanted a refresh to pick up the server's new name. These reports describe different version behaviours. The latter does not establish that v2.5.8 overwrites manual names in the same way.

The affected commit writes a newly obtained remote name back to the existing profile on refresh. The reviewed implementation consults content-disposition. Without that response header, it can use the last segment of the subscription URL after removing query parameters, producing auto or main.

This display name is not a policy-group or node name. Editing the card label does not change the subscription URL or establish that node credentials changed. A refresh still downloads configuration content, so check the active profile and actual requests separately.

Record the complete in-app version, rather than only v2.5.9, and distinguish autobuilds from stable releases. This guide covers the reported build and pinned commit. For later builds, check release notes and their actual refresh behaviour.

Upstream subsequently reverted this name-writeback change in #8366, with pinned revert commit 27d8a71. A source revert does not automatically repair an installed package. The latest stable release checked for this guide remains v2.5.8; this does not establish that all preview builds include the correction.

Record the card's original name, subscription source, selection and automatic-update switch. A subscription URL often contains credentials; keep it locally. Redact credentials in paths and query parameters from screenshots or reports, and do not put the complete address in a name.

For an independent backup, open Settings → Verge Advanced Setting → Backup Setting and create a local backup. Open View history, use Export Backup on its record, save it elsewhere and confirm that the file is readable. Creating a backup inside the application's data directory alone is not an export.

Pausing automatic updates reduces opportunities for the next overwrite; it does not repair the naming logic. Clicking Update manually still fetches the remote configuration and may change the name again. Pausing also prevents automatic receipt of the provider's new nodes, so restore the original update plan once the problem is resolved.

If someone else operates the subscription, explain that the affected build uses a remote name during refresh and ask whether the response supplies a recognisable content-disposition. Share the redacted symptom and version rather than posting a complete subscription address in a public issue.

If you operate the subscription service, supply an appropriate filename in the HTTP response headers that deliver the subscription, rather than inside its YAML. The example shows the header's location and form. Configure an existing backend according to its own documentation.

After changing it, inspect the name the client actually receives and confirm that it still updates the same subscription. Filename parsing and sanitisation can affect the result. A name entered somewhere on the server is not proof that the client received it. Do not casually replace a credential-bearing URL just to change the label.

Record the state and pause transfers that cannot be interrupted before a manual-refresh comparison: updating a subscription may reload the active configuration. Keep the before-and-after names, version, time and actual content. A name surviving a restart alone does not prove that refresh overwrites have been fixed.

To undo the name and switch changes, restore the recorded values and retain the original subscription and working configuration. If repeated overwrites make cards hard to identify, use the short-term manual approach above while waiting for clear upstream guidance. Repeated deletion and reimporting are not a reliable recovery method.

Before changing application versions, retain the current data and an independently exported backup, then verify the target version at the project's official releases. Cross-version data compatibility has not been tested here. Do not let another version overwrite your only data directory or assume that a downgrade will solve the problem.

Restoring a complete backup overwrites application data and triggers a restart, so it should not be the first response to a changed display name. If restoration is necessary, separately save the current state, check the backup's source and compatible version, and follow the application's recovery flow before verifying every profile and selection.

Report the full application version, operating system, whether you renamed the profile manually, automatic-update state, names before and after, and redacted response-header details. Verify subsequent corrections against specific commits and release records. An issue being closed does not prove that the installed build contains a fix.