使用 Clash Verge、Clash Verge Rev、Mihomo Party、OpenClash 等客户端时，很多用户会遇到这些问题：
主节点失效以后为什么没有自动切换？
Clash怎么设置备用节点？
Fallback是什么意思？
URL-Test和Fallback有什么区别？
自动选择为什么总是切到其他节点？
节点Timeout以后怎么自动换下一个？
如果你的目标是：
优先使用香港01。
香港01失效以后切香港02。
香港02失效再切日本01。
节点恢复以后重新按优先级使用。
那么需要重点了解的是：
Fallback代理组。
最快的配置思路是：
建立一个 type: fallback 的代理组。
把节点按照希望使用的优先级从上到下排列。
配置健康检查url。
设置合理的interval。
然后让需要代理的规则指向这个Fallback组。
Fallback和URL-Test最大的区别是：
Fallback优先考虑节点顺序和可用性。
URL-Test主要根据测速结果选择延迟更低的节点。
所以想要“主节点失效以后自动切备用节点”，通常优先考虑Fallback，而不是单纯URL-Test。
下面详细说明。
一、Clash里的Fallback是什么意思？
Fallback可以理解成：
自动回退。
它是一种代理组类型。
配置中通常写成：
type: fallback
这个代理组会对成员节点进行健康检查。
当当前节点出现超时或不可用时，会按照配置中的代理顺序寻找第一个可用节点。
例如：
香港01
香港02
日本01
美国01
如果香港01正常：
优先使用香港01。
如果香港01不可用：
回退到香港02。
如果香港01和香港02都不可用：
继续使用日本01。
这就是Fallback最典型的用途。
二、Fallback适合什么场景？
特别适合：
有固定主节点。
希望备用节点自动接管。
不希望单纯按照最低延迟乱切节点。
办公软件需要稳定IP。
长期访问同一地区服务。
自己维护多个备用线路。
例如你希望：
平时始终使用美国01。
只有美国01失效才用美国02。
那Fallback就比URL-Test更合适。
三、最简单的Fallback配置是什么？
一个基础示例可以写成：
proxy-groups:
- name: 自动回退
type: fallback
proxies:- 香港01
- 香港02
- 日本01
- 美国01
url: https://www.gstatic.com/generate_204
interval: 300
这里最重要的是：
type: fallback
以及：
proxies的顺序。
排在越前面的节点，优先级越高。
四、节点顺序重要吗？
非常重要。
Fallback和URL-Test最大的差别之一就在这里。
例如：
proxies:
- 香港01
- 香港02
- 日本01
意味着优先顺序是：
香港01
→ 香港02
→ 日本01
并不是哪个延迟最低就一定用哪个。
如果香港01可用，即使：
香港01延迟120ms。
香港02延迟60ms。
Fallback仍然可能继续优先使用香港01。
因为：
它的核心逻辑是可用性和顺序。
五、URL-Test是什么意思？
URL-Test也是一种自动代理组。
例如：
type: url-test
它会测试多个节点访问指定URL的延迟。
然后倾向于选择：
延迟表现更好的节点。
所以URL-Test更适合：
自动选低延迟节点。
例如：
香港01 68ms
香港02 92ms
日本01 130ms
URL-Test通常更倾向于：
香港01。
六、Fallback和URL-Test有什么区别？
可以简单理解：
Fallback：
主节点优先。
主节点挂了再换备用节点。
URL-Test：
根据测速结果自动选择更优节点。
如果你的需求是：
节点A必须优先。
只有节点A失效才用节点B。
应该优先：
Fallback。
如果你的需求是：
哪个延迟低就自动用哪个。
应该优先：
URL-Test。
七、Fallback会一直选择延迟最低的节点吗？
不会。
这是很多用户最容易搞错的一点。
Fallback并不是：
最低延迟选择器。
它首先关注的是：
节点是否可用。
以及：
节点在代理组里的排列顺序。
所以不要因为备用节点测速更低，就认为Fallback一定会切过去。
八、主节点恢复以后会切回来吗？
通常Fallback会根据后续健康检查重新判断节点可用状态。
如果前面优先级更高的节点重新变为可用，代理组可以重新回到更靠前的可用节点。
具体切换时机和：
健康检查。
interval。
当前运行状态。
客户端实现。
有关。
所以不会每秒不停检测并立即切换。
九、interval是什么意思？
interval表示：
健康检查间隔。
单位通常是秒。
例如：
interval: 300
表示大约每300秒进行一次周期健康检查。
也就是：
5分钟。
如果设置：
interval: 60
就是：
约1分钟。
十、interval越小越好吗？
不是。
太小意味着：
频繁健康检查。
产生更多测试请求。
增加节点和客户端负担。
太大又会导致：
节点恢复以后不能很快被发现。
一般用户没有必要设置成：
1秒。
5秒。
10秒。
通常根据实际用途选择几十秒到几分钟级别更合理。
十一、Fallback是怎么判断节点可用的？
它会使用配置中的：
url
进行健康检查。
例如：
url: https://www.gstatic.com/generate_204
客户端会尝试通过节点访问这个测试地址。
根据结果判断节点是否：
alive。
如果测试失败或超时：
节点可能被判断为不可用。
十二、为什么Fallback需要url？
因为系统必须有一个标准来判断：
这个节点现在能不能正常访问网络。
如果没有测试目标，就无法有效判断：
主节点到底失效没有。
所以Fallback配置中通常会设置：
健康检查URL。
十三、测速URL选错会发生什么？
这是很常见的问题。
如果你配置的测试URL本身：
打不开。
响应异常。
被网络拦截。
服务器不稳定。
就可能导致：
正常节点也被判断成不可用。
最终表现为：
Fallback不停切换。
所有节点Test Failed。
自动回退异常。
所以测速URL应该使用：
稳定。
响应快。
适合连通性检测。
的地址。
十四、Fallback和之前的Test Failed有什么关系？
关系很大。
Fallback依赖健康检查判断节点可用性。
如果所有节点测试都：
Test Failed
Fallback自然无法正确判断哪个节点可以使用。
所以如果自动回退异常，同时看到：
Test Failed。
应该先解决：
健康检查问题。
而不是不停调整节点顺序。
十五、timeout是什么意思？
Mihomo代理组可以配置：
timeout
用于健康检查超时判断。
单位是：
毫秒。
如果节点没有在规定时间内完成健康检查：
可能被判断为测试失败。
如果timeout设置过低：
网络稍微波动就容易失败。
十六、timeout越大越好吗？
也不是。
如果设置得非常大：
真正失效的节点需要等待更久才能确认。
自动切换速度会变慢。
因此应该保持合理值。
不要为了避免Test Failed把timeout无限放大。
十七、max-failed-times是什么意思？
Mihomo代理组还支持：
max-failed-times。
它代表：
最大失败次数相关设置。
超过设定失败次数后，可以触发强制健康检查。
这属于更细的健康检查控制参数。
普通用户一般不需要频繁修改。
十八、lazy是什么意思？
lazy表示：
懒惰健康检查。
默认情况下，如果当前代理组没有被实际选择使用，可能不会持续进行健康测试。
这样可以减少：
不必要的测速请求。
资源消耗。
如果你发现：
某个没有使用的Fallback组很久不更新延迟。
不一定是故障。
可能和lazy有关。
十九、Fallback节点怎么排序？
应该按照你的实际优先级排序。
例如你需要：
香港主线路。
香港备用。
日本备用。
新加坡备用。
可以写：
香港01
香港02
日本01
新加坡01
不要单纯按照：
当前延迟。
排序。
因为Fallback本来就是为了：
稳定优先级。
二十、可以把不同地区节点放进Fallback吗？
可以。
例如：
香港01
日本01
新加坡01
美国01
技术上完全可以。
但是需要考虑：
出口IP国家会变化。
例如：
香港01失效以后切到日本01。
你的出口IP也会变成日本。
对于：
ChatGPT。
Google。
流媒体。
账号登录。
电商后台。
社交账号。
某些对IP地区敏感的服务。
可能产生不同影响。
二十一、想始终保持同一个国家怎么办？
建立地区专用Fallback组。
例如：
美国回退
只放：
美国01
美国02
美国03
美国04
这样即使自动切换：
出口国家仍然主要保持美国。
同理可以建立：
香港回退。
日本回退。
新加坡回退。
二十二、可以建立多个Fallback组吗？
可以。
例如：
香港自动回退
美国自动回退
日本自动回退
AI自动回退
流媒体自动回退
然后让不同规则指向不同策略组。
这比把所有节点全部塞进一个组更容易管理。
二十三、Fallback可以引用其他代理组吗？
代理组的proxies字段可以引用：
具体代理节点。
也可以引用其他代理组。
因此可以做更复杂的嵌套结构。
但是层级越复杂：
排障难度越高。
普通用户不建议一开始建立很多层代理组。
二十四、Fallback可以使用proxy-providers吗？
Mihomo代理组可以通过：
use
引入代理集合。
但需要注意：
通用代理组字段中的url健康检查，仅针对proxies字段时有对应行为说明。
通过provider引入节点时，还涉及：
proxy-provider自己的health-check。
所以使用订阅Provider时：
最好同时理解Provider健康检查。
二十五、Proxy Provider是什么？
Proxy Provider可以理解为：
单独管理的一组代理节点来源。
例如你的机场节点来自：
provider1。
配置可以让多个代理组重复使用这个Provider。
这样不用在每个代理组里重复写几十个节点。
二十六、Provider里的节点怎么做健康检查？
Proxy Provider本身可以配置：
health-check。
例如：
health-check:
enable: true
url: https://www.gstatic.com/generate_204
interval: 300
这样Provider会定期检测节点状态。
如果你使用复杂的：
Fallback + Proxy Provider
配置，这部分也需要检查。
二十七、为什么Fallback里面没有节点？
如果使用：
filter
筛选节点。
正则写错以后：
可能把所有节点过滤掉。
最终Fallback组变成：
空组。
这种问题在自动生成配置里很常见。
二十八、empty-fallback是什么？
Mihomo代理组提供：
empty-fallback
字段。
它的用途是：
当代理组为空时指定一个回退Proxy。
默认值通常为：
COMPATIBLE。
需要注意：
这里说的是“组为空”。
不是普通意义上的：
主节点Timeout以后切备用节点。
它和：
type: fallback
不是完全一回事。
二十九、empty-fallback能填写另一个策略组吗？
当前Mihomo官方文档说明：
empty-fallback只支持填写Proxy名称。
不能直接填写代理组名称。
所以不要把：
自动选择
香港回退
这种策略组名直接塞进去，认为一定可以工作。
三十、DNS里面也有fallback，是一回事吗？
不是。
这是非常容易混淆的地方。
Clash/Mihomo里至少可能看到两种：
fallback。
一种是：
代理组Fallback。
例如：
type: fallback。
用于节点自动回退。
另一种是：
DNS fallback。
用于备用DNS解析。
两者不是同一个功能。
三十一、DNS fallback能切换代理节点吗？
不能。
DNS fallback只是：
DNS解析相关配置。
它不会帮你：
香港01失效切香港02。
所以搜索：
Clash fallback
时，一定先判断自己问的是：
节点回退。
还是：
DNS备用解析。
三十二、Fallback和Load-Balance有什么区别？
Fallback主要是：
按顺序寻找可用节点。
Load-Balance主要用于：
在多个节点之间分配连接。
两者目的完全不同。
如果你只想：
主节点挂了再切备用。
不需要Load-Balance。
三十三、Fallback和Select有什么区别？
Select表示：
手动选择。
例如：
type: select。
你自己点击：
香港01。
客户端就使用：
香港01。
香港01挂了以后：
普通select并不等于自动帮你选择香港02。
Fallback则负责：
根据可用状态自动回退。
三十四、为什么Select节点挂了不会自动切？
因为：
select的设计目标就是：
用户手动指定。
它不会因为另一个节点延迟更低就随便切换。
所以想要自动切换：
应该建立Fallback或URL-Test等自动策略组。
三十五、Clash Verge界面里怎么设置Fallback？
如果订阅已经包含：
自动回退。
Fallback。
故障转移。
备用线路。
类似代理组：
可以直接在代理页面选择该策略组。
如果订阅本身没有：
Fallback组。
通常需要：
修改Mihomo配置。
使用Merge或覆写功能。
或者让订阅服务端生成对应策略组。
具体入口会根据Clash Verge版本有所不同。
三十六、为什么不建议直接修改机场原始配置？
因为：
订阅更新以后。
原始配置可能被重新下载。
你手工加入的：
Fallback。
节点顺序。
URL。
可能被覆盖。
所以如果客户端支持：
覆写。
Merge。
脚本。
订阅转换。
更适合通过这些方式维护长期自定义配置。
三十七、订阅更新后Fallback消失怎么办？
基本说明：
你修改的是订阅生成后的最终YAML。
更新订阅时服务器重新下发配置：
原来的手工修改被覆盖。
需要改成：
持久化覆写方式。
或者使用：
独立本地配置。
三十八、Fallback可以固定某个节点吗？
当前Mihomo的API中，Fallback和URL-Test都存在与固定选择有关的状态支持。
但在实际GUI中是否暴露对应功能：
取决于客户端前端实现。
如果你手动固定了某个自动策略组节点：
需要注意它可能影响原本的自动选择逻辑。
三十九、为什么Fallback一直停在备用节点不回来？
可能原因包括：
主节点健康检查仍然失败。
健康检查还没到下一周期。
测速URL访问异常。
主节点实际没有恢复。
当前节点被固定。
客户端状态没有刷新。
所以不要只看：
节点服务器似乎恢复了。
还应该看：
健康检查结果。
四十、为什么主节点能打开网页但Fallback认为不可用？
可能是：
主节点能打开你测试的网站。
但不能成功访问Fallback配置里的：
健康检查URL。
这和之前：
Test Failed但节点能上网
是同一类逻辑。
所以要检查：
健康检查地址。
四十一、Fallback切换会不会断开现有连接？
有可能。
当出口节点变化以后：
已有TCP连接。
WebSocket。
长连接。
下载任务。
登录会话。
可能需要重新建立。
所以Fallback并不意味着：
所有应用都能完全无感切换。
四十二、打游戏适合频繁Fallback吗？
不一定。
游戏连接通常对：
IP变化。
UDP连接。
会话状态。
较敏感。
节点切换以后可能出现：
掉线。
重新登录。
延迟变化。
Fallback主要解决：
可用性。
不代表无缝漫游。
四十三、ChatGPT适合Fallback吗？
可以使用。
但建议同一Fallback组尽量保持：
相近地区。
例如：
美国01。
美国02。
美国03。
避免：
美国失效以后突然切香港。
香港失效再切日本。
这样出口地区频繁变化。
四十四、流媒体适合Fallback吗？
可以。
但最好：
同地区回退。
例如Netflix美国线路：
美国Netflix01。
美国Netflix02。
美国Netflix03。
否则切到其他地区后：
片库。
地区识别。
解锁状态。
可能变化。
四十五、为什么Fallback会频繁跳节点？
常见原因：
健康检查URL不稳定。
节点线路抖动。
timeout太短。
interval太频繁。
本地网络丢包。
节点本身不稳定。
不要一看到频繁切换就立刻认为：
Fallback配置语法错了。
四十六、怎么判断是节点问题还是本地网络问题？
进行交叉测试。
例如：
家庭Wi-Fi频繁Fallback。
换手机热点以后稳定。
说明更应该检查：
家庭网络。
运营商。
Wi-Fi。
DNS。
如果两个网络下同一个节点都持续失败：
再重点检查节点本身。
四十七、Fallback可以解决节点Timeout吗？
Fallback不能修复：
发生Timeout的服务器。
但它可以在某个节点不可用以后：
自动选择下一个可用节点。
所以：
它解决的是“故障转移”。
不是“修复坏节点”。
四十八、所有节点都Timeout怎么办？
如果Fallback组里：
所有节点都不可用。
那也没有备用节点可以切换。
这时需要排查：
本地网络。
机场线路。
DNS。
协议兼容。
Mihomo内核。
服务器状态。
Fallback不是万能修复工具。
四十九、为什么Fallback所有节点都是Test Failed？
优先检查：
测试URL。
DNS。
网络连接。
Health Check。
timeout。
如果全部节点同时失败：
通常先排查共同因素。
不要先调整节点顺序。
五十、URL-Test和Fallback可以一起使用吗？
可以设计组合结构。
例如：
香港URL-Test。
日本URL-Test。
美国URL-Test。
再把这些策略组用于更高级的策略结构。
但是：
配置层级越多。
理解和排障难度越高。
普通用户只需要自动备用时：
一个简单Fallback组通常更容易维护。
五十一、我想“优先香港，香港都挂了再日本”怎么做？
推荐先分别建立地区组。
例如香港组只包含：
香港01。
香港02。
香港03。
然后再设置更高层策略。
但如果节点数量不多：
也可以直接按顺序写：
香港01。
香港02。
香港03。
日本01。
日本02。
Fallback会按照顺序判断可用节点。
五十二、我想“香港节点里自动选最快，香港全挂再日本”怎么办？
这种需求已经不是单一Fallback能最直观解决的。
可以组合：
URL-Test
和：
Fallback。
例如：
香港自动选择使用URL-Test。
日本自动选择使用URL-Test。
更高层再设计故障转移。
不过这种配置建议对YAML和代理组已经熟悉以后再做。
五十三、为什么自动切换以后IP没马上变化？
可能存在：
浏览器连接复用。
网站缓存。
已有TCP连接。
DNS缓存。
IP查询页面缓存。
所以切换节点以后：
重新打开新窗口。
刷新连接。
必要时重启目标应用。
再检查出口IP。
五十四、Fallback需要开启TUN吗？
不需要。
Fallback本身属于：
代理策略选择机制。
TUN属于：
流量接管机制。
即使不开TUN：
使用系统代理的应用一样可以使用Fallback代理组。
不要把：
代理组选择
和：
TUN
混为一谈。
五十五、Fallback需要开启系统代理吗？
取决于应用流量怎么进入Mihomo。
如果浏览器依赖：
系统代理。
那通常需要系统代理开启。
如果应用通过：
TUN
进入Mihomo。
则由TUN接管。
但Fallback本身并不要求：
必须系统代理。
五十六、Fallback配置错误会导致整个Profile加载失败吗？
会。
如果YAML结构错误。
缩进错误。
节点名称不存在。
代理组引用异常。
可能导致：
配置验证失败。
无法切换Profile。
所以修改之前最好：
备份原配置。
一次只改一部分。
五十七、节点名称需要完全一致吗？
需要。
例如配置里真实节点叫：
香港 01
你却在Fallback中写：
香港01
可能被视为：
不同名称。
最终出现引用失败。
所以proxies列表中的名称应与实际节点：
完全对应。
五十八、为什么出现Proxy Not Found？
通常说明：
代理组引用了不存在的代理。
例如：
Fallback里写了香港01。
但订阅更新以后节点改名成：
香港-01。
旧代理组仍然引用：
香港01。
就可能出现：
Proxy Not Found。
五十九、机场经常改节点名怎么办？
可以考虑：
Provider。
filter。
正则筛选。
等方式动态引入节点。
这样比写死：
几十个节点名称
更容易长期维护。
但正则配置错误也可能导致：
一个节点都筛不出来。
六十、filter是什么？
filter可以通过：
关键词。
正则表达式。
筛选满足条件的节点。
例如只筛选：
香港。
HK。
Hong Kong。
这样可以建立：
香港策略组。
节点名称变化不大的情况下很方便。
六十一、exclude-filter是什么？
exclude-filter作用相反：
排除符合条件的节点。
例如你想自动组里不要出现：
剩余流量。
套餐到期。
官网。
可以使用排除规则。
这对机场订阅自动分组非常有用。
六十二、exclude-type是什么？
exclude-type可以根据：
节点协议类型
排除某些代理。
它与：
按节点名称筛选
不是一回事。
普通用户没有明确需求时：
不需要随便配置。
六十三、Fallback最常见错误有哪些？
第一：
把Fallback当成最低延迟选择。
第二：
节点顺序写反。
第三：
健康检查URL不可用。
第四：
interval过短。
第五：
timeout过低。
第六：
引用不存在的节点。
第七：
订阅更新后自定义配置被覆盖。
第八：
把DNS fallback和代理组Fallback混淆。
第九：
所有节点都失败却期待Fallback还能自动修复。
第十：
同时运行多个代理客户端导致测试异常。
六十四、最推荐的简单配置思路
如果你只是普通Clash Verge用户：
不要一开始构建复杂多层策略。
可以先做：
一个Fallback代理组。
加入3到5个稳定节点。
按实际优先级排序。
配置稳定健康检查URL。
interval设置合理。
测试主节点失效时是否自动切换。
确认工作正常以后：
再考虑URL-Test。
地区筛选。
Proxy Provider。
复杂自动分组。
六十五、常见问题
Clash Verge回退节点怎么设置？
核心是建立type: fallback代理组，并按照优先顺序加入节点，再设置健康检查URL和interval。
Fallback会自动选择延迟最低节点吗？
不会。Fallback重点是节点可用性和排列顺序。
想自动选最低延迟应该用什么？
通常使用URL-Test。
Fallback和URL-Test哪个好？
没有绝对哪个好。需要主备故障切换用Fallback，需要自动低延迟选择用URL-Test。
主节点Timeout以后Fallback会切吗？
如果健康检查判断主节点不可用，会按照顺序寻找下一个可用节点。
为什么Fallback没有自动切换？
检查健康检查URL、节点状态、interval、timeout以及当前节点是否被固定。
为什么所有节点都Test Failed？
优先检查测速地址、本地网络、DNS和健康检查配置。
DNS fallback和节点Fallback一样吗？
不一样。DNS fallback用于DNS解析，type: fallback用于代理节点自动回退。
Fallback需要开启TUN吗？
不需要。Fallback与TUN属于不同功能。
订阅更新后Fallback配置没了怎么办？
说明手工修改可能被新订阅覆盖，应考虑客户端覆写、Merge或独立本地配置。
Fallback能修复坏节点吗？
不能。它只能在节点失效以后切换到其他可用节点。
六十六、总结
如果你的需求是：
主节点优先。
主节点失效自动切备用。
备用失效继续向后切换。
那么Clash/Mihomo里应该重点使用：
Fallback。
基础逻辑可以概括成：
type: fallback
→ 按优先级排列节点
→ 配置健康检查URL
→ 设置合理interval
→ 让规则使用这个策略组。
如果你的需求是：
哪个节点延迟最低就用哪个。
更适合：
URL-Test。
所以一定要先区分：
Fallback解决的是故障回退。
URL-Test解决的是自动测速选择。
另外需要特别注意：
代理组Fallback
和：
DNS fallback
不是同一个功能。
如果Fallback出现：
不自动切换。
频繁切换。
所有节点Test Failed。
一直停留在备用节点。
优先按照以下顺序排查：
检查节点实际能否使用
→ 检查健康检查URL
→ 查看Test Failed状态
→ 检查interval和timeout
→ 检查节点排序
→ 检查节点名称是否存在
→ 检查是否被手动固定
→ 检查订阅更新是否覆盖了配置。
对于大多数普通用户：
不要一开始追求复杂自动策略。
先把一个简单Fallback组配置正确，再逐步加入URL-Test、Provider和地区筛选，会更稳定，也更容易排查问题。