Mihomo自动回退为何仍选第一项：候选顺序、可用状态与固定选择
用甲乙丙四轮状态解释fallback优先次序，核对有效候选、测试地址、固定选择与全不可用兜底，避免把备用顺序当成测速排名。
把策略组设成自动回退后，后面的候选看起来状态不错，当前选择却仍留在第一项，这通常需要先读顺序。Mihomo的fallback组处理的是“按既定次序寻找可用候选”。如果期望是主用正常就继续主用、主用不可用再用备用，这个次序正是需要维护的内容。先明确希望保留哪一项，再判断实际选择是否符合计划。
本题先固定三个条件
下文限定为当前Mihomo的fallback类型；有效候选列表只包含甲、乙、丙，排列依次如此；没有通过面板或API手动固定某个候选。健康检查状态已经更新，例题中的“可用”指相应测试地址下的检查状态。把这些条件写在前面，后面的选择才能在同一个问题里比较。
桌面客户端标题里有Clash，并不足以说明它使用哪一支内核或版本。先在其现有版本信息里确认核心，再查对应维护者说明。打开的组也应确实是fallback，不能把手动选择组的当前项目，或者包在外层的另一个组，误认为这组三项自动回退的结果。
四轮演算：改变状态，不改变顺序
第一轮，甲、乙、丙都可用。从列表起点检查，甲已经满足条件，就选甲。这里无需把三项重新排名，也不需要把其余两项删掉；它们的作用是在前面项目不可用时继续承接选择。
第二轮，甲已被检查为不可用，乙与丙仍可用。跳过甲之后，遇到的第一项是乙，本轮选择就是乙。若看到乙而没有选丙，先不把它解释成丙失效：在本例中丙同样可用，只是排在乙之后。
第三轮，甲和乙都不可用，仅丙可用，才继续到丙。第四轮，甲恢复可用，其他项目也可用，在本题没有固定选择、并且状态已经更新的条件下，重新按有效次序判断时又会遇到甲。若业务希望长期优先乙，那应该复核优先次序，而不是反复期待自动回退读出没有写下来的偏好。
把“备用顺序”写成能说明用途的清单
维护者可以先在纸面写：“甲为日常优先项，乙为第一备用，丙为第二备用。”下一列再写这一次有效列表中的真实显示名，避免多个相似名称看错。例题采用甲乙丙，只是为了把选择算法与真实地址、账号和服务信息分开；它不是要求给现有条目强制重命名。
若决定调整顺序，先确认当前完整配置的保存层。有些客户端使用远程完整配置，有些在本地合并生成输出。改了生成后的缓存文件，下一次更新可能重新生成。应由有权维护配置的人在对应的长期保存位置调整，并预先保留原次序，而不是只在屏幕里拖了一下就认定所有后续更新都已采用新优先级。
阅读简单局部配置时，可以把proxies下的三项看成一个按先后排列的候选清单。但本题没有给出任何代理定义或连接参数，不构成可运行配置。对正在使用的配置，先核对现成条目与组引用，不为了跟着教程操作而加入不认识的服务。
为什么配置里的次序和眼前列表可能不同
有效候选不一定只来自手写的proxies。策略组可以引用代理集合，还可能启用全部引入或筛选字段。Mihomo通用文档说明，部分全部引入字段会按名称排序。因此，查看者想象中的“原订阅第一项”，未必就是当前组完成引入与筛选后的第一项。
先查看当前组实际得到哪些候选，再核对这些候选如何进入组。若组里还有另一个策略组，其内部又有自己的选择过程，分析就多了一层，不能直接套甲乙丙都是单个候选的四轮表。把外层组与内层当前项分别写清楚，就能避免一边说“选甲”，另一边实际看到的是甲组里面的乙节点。
面板也可能把候选按显示习惯重新排列。定位时要能说明用于选择的有效顺序，而不是只凭某一列的视觉位置作结论。必要时交给维护者查看该核心提供的当前组信息，并保留实际组名与版本。没有这份顺序信息时，先把结论写成“尚未确认”，不要凭名称字母顺序替它补答案。
“可用”取决于怎样检查
健康检查对应一个测试地址。配置若指定expected-status，还要求响应状态符合该条件；维护者文档列出了单个状态码以及组合、范围的写法。只看某个网页平时能否打开，不能替代当前组的检查条件。例如维护者预期的测试结果是204，测试端点却改变了响应，应该先核对端点约定与实际状态，不能立刻认定所有候选同时坏了。
同样，不应为了让界面全部变绿，把期望条件随意放宽。先确认测试地址本来应该提供什么响应、当前检查采用什么标准，再决定是否需要维护配置。通过一条健康检查，描述的是该测试条件下的可用状态；日常任务还可能涉及别的服务、协议或权限，需要另外观察其结果。
通用文档还区分组内直接列出的代理与通过集合引入的代理，组里的测试地址并不自动负责所有集合成员的健康检查。看到集合成员的状态时间较旧时，应回到集合自身的检查安排确认。本文的四轮表故意先给定已更新状态，避免用没有发生过的检查结果解释选择。
手动固定与“全都不可用”需要单独看
当前维护者源码包含固定选择状态。通过相关接口固定一个可用候选后，选择过程可能先保留它，不能再用“第一项已恢复就一定立即回第一项”的简化说法。先确认是否存在手动固定，再由熟悉该客户端的人按原使用计划处理。不同外壳怎样呈现或撤回固定状态，应看各自说明，不编造一个通用按钮名称。
若三项全部不可用，当前源码仍有返回首项的兜底路径。于是面板上还显示甲，并不证明甲刚通过检查，也不保证这次连接能成功。另一个容易混淆的字段是empty-fallback，它处理的是组为空时的回退对象；“列表有三项但全不可用”和“列表根本为空”是两种输入条件。
带着具体结果继续查下一层
一份有用的说明可以写：“核心版本已确认，当前组为fallback；有效次序甲乙丙；未发现手动固定；相应测试状态为甲不可用、乙丙可用；当前选择乙。”这已经能回答本题。若客户端连启动都失败，出现监听冲突，可转看本站本地端口与进程归属核对；那是进入本题前的运行条件。
如果当前选择与优先次序相符，具体任务仍异常，应按其错误继续分析。本站教程与排查目录可按现象查找后续说明。本文例题根据当前维护者文档与fallback源码自行编写，没有连接测试、实测延迟或真实故障切换记录；已有连接是否续用也不由这张选择表保证。先把当前选择解释清楚，再按实际任务检查访问结果，处理范围会更准确。