本文目录
要确认选中了哪个出口，名称和延迟数字都不够。同名节点可能来自不同的集合，界面能点选后，也要用新请求查看实际出口。保留当前配置，按来源核对组成员，才能判断升级是否解决了自己遇到的选择问题。
节点变灰并显示 ambiguous，是订阅坏了吗？
在 Clash Verge Rev 节点页记录 ambiguous 提示、变灰无法选择的条目，或测速对应另一来源的节点。随后核对这些节点是否由多个代理集合提供，并且名称相同。
2026 年 10 月 9 日发布的官方 v2.5.8 明确修复这两类问题。issue #8021 有旧版用户报告：节点不能点选，但原有连接仍可用。报告不代表所有灰色节点都属于此问题，也不能据此断言所有旧版本和平台都受影响。
对应线索是运行配置含多个 proxy-providers、不同来源节点重名，并出现界面或测速差异。若集合未加载、节点本身不可用或配置解析失败，应先处理对应错误，不把它们统称为 ambiguous。
核对 Provider 范围并导出独立备份
记录完整客户端版本、系统、当前 Profile、异常组和重名节点。对照订阅原文与运行配置：proxy-providers 下的集合名称、各集合的节点名称，以及异常组的 use 列表。集合键名重名属于另一种配置错误，不能靠升级修正。
同时检查 include-all-providers、include-all 和 exclude-type。固定版本实现中，前两项会纳入所有集合，不能声称只写 use 就能隔离来源；排除类型也会改变候选节点。没有这些条件时，再按组自己的集合范围比较。
先确认集合已加载、确有同名节点，再分别测试该节点与策略组，用同一可信测试地址记录结果。通过原选择发起一个新的 HTTPS 请求，查看连接记录是否经过预期组和出口；浏览器绕过代理的成功不算对照。
在设置的 Verge 高级设置中进入备份设置，手动备份选择本地备份并创建记录，再从查看记录导出这份升级前备份，存到应用数据目录之外。界面翻译可能不同；仅创建本地记录，不等于已得到独立的离线副本。
官方备份实现包含 profiles 里的普通文件和应用配置，但不是整个数据目录的镜像。外部 Provider 文件和其他自管资源应另存安全副本；订阅令牌、密码和原始备份只留在自己的设备上，不作为公开报错附件。
不要因为界面异常就删除仍在工作的订阅。
升级 v2.5.8 后，怎样确认选择和测速恢复？
v2.5.8 会按策略组实际使用的 Provider 查找节点，避免把其他集合的同名节点误当成本组成员。它调整的是客户端对组成员与来源的对应关系；同一组里的两个完全同名出口能否分别选中，仍要用真实连接确认，不能只看显示恢复。
从文末官方 Release 获取适合系统与架构的 v2.5.8，按项目正常升级方式操作，保留配置和已导出的备份。本站已有客户端备份与上游最新版本是不同记录；不能用本站旧备份版本代替这次修复版本核验。
在原配置上验证修复
确认真正运行的版本
升级并正常启动后，在应用内核对完整版本为 v2.5.8；不要只凭安装文件名判断。保持同一 Profile 和原代理模式。
检查组成员并主动切换
重新应用配置，等待集合加载结束，打开原异常组。确认原 ambiguous 条目恢复可用，成员与本组的 Provider 范围相符；点选目标有效节点，等待切换结束并核对当前选择。
分别测试节点和组
用原测试地址分别测相关节点和组，等本轮结束再比较。一个延迟数字只是探测结果，不能证明真实业务已走到对应来源。
用新连接验证并重启复查
关闭旧测试连接后发起新的 HTTPS 请求，查看请求依次经过的策略组和实际出口；已有可验证的出口信息时一并对照。正常退出重启，再核对节点、选择和新请求。
若同一组仍包含来自多个集合的完全同名节点，界面可点选也不能证明能独立切到第二个出口。v2.5.8 的选择调用仍传组名和节点名；证据不足时记为未确认，不用重复测速或已有长连接推断切换成功。
若升级后集合仍为空或报下载、解析错误，先保留首条错误并排查集合来源。若成员和选择已正确但新请求失败，再检查节点连通性、规则与测试目标，不继续把所有失败归因于客户端映射。
同一组必须区分同名出口时，怎样保留原配置？
升级已恢复所需选择时，不必再改节点名。确需在同一组区分两个重名出口时，可在自己管理的本地配置副本中，为对应集合分别设置 override.additional-prefix，例如 A- 与 B-；这是 Mihomo 官方支持的来源前缀，不是修改远程订阅服务。
把 additional-prefix 合并进该集合原有的 override，保留其中其他字段。配置里的显式 proxies 引用、名称过滤、脚本和保存的选择可能仍指向旧名称，需要同步核对；不要直接覆盖整份 override 或把 A-、B- 当成所有订阅都适用的固定值。
通过正常导入入口添加带不同名称的本地副本，保留原 Profile。先检查语法、节点、规则与所需定制，再短时切换验证新名称和真实出口。无法判断运行配置或脚本的影响时停止改名，保留脱敏证据交给上游。
失败时切回原可用 Profile，并还原本次确实改变的应用设置。副本中的前缀不会自动迁移到其他订阅；订阅更新后的运行配置也要重新核对，不能把一次测试通过当成永久保证。
失败后如何恢复，并提供可复查的反馈？
若配置损坏需要恢复，先保留当前数据，再在备份记录中导入升级前导出的文件，选择对应记录执行恢复备份；导入本身只加入记录，不会自动应用。恢复后重新检查订阅、规则、代理模式和真实请求。
回退应用版本前核对备份兼容性和官方安全公告。不要照抄 issue 中回到 v2.5.2 的用户建议，尤其 Windows 服务：相关安全公告有明确受影响版本与修复构建。新版本生成的备份也不能假定旧版能读取；优先恢复已验证可用的配置。
没有可用配置时正常停止代理接管，检查普通网络；必须经代理访问的业务暂缓使用。不要清空全部数据或关闭安全软件来试错，也不要以其他来源的安装包绕过官方升级。
仍异常时向上游提供完整版本、系统、脱敏后的集合和组范围、同名关系、单测与组测、新连接链路及退出重启结果。用一致的占位名保留结构，遮盖订阅凭据、个人地址和 secret，并说明自己观察到的差异，不把未验证的出口选择写成修复成功。