本文目录
刚给工作和日常订阅取好名字，刷新后卡片却都变成 auto，容易让人误以为配置被替换。先辨认变化的是卡片名称、订阅内容还是当前选中项，再核对完整应用版本，避免为了改名删除仍然可用的订阅。
刷新后只剩 auto，订阅真的丢了吗？
项目 #8365 报告了 v2.5.9+autobuild.1020.9dd5aa6 在更新订阅后把名称改成 auto 的情况，报告环境为 macOS。维护者把它与 #8360 的远程名称刷新改动联系起来；不能据此认定所有平台或正式版都受影响。
另一个 #8348 诉求恰好相反：v2.5.8 用户希望刷新订阅时同步服务端名称。两份报告代表不同版本行为，不能把后者当成 v2.5.8 也会覆盖手动名称的证据。
先区分需要处理的对象
| 看到的变化 | 先做什么 |
|---|---|
| 卡片改名，但原订阅地址、节点和选中状态仍对应原配置 | 按名称覆盖排查，不删除后重导。 |
| 节点、规则也变了，或当前选中了另一张卡片 | 检查实际更新内容和选中配置；改名不能修复这些差异。 |
| 名称没变，只是服务端已改名称没有同步 | 先记录所用版本；这与新自动构建覆盖手动名称不是同一种问题。 |
名称为什么会取到网址里的 auto？
受影响提交在远程订阅刷新时，把新取到的名称写回已有配置。核对的实现会参考响应的 content-disposition；没有这个响应头时，可从订阅 URL 去掉查询参数后的末段取得名称，因而出现 auto 或 main。
这里的显示名称不是策略组名或节点名。改卡片名称不等于修改订阅 URL，也不代表节点凭据被更换；但更新本身仍会获取配置内容，因此要另外核对选中配置与实际请求。
先在应用内记录完整版本，不能只看 v2.5.9 这一段或把自动构建当成正式发布。本文针对报告中的具体构建与固定提交；后续构建是否仍有同样行为，应核对其发布说明和实际刷新结果。
上游随后通过 #8366 撤回了这次名称写回改动，固定撤回提交为 27d8a71。源码撤回不等于你已安装的包自动获得修复；本次核对的最新正式版仍是 v2.5.8，不能据此把所有预览构建称为已修复。
先备份，再恢复卡片名称
先记录目标卡片的原名称、订阅来源、选中状态以及自动更新开关。订阅 URL 常含认证信息，只保留本地记录；截图或反馈中应隐藏路径里的凭据和查询参数，不把完整地址放进名称。
需要独立备份时，从“设置 → Verge 高级设置 → 备份设置”创建本地备份，再打开“查看记录”，使用记录行的“导出备份”保存到独立位置并确认文件可读。仅在应用数据目录里创建一份备份，不等于已经导出。
在目标订阅上做最小恢复
等待当前更新结束
先确认目标订阅不再刷新。关闭定时更新不会强制取消已经发出的请求，过早改名仍可能被这次更新覆盖。
进入编辑信息
在“订阅”页面右键目标卡片，选择“编辑信息”。在“编辑配置”窗口核对订阅 URL 与记录一致，只修改“名称”，不要误用“编辑文件”或删除卡片。
需要时暂关允许自动更新
若要在受影响构建中暂时保留这个名字，可关闭同一窗口的“允许自动更新”并保存，保留原间隔和开关记录。已在途更新结束后，再确认名称仍正确。
重启后确认配置身份
正常退出应用再打开，核对名称、目标卡片和选中状态，并测试原来使用的网页或应用。没有必要为了改显示名称清空配置、切换内核或修改 DNS。
暂关自动更新只是减少下一次覆盖，不是修复命名逻辑。手动点击“更新”仍会请求远程配置，名称仍可能再次改变；暂停期间也不会自动收到服务方的新节点，应在问题解决后恢复原更新安排。
怎样让服务端提供可识别的名称？
如果订阅由别人维护，可向服务方说明：受影响构建刷新时会使用远程名称，当前响应是否提供了可识别的 content-disposition？提供脱敏后的现象和版本即可，不把完整订阅地址发到公开 issue。
自己维护订阅服务时，应在返回订阅内容的 HTTP 响应头中提供合适的文件名，而不是把这个字段写进订阅 YAML。下面仅表示响应头的位置与形式；已有后端如何设置，应按它自己的文档操作。
content-disposition: attachment; filename="work-profile.yaml"修改后再检查客户端实际收到的名称，并确认更新的仍是同一份订阅。显示结果可能经过文件名解析与清理，不能仅凭服务端某处写过名称就断言客户端一定收到；不要为了改显示名擅自更换带认证信息的 URL。
用重启和下一次更新核对结果
核对这几项再决定是否保留设置
- 目标卡片的订阅来源、当前选中项、原名称和更新开关有独立记录。
- 保存并正常重启后，名称仍正确，实际使用的订阅与节点没有选错。
- 同一网页或应用的新请求能够完成；名称恢复与连接正常分别检查。
- 临时关闭自动更新时，界面状态与记录一致；手动更新后若再次改名，应明确记为临时办法仍有限制。
- 服务端名称或后续构建确认可用后，恢复原自动更新安排，再检查下一次更新和正常重启。
做手动刷新对照前先保留记录，并暂停不可中断的请求，因为订阅更新可能重载当前配置。记录更新前后名称、版本、时间和实际内容；不能只因一次重启后名字没变，就宣称刷新覆盖已经修好。
仍被覆盖时，保留配置再处理版本
撤销本次名称和开关修改时，按记录恢复原值，保留原订阅和可用配置。若持续覆盖影响识别，可先采用上述短期手动辨认办法，并等待维护方提供明确处理；不要反复删除、重导来碰运气。
需要更换应用版本时，先保留当前数据与独立导出备份，从项目正式发布来源核对目标版本。本文没有验证跨版本数据兼容性，不能让另一版本直接覆盖唯一的数据目录，也不承诺降级一定解决。
整份备份恢复会覆盖应用数据并触发重启，不适合作为单纯改显示名称的第一步。确实需要恢复时，先另存当前状态，核对备份来源与适用版本，再按应用恢复流程验证所有订阅和选择。
反馈时提供完整应用版本、操作系统、是否手动更名、自动更新状态、更新前后名称及脱敏后的响应头情况。后续修复应以明确提交和发布记录为准；issue 被关闭本身不能证明已安装版本包含修复。