负载均衡与故障转移:打造稳定不断线的代理组

代理组与策略概览

Clash 的 proxy-groups 决定了流量如何在多个节点或子组之间选择。规则匹配后,会指向某个代理组(如 PROXY、自动选择、故障转移),组内的策略再决定最终使用哪个节点。

除手动选择的 select 外,还有三种自动化策略能显著提升稳定性与体验:

  • url-test:定期测速,自动选延迟最低的节点。
  • fallback:按顺序使用,当前节点不可用时自动切到下一个。
  • load-balance:将连接分散到多个节点,分摊负载。

合理组合这些策略,可以告别「手动切节点」「单点故障断线」等常见烦恼,让代理连接既快又稳,日常使用更加安心。

select:手动选择

select 是最基础的代理组类型,用户在客户端或面板中手动挑选节点。适合「我知道哪条线路最好」的场景,或作为自动策略的补充——例如同时配置「自动选择」(url-test)和「手动选择」(select),平时用自动,需要时手动干预。

机场订阅通常会提供「节点选择」「香港」「日本」等 select 组,方便按地区或用途切换。

url-test:自动择优

url-test 会定期对组内每个节点发起 HTTP 请求(默认测速 URL 如 http://www.gstatic.com/generate_204),根据延迟选择最快的节点并自动切换。适合「永远想用最快节点、不想手动测速」的用户。

- name: "自动选择" type: url-test proxies: [香港01, 日本01, 新加坡01] url: "http://www.gstatic.com/generate_204" interval: 300 tolerance: 50 lazy: true

关键参数说明:

  • interval:测速间隔(秒),默认 300,不宜过短以免频繁切换。
  • tolerance:容差(毫秒),新节点比当前快超过此值才切换,避免频繁抖动。
  • lazy:懒加载,仅在有流量时测速,节省资源。

fallback:故障转移

fallback 按 proxies 列表顺序使用节点,仅当当前节点测速失败或不可达时,才尝试下一个。适合「有明确主力节点,主力挂了再用备用」的场景,如主力香港、备用日本、备用美国。

- name: "故障转移" type: fallback proxies: [主力节点, 备用节点A, 备用节点B] url: "http://www.gstatic.com/generate_204" interval: 180

与 url-test 的区别:fallback 不会主动切换到更快的节点,只在当前节点失效时切换,因此更稳定、切换更少。适合对延迟波动敏感、希望固定使用某条线路的用户,例如观看直播或进行远程桌面连接时。

load-balance:负载均衡

load-balance 将不同连接分散到组内多个节点,缓解单节点压力,提高整体吞吐。可选策略:

  • round-robin:轮询,依次使用各节点。
  • consistent-hashing:一致性哈希,同一目标(域名+端口)固定走同一节点,对需要会话保持的站点(如登录态)更友好。
- name: "负载均衡" type: load-balance proxies: [节点1, 节点2, 节点3] url: "http://www.gstatic.com/generate_204" interval: 300 strategy: consistent-hashing

负载均衡适合多节点、高并发场景,个人用户日常使用 url-test 或 fallback 通常已足够。若你订阅的节点数量较多,不妨为不同地区分别建 url-test 组,再在顶层做二次择优,充分发挥多节点的优势。合理规划代理组结构,是提升 Clash 使用体验的关键一步,也是从业余用户进阶到熟练玩家的必经之路。

常见做法:用 url-test 做「自动选择」作为主组,再放一个 select 组方便随时手动干预。规则中 PROXY 指向「自动选择」即可。

嵌套代理组

代理组的 proxies 不仅可以填节点名,还可以填其他代理组名,实现嵌套。例如:

- name: "香港组" type: url-test proxies: [香港01, 香港02, 香港03] url: "http://www.gstatic.com/generate_204" interval: 300 - name: "自动选择" type: url-test proxies: [香港组, 日本组, 新加坡组] url: "http://www.gstatic.com/generate_204" interval: 300

先在各地区组内选最快节点,再在地区组之间选最快,结构清晰、易于维护。嵌套层数不宜过多,一般两到三层即可满足绝大多数需求,过深的嵌套会增加测速开销和理解成本。

参数调优与排错

若自动切换过于频繁,增大 toleranceinterval。若节点经常误判断线,检查测速 URL 是否可访问、节点是否被墙。若希望固定使用某节点,用 select 或 fallback 并将目标节点放首位。测速 URL 推荐使用 generate_204 类轻量接口,响应快、流量小,不会给节点带来额外负担。

在 Clash 面板的 Proxies 页可实时查看各组当前选中节点及延迟,便于调试。若使用机场订阅,部分订阅已内置优化过的代理组,可直接使用;自行编写配置时,可参考本文示例逐步调整。

典型使用场景

日常上网:规则中 PROXY 指向 url-test 的「自动选择」,兼顾速度与省心。偶尔需要固定节点时,在客户端切换到 select 组即可。多数机场订阅已内置类似结构,导入后可直接使用。

直播 / 视频会议:对延迟和稳定性要求高,建议用 fallback 将低延迟节点放首位,或使用 select 固定一条测速最优的线路,避免 url-test 自动切换导致短暂断流。

下载大文件:可尝试 load-balance 分摊到多节点,或 select 选带宽大的专线节点。注意部分机场对单连接限速,负载均衡可能无法突破单线带宽上限。无论哪种场景,都建议在 Clash 面板观察一段时间的实际表现,再决定是否调整 interval、tolerance 等参数,避免过度优化带来的不稳定。

小结

url-test、fallback、load-balance 三种策略各有侧重:追求速度用 url-test,追求稳定用 fallback,分摊负载用 load-balance。结合 tolerance、interval、lazy 等参数微调,配合 select 手动干预和嵌套代理组,就能打造既快又稳、不易断线的代理方案。建议从「自动选择 + 手动选择」的双组配置开始,再根据实际体验逐步优化。代理组配置是 Clash 进阶的核心技能之一,掌握后无论换机场还是自建节点,都能快速搭建出顺手的连接策略。投入少量时间理解各策略差异,长远来看能省下大量手动切节点的时间,上网体验也会更加省心、流畅。

准备好体验 Clash 了吗?

前往 Clash 官方中文网下载客户端中文版,按教程导入订阅,Windows / macOS / Android / iOS / Linux 全平台支持,几分钟即可上手。

返回博客列表