外观
Clash 代理组怎么选？一文弄懂自动选择、故障转移与负载均衡
很多人导入 Clash 订阅后，看到策略组里同时出现“自动选择”“故障转移”“负载均衡”“手动选择”等选项，往往只会随便点一个延迟低的节点。日常使用似乎没有问题，但一旦某条线路波动、某个地区无法访问，或者下载速度异常，就会很难判断究竟该切节点、切策略组，还是调整配置。
实际上，Clash 的“代理组”可以理解为节点的调度规则：它决定一条网络请求最终从哪个节点出去，以及节点失效时是否自动更换。理解代理组，比单纯盯着延迟数字更重要。本文重点介绍最常见的四类代理组，并说明普通用户该如何选择。
先建立一个概念：节点不等于代理组
节点是具体的连接入口，例如某个地区、某种协议或某台服务器。代理组则像一个“节点集合加决策方式”，里面可以放多个节点，也可以嵌套另一个代理组。
举例来说，一个配置可能有下面的层级：
节点选择：让用户手动挑选具体节点；自动选择：在多个节点中定期测试，选出响应较快的一个；流媒体：可以单独指定适合视频服务的节点或地区；国外网站：默认使用自动选择；AI 服务：手动选择一个网络环境更匹配的地区节点。
最后，规则会把不同网站或应用的流量交给不同代理组处理。也就是说，规则回答的是“这条请求该走哪一组”，代理组回答的则是“这一组具体用哪个节点”。
因此，当某个网站异常时，不要一上来就在几十个节点之间反复切换。先看该网站命中了哪个代理组，再确认那个代理组的选择逻辑，通常更高效。
手动选择：最直观，也最适合有明确需求时使用
select，也就是手动选择组，是最基础的一种代理组。它不会自行测速、切换或分配流量，当前使用哪个选项完全由你决定。
这类策略组通常会显示为“节点选择”“手动切换”“PROXY”或服务分类名称。组内除了具体节点外，也可能包含 DIRECT（直连）、REJECT（拒绝连接）以及其他代理组。
手动选择的优点很明显：可控、结果容易复现。例如，你需要访问一个对地区有要求的服务，可以固定选择合适的地区；你在排查问题时，也可以固定在单一节点，避免自动切换干扰判断。
但它也有局限：如果当前节点临时不可用，Clash 不会自动帮你切到下一个可用节点。对于希望“少操作”的日常浏览场景，单纯使用手动选择并不总是方便。
适合手动选择的场景包括：
- 某项服务对出口地区有明确要求；
- 需要固定出口环境，避免会话频繁变化；
- 正在排查某一节点、某一网站或某条规则的问题；
- 希望自己决定所有流量走向。
一个实用做法是：保留一个总的“节点选择”手动组，再让其他自动组引用它的节点列表。这样既能随时手动接管，也能在日常使用中享受自动调度。
URL-Test：自动选择不等于“绝对最快”
url-test 是 Clash 中最常见的自动选择组，界面上往往被命名为“自动选择”“自动测速”或“自动优选”。它会以固定间隔访问一个测试地址，比较组内节点完成请求所花费的时间，然后选择结果更好的节点。
它的核心作用是：在节点可连接的前提下，优先选择测试响应更快的节点。
需要特别注意，延迟只是一次特定测试的结果，不等于网页加载、视频播放、下载速度或特定应用体验。一个节点测试延迟较低，可能只是因为它到测试网址的路径较短；而你真正访问的目标网站位于另一个网络或地区，实际体验仍可能不同。
url-test 通常涉及几个关键参数：
url：用于测试连通性的地址；interval：两次测试的时间间隔；tolerance：容差，用于避免节点之间极小的延迟差导致频繁切换；lazy：是否仅在实际需要时再发起测速。
普通用户不一定需要自行编辑这些参数，但应理解它们带来的现象。例如，自动组切换得过于频繁，可能是测试间隔太短、容差太低，也可能是网络本身波动较大。频繁变更出口有时会导致网站要求重新验证，或让正在进行的下载、通话和登录状态变得不稳定。
url-test 更适合以下需求：
- 日常浏览、搜索、资料查阅；
- 多个节点质量接近，希望自动选出当前较顺畅的一个；
- 节点偶有波动，但不希望每次都手动调整；
- 对固定出口地区没有严格要求的流量。
如果你发现自动选择“明明延迟最低却不好用”，可以暂时切到手动选择组，用不同节点访问同一个目标服务进行对比。不要只根据首页显示的毫秒数下结论。
Fallback：优先稳定，不追求最低延迟
fallback 是故障转移组。有些界面会将它翻译为“故障切换”“自动回退”或“备用节点”。它会按照节点在列表中的顺序进行可用性检测：优先使用排在前面的可用节点，当当前节点不可用时，再切换到后续可用节点。
与 url-test 不同，fallback 的重点不是在所有节点中寻找最低延迟，而是维持一个优先级明确的主备关系。
例如，你可以将一个更符合当前需求的节点放在第一位，将另外两个可靠节点放在后面。只要首选节点仍被判定为可用，Clash 通常就会继续优先使用它；只有在检测失败后，才会启用备用项。
这类策略尤其适合不希望出口频繁变化的场景。假如你的任务更看重“能持续用同一个节点完成”，而不是每隔一段时间换到延迟更低的线路，故障转移往往比自动测速更合适。
不过，fallback 的“可用”只代表它通过了配置中的健康检查，不保证每个网站、每种应用都可正常访问。若某一服务打不开，而其他网站正常，问题仍可能与目标服务的地区限制、规则匹配或节点出口环境有关，并不一定意味着节点整体失效。
使用故障转移组时，可以遵循两个原则：
- 把真正希望长期使用的节点或地区放在前面；
- 备用节点不宜堆得过多，保留少量分布不同的备选项即可。
Load-Balance：适合并发请求，不适合所有登录场景
load-balance 是负载均衡组。它的目标不是固定使用一个节点，也不是单纯选择延迟最低的节点，而是把不同连接按一定算法分配给多个节点。
常见的分配思路包括轮询、散列和一致性散列等。不同内核、不同配置写法支持的选项可能有所差异，但普通用户只需要抓住一点：负载均衡可能让不同请求走不同出口。
这在大量独立连接同时发生时可能有价值，例如多线程下载、多个相互独立的网页请求，或将不同域名的流量分散到多个节点。但它并不天然代表“网速翻倍”。实际速度还受到本地网络、远端服务器限速、节点带宽、协议开销和目标网站连接策略影响。
更重要的是，负载均衡存在出口不一致的问题。许多网站会把登录状态、风控校验或会话信息与访问来源关联。如果同一项服务的相关请求在短时间内从不同出口出现，就可能遇到重新验证、验证码增加、会话中断或访问异常。
因此，以下情况一般不建议优先使用负载均衡：
- 登录后的账号操作；
- 支付、账户安全和身份验证页面；
- 长时间在线会议、远程桌面、游戏等持续连接；
- 对出口地区或 IP 稳定性较敏感的服务。
如果配置中已有负载均衡组，而你又不确定它是否适合当前用途，最稳妥的方式是把它用于普通下载或非登录状态下的通用流量，不要把所有服务一股脑都交给它处理。
怎样为不同用途搭配代理组？
对大多数普通用户而言，并不需要为每个应用建立复杂规则。一套相对容易维护的思路是：
- 日常国外网站：优先使用
url-test，减少手动切换； - 账号、AI 服务或地区敏感服务：使用手动选择，或使用首选顺序明确的
fallback； - 下载类流量：根据实际情况尝试自动选择或负载均衡，但要观察是否引发连接异常；
- 国内网站、局域网和设备管理页面：保持直连，不要交给代理组；
- 临时排障：改用手动选择，固定一个节点后再观察现象。
很多订阅自带的策略组已经完成了基本分类。此时最重要的不是立刻修改 YAML，而是先理解每个组的作用，并在客户端的策略页面观察：当前规则组选择了什么、自动组最终选中了哪个节点、切换后问题是否变化。
如果你确实要编辑配置，也建议先备份原文件，并使用覆写或独立配置保存自己的改动。直接改订阅生成的内容，通常会在下一次更新订阅时被覆盖。
常见误区：别把“自动”理解成万能
误区一：延迟最低就一定最好。
延迟测试只是健康检查的一种参考。访问视频、代码仓库、聊天服务或 AI 工具时，最合适的节点可能不同。判断时应结合目标服务的实际打开速度、稳定性和地区要求。
误区二：自动切换越频繁越可靠。
频繁切换不一定是好事。对于需要稳定会话的服务，出口变化反而可能带来问题。自动组应该在“响应变化”和“连接稳定”之间保持平衡。
误区三：负载均衡等于带宽叠加。
单条连接通常仍只能走一个节点。负载均衡主要是分配多条连接，并不能保证一个文件下载或一个视频流就获得多倍速度。
误区四：节点显示超时，就说明整个代理不可用。
测速地址、DNS 解析、本地网络、节点临时负载和客户端设置都可能影响检测结果。应结合实际访问情况，以及 Clash 日志中的报错信息综合判断。
出现异常时，按这个顺序检查
当自动策略组表现不符合预期时，可以按以下顺序处理：
- 先确认本地网络在关闭代理时是否可以正常联网；
- 切换到手动选择组，固定一个节点测试目标网站；
- 查看该目标网站实际命中的规则组，而不是只看总开关；
- 对比
url-test选中的节点与手动测试结果是否一致； - 若只有个别服务异常，检查是否需要单独选择地区或改用稳定出口；
- 若所有节点都异常，再检查订阅更新状态、系统时间、DNS 设置和客户端日志。
代理组的价值不在于让配置看起来复杂，而在于让不同类型的流量用合适的方式被处理。掌握 select、url-test、fallback 和 load-balance 的区别后，你就能更清楚地判断：什么时候应该手动固定节点，什么时候交给自动选择，什么时候需要优先保证连接连续性。
最后要记住，配置越复杂，维护成本越高。对于普通用户，一两个手动组、一个自动选择组、一个故障转移组，再配合清晰的分流规则，通常已经足够覆盖大部分使用场景。