故障排查

Clash/Mihomo 重启后又选回默认节点？看懂 store-selected

手动选择的节点在重启或订阅更新后恢复默认，未必是节点故障。解释 store-selected、策略组类型、配置变化和运行实例之间的边界。

发布于 2026/8/26 · 更新于 2026/8/26 · 5 项可核验来源

先看重点`profile.store-selected: true` 只负责保存 Mihomo API 对策略组的选择，供同一内核下次启动时恢复。它不会改写订阅，也不会把 url-test、fallback 变成永久手动组。若仍恢复默认，应分清是手动 select 组、自动组在重新选择，还是更新后策略组或节点名称已经变化。

昨晚在“节点选择”里切到了日本，今天重启客户端，它又回到“自动选择”或列表第一项。网络还能用，只是每次都得重新点。这个现象很像客户端没记住设置，也可能是你看到的根本不是同一种策略组。

store-selected 保存的是内核运行时选择，不是订阅文件。 Mihomo 官方只承诺它把 API 对策略组的选择留给下次启动；策略组变了、节点不再属于该组，或者当前组本来会自动选路，都不能靠这个字段锁住。

面板点一下，实际改的是内核状态

Mihomo 的面板和图形客户端通常通过控制 API 读取策略组。官方 API 用 now 表示组内当前节点，用 all 列出当前可选成员；选择某个成员时，则向对应代理组提交新的名称。

这解释了一个常见误会：在面板里选中节点，不等于那行节点已经写回机场订阅。订阅仍由提供方维护，选择属于内核的运行状态。全局配置中的 profile.store-selected: true 才负责把这类 API 选择保存下来，供下次启动继续使用。

旁边的 store-fake-ip 是另一件事。它保存 fake-ip 映射，不能补救策略组选择，也不该因为节点恢复默认就一起清理 DNS 缓存。

先分清 select、url-test 和 fallback

官方的 select 是手动选择组，组内成员由 proxies 等字段提供。你在这类组中选择一个仍然存在的成员，才符合“下次继续用我选的节点”这个预期。

url-test 会按健康检查结果自动选择，fallback 会在当前节点不可用时按顺序回退。它们显示的 now 也会变化，但变化本身不等于缓存失效。官方 API 还为部分自动组提供 fixed 状态；清除固定状态后，组会重新按自己的自动逻辑工作。

因此，界面都叫“节点选择”，背后的类型可能完全不同：

当前策略组类型	节点变化更可能表示什么
`select`	手动选择未恢复，或原成员已不在当前组内
`url-test`	延迟检查后重新决定当前节点
`fallback`	原节点不可用，自动回退到可用成员

已有的自动选择与自动回退说明展开了两类自动组的切换逻辑。只想固定一个节点时，先确认自己操作的是 select，不要把自动组的正常变化当成“重启重置”。

为什么订阅更新会带走旧选择

如果普通重启能保留，只有订阅更新后会恢复，问题更可能出在新配置。机场可能重建策略组、修改组名、替换节点名，客户端也可能在更新时重新生成最终运行配置。

此时旧选择即使曾被保存，也必须在当前配置里找到对应对象才有意义。官方 API 返回的 all 是这个策略组此刻真正拥有的成员；原节点已经不在其中时，内核不可能继续把它当作该组的有效选择。看到相似地区名也不能当成同一个成员，例如“日本 01”和“日本-01”是两个不同名称。

不要为了保留选择直接修改下一次会被覆盖的订阅文件。客户端若支持覆写或合并配置，应把持久设置放在那一层；订阅更新后保留自定义配置说明了原始订阅与最终运行配置的区别。

你看到的可能是另一份运行配置

桌面客户端、系统服务和手动启动的 Mihomo 可以各自持有配置。面板重开后如果连接到了另一个控制地址，或者客户端切换了配置档案，你看到的就是另一组 now 与 all，不能用前一个实例的选择判断它是否成功恢复。

比反复点击更有用的是保留一次对照：记下策略组的精确名称、类型和所选节点；重启后再看同一组是否还存在、类型是否仍为 Selector、成员是否仍在 all 中。组和成员都没变，运行实例也相同，选择仍无法保留，才把范围收窄到 store-selected 是否进入最终配置，以及客户端是否保留了内核缓存。

这项配置只承诺“供下次启动使用”，没有承诺跨设备同步，也不会把所有 GUI 的本地设置合并成一份。清空应用数据、切换配置档案或更换内核实例后的具体行为，还要以对应客户端的实现为准。

记住名字不等于节点可用

持久化选择解决的是“记住哪个名字”，不是节点健康检查。节点仍在列表里却已经超时，select 组可以继续显示它；反过来，自动组为了可用性发生切换，也不该用强行持久化掩盖。

如果名称被保留但实际连不上，应回到连通性排查，区分测速失败和真实断网。如果名称在订阅更新后消失，则看为什么旧节点会被替换。两种问题都不是把 store-selected 重复写几遍就能解决。

本文没有对某个图形客户端的缓存目录、配置合并顺序或清理机制做实际测试。能从 Mihomo 官方文档确定的是：面板选择通过 API 改变运行状态，store-selected 为下一次启动保存这类选择；超出这层的同步与持久化，由具体客户端和当前配置共同决定。

资料来源

以下来源于 2026/8/26 复核。版本、支持平台和发布状态以后续官方页面为准。

持续更新

收到新教程，也欢迎纠错

想收到新文章，可以关注 TG 频道；发现下载失效、套餐变化或步骤不一致，请附上页面链接和可公开的截图。不要发送订阅链接、密码或完整账户信息。

关注 TG 频道 Telegram 纠错邮件纠错

读者互动

这篇内容对你有帮助吗？

— 次访问— 累计日独立访问— 条评论

直接说出你的问题