Clash 负载均衡完全入门 – wiki基地

作者： /

Clash 负载均衡完全入门：构建稳定、高效的网络代理

引言：为何需要代理组与负载均衡？

对于许多用户而言，Clash 已经成为一个强大且灵活的网络代理工具。它允许我们通过配置文件定义复杂的路由规则和代理策略，以应对不同的网络环境和访问需求。然而，仅仅配置一个或两个代理节点往往不足以满足所有场景。

想象一下，你依赖一个单一的代理节点。如果这个节点突然发生故障、速度变慢，或者因为负载过高而变得不稳定，你的网络连接就会立即受到影响，导致访问中断或体验下降。特别是在代理节点资源有限、稳定性波动大的情况下，这种风险尤其突出。

这就是 代理组（Proxy Groups） 和 负载均衡（Load Balancing） 概念应运而生的原因。

代理组 允许我们将多个代理节点组织在一起，形成一个逻辑上的集合。通过配置代理组的策略，Clash 可以智能地从这个集合中选择一个或多个节点来处理流量。

而 负载均衡（或更广义地说，自动化节点选择策略）则是代理组策略中的一种高级应用。它不仅仅是手动切换节点，更是让 Clash 根据预设的规则（如节点的健康状况、延迟、连接数等）自动选择或分配流量，从而达到以下目的：

  1. 提高可靠性： 当某个节点出现故障时，自动切换到其他可用节点，保证网络连接不中断。
  2. 提升性能： 自动选择当前速度最快、延迟最低的节点，优化访问体验。
  3. 分散流量： 将流量分配到多个节点上，避免单个节点过载，延长节点的使用寿命或提高稳定性。
  4. 简化操作： 用户无需手动监控节点状态和切换，一切由 Clash 自动完成。

本文将带你深入了解 Clash 中如何配置和利用代理组的不同策略，特别是那些实现自动节点选择和流量分配的模式，让你彻底掌握 Clash 的负载均衡精髓。

代理组（Proxy Groups）的基础

在深入负载均衡之前，我们必须理解 Clash 配置中的 proxy-groups 部分。这是所有节点选择策略的基础。

一个典型的 Clash 配置文件（YAML 格式）包含 proxies（定义所有可用的代理节点）和 proxy-groups（定义如何使用这些节点）两个主要部分。

proxy-groups 部分是一个列表，列表的每个元素都是一个代理组的定义。每个代理组至少包含以下几个基本属性：

  • name: 代理组的名称，用于在规则或其他代理组中引用。
  • type: 代理组的类型，决定了这个组如何选择或处理流量。这是实现不同策略（包括负载均衡）的关键。
  • proxies: 一个列表，包含这个代理组可用的代理节点或子代理组的名称。

例如：

“`yaml

… 其他配置，如 port, socks-port, allow-lan 等

proxies:
– name: “Proxy-A”
type: ss
server: your_server_a
port: 443
password: your_password_a
cipher: aes-256-gcm
– name: “Proxy-B”
type: vmess
server: your_server_b
port: 80
uuid: your_uuid_b
alterId: 0
cipher: auto
– name: “Proxy-C”
type: ss
server: your_server_c
port: 8443
password: your_password_c
cipher: chacha20-ietf-poly1305

proxy-groups:
– name: “MyProxyGroup”
type: select # 这是最基本的类型，手动选择
proxies:
– “Proxy-A”
– “Proxy-B”
– “Proxy-C”
– “DIRECT” # DIRECT 表示直连，不是代理节点
– “REJECT” # REJECT 表示拒绝连接

… 路由规则 (Rules) 会引用这些代理组

rules:

– DOMAIN-KEYWORD,google,MyProxyGroup

– MATCH,DIRECT # 默认规则

“`

在上面的例子中，我们定义了三个代理节点 Proxy-A, Proxy-B, Proxy-C，以及一个名为 “MyProxyGroup” 的代理组。这个组的类型是 select，它允许用户在 Clash 客户端界面手动从 “Proxy-A”, “Proxy-B”, “Proxy-C”, “DIRECT”, “REJECT” 中选择一个作为当前策略。

select 是最基础的代理组类型，它不涉及自动选择。真正的负载均衡或自动化节点选择策略体现在 proxy-groups 的其他 type 类型中。

接下来，我们将详细介绍 Clash 中用于实现自动化节点选择和流量分配的主要代理组类型。

Clash 的自动化节点选择与负载均衡策略类型

Clash 提供了几种不同的代理组类型，它们通过内置的策略实现节点的自动选择或流量分配。这些类型包括：

  1. url-test (延迟测试选择最快)
  2. fallback (健康检查选择第一个可用)
  3. load-balance (真正的流量负载均衡/分发)

理解这三种类型的区别和用途是掌握 Clash 负载均衡的关键。

1. url-test 类型：速度优先的选择器

url-test 是 Clash 中最常用的自动化节点选择类型之一。它的核心功能是 定期对组内的所有代理节点进行延迟测试（通过访问一个特定的 URL），并自动选择当前延迟最低且健康的节点。

工作原理：

  • Clash 会周期性地（根据配置的 interval）向组内所有代理节点发送一个 HTTP GET 请求到指定的 url。
  • 它测量每个节点响应这个请求所需的时间（即延迟）。
  • 同时，它检查响应状态码（通常是 2xx 表示成功，即节点健康）。
  • 在健康的节点中，Clash 会选择延迟最低（速度最快）的一个作为当前的出站代理。
  • 如果当前使用的节点变得不健康或延迟过高超过设定的 tolerance 阈值，Clash 会触发一次新的测试并切换到新的最优节点。

适用场景：

  • 你有一组节点，希望总是使用当前速度最快、延迟最低的那个。
  • 你关心访问特定服务（如 Google, YouTube 等）的速度。

配置参数：

  • name: 代理组名称。
  • type: url-test。
  • proxies: 包含节点名称或子代理组名称的列表。
  • url: 用于测试节点连通性和延迟的 URL。通常选择一个稳定、响应快的网站，如 http://www.gstatic.com/generate_204 或 http://cp.cloudflare.com/generate_204。也可以用其他你常用的服务地址，但需要确保这些地址通过直连是无法访问或测试结果准确的（例如，如果你在中国大陆直连无法访问 Google，那么测试 google.com 的延迟是合理的）。
  • interval: 延迟测试的间隔时间，单位为秒。例如 300 表示每 5 分钟测试一次。
  • tolerance: （可选）延迟容忍度，单位为毫秒。如果在健康测试中当前节点的延迟超过 “测试结果中最低延迟 + tolerance”，Clash 可能会触发一次新的测试并切换节点。例如，tolerance: 50 意味着如果当前节点延迟比最快节点慢 50ms 以上，就可能切换。
  • lazy: （可选，布尔值）如果设置为 true，Clash 只有在需要建立新连接时才进行延迟测试和选择节点。这可以减少不必要的后台测试，但在节点状态变化时不一定能立即切换。默认通常为 false。

配置示例：

yaml
proxy-groups:
- name: "AutoSpeedTest"
type: url-test
proxies:
- "Proxy-A"
- "Proxy-B"
- "Proxy-C"
url: http://www.gstatic.com/generate_204
interval: 600 # 每 10 分钟测试一次
tolerance: 100 # 如果当前节点比最快节点慢 100ms 以上，考虑切换

优点： 总是尝试为你选择当前性能最好的节点，优化速度体验。
缺点： 如果节点状态频繁波动，可能会导致频繁切换；测试 URL 的选择很重要，会影响测试结果的准确性。

2. fallback 类型：可靠性优先的选择器

fallback 策略关注的是节点的可靠性。它的工作原理是 按照 proxies 列表中的顺序，定期检查节点的健康状况，并选择第一个健康的节点。

工作原理：

  • Clash 按照你在 proxies 列表中定义的顺序，依次对每个节点进行健康检查（通过访问指定的 url）。
  • 它选择列表中遇到的第一个 健康 节点作为当前的出站代理。
  • 如果当前使用的节点变得不健康，Clash 会立即从列表的开头重新扫描，寻找第一个健康的节点进行切换。
  • 只有当列表中的所有节点都变得不健康时，这个代理组才会失效。

适用场景：

  • 你有一组备用节点，希望主节点不可用时能自动切换到备用节点。
  • 你优先关心连接的稳定性，不一定需要最快的速度，但要求在节点故障时能快速切换。
  • 你的节点有优先级之分（例如，付费节点优先于免费节点，流量多的节点优先于流量少的节点）。

配置参数：

  • name: 代理组名称。
  • type: fallback。
  • proxies: 包含节点名称或子代理组名称的列表。列表中的顺序至关重要，因为它决定了节点的优先级。
  • url: 用于测试节点连通性的 URL。与 url-test 类似。
  • interval: 健康检查的间隔时间，单位为秒。如果设置为 0，表示不进行周期性检查，只在需要时（如当前节点连接失败）触发检查。

配置示例：

yaml
proxy-groups:
- name: "ReliableGroup"
type: fallback
proxies:
- "MainProxy" # 主要使用的节点，放在第一位
- "BackupProxy-1" # 主节点失效时使用
- "BackupProxy-2" # 如果 BackupProxy-1 也失效则使用
url: http://www.gstatic.com/generate_204
interval: 300 # 每 5 分钟检查一次健康状态

优点： 简单有效，高度可靠，确保总有健康的节点可用（如果存在）。可以根据节点优先级进行排序。
缺点： 不考虑节点的速度，只关注健康状态。可能长期使用一个健康的但速度较慢的节点，而忽略列表中后面速度更快的节点。

3. load-balance 类型：流量分配器

load-balance 是 Clash 中用于实现真正意义上的“负载均衡”的类型。与 url-test 和 fallback 每次只选择一个节点不同，load-balance 策略会 根据一定的策略将流量（不同的连接）分配到组内多个健康的节点上。

工作原理：

  • Clash 会定期对组内所有代理节点进行健康检查（通过访问指定的 url）。
  • 它维护一个健康的节点列表。
  • 当有新的网络连接需要通过这个代理组时，Clash 会根据配置的 strategy（策略）从健康的节点列表中选择一个节点来处理这个连接。
  • 不同的连接可能会被分配到不同的节点，从而将整体流量分散到多个节点上。

适用场景：

  • 你希望将流量分散到多个节点，以避免单个节点流量过大被限速或封禁。
  • 你有多个性能相似的节点，希望同时利用它们的带宽。
  • 你希望通过分散连接来降低单个节点出现临时问题的风险。

配置参数：

  • name: 代理组名称。
  • type: load-balance。
  • proxies: 包含节点名称或子代理组名称的列表。
  • url: 用于测试节点连通性（健康检查）的 URL。
  • interval: 健康检查的间隔时间，单位为秒。
  • strategy: 负载均衡策略。这是 load-balance 类型的核心。Clash 支持的策略包括：
    • consistent-hash (一致性哈希): 根据目标地址（域名或IP）和端口来选择节点。同一个目标地址的连接通常会固定使用同一个节点，除非该节点失效。这有助于维持与特定服务器的连接稳定性（例如，某些网站登录状态可能依赖于连接的IP）。
    • round-robin (轮询): 按照列表顺序依次将连接分配给健康的节点。例如，第一个连接给节点A，第二个给节点B，第三个给节点C，第四个再给节点A，以此类推。这是最简单的分配策略。
    • least-conn (最少连接): 将新的连接分配给当前活跃连接数最少的健康节点。这旨在更均匀地分配负载，避免某些节点连接数过多。

配置示例：

yaml
proxy-groups:
- name: "LoadBalancedGroup"
type: load-balance
proxies:
- "Proxy-X"
- "Proxy-Y"
- "Proxy-Z"
url: http://www.gstatic.com/generate_204
interval: 300 # 每 5 分钟检查健康状态
strategy: consistent-hash # 使用一致性哈希策略

优点： 真正实现流量分散，避免单点过载，提高整体可用性。可以同时利用多个节点的资源。
缺点： 不会优先选择最快的节点（不像 url-test），而是平均分配或根据连接特性分配。如果节点之间性能差异很大，使用 round-robin 可能导致整体性能受限于最慢的节点。consistent-hash 可能导致某些热门目标地址的流量集中在少数节点上。

关键配置参数详解

在配置自动化代理组时，有几个关键参数是共享且非常重要的：

  • url: 用于健康检查或延迟测试的 URL。选择一个可靠、响应快且不会被直连访问的 URL 至关重要。如果选择的 URL 本身就不稳定，或者容易被墙，那么健康检查结果就会不准确。常用的如 http://www.gstatic.com/generate_204 或 http://cp.cloudflare.com/generate_204 是因为它们设计为无内容响应，主要用于测试连通性和延迟。你也可以测试特定服务，例如 https://www.google.com/generate_204 或 https://www.youtube.com/（但需要确保这些地址不会被墙影响测试结果）。
  • interval: 测试/检查的间隔时间（秒）。
    • url-test 和 load-balance 通常建议设置一个合理的间隔（如 300-600 秒），太短会增加测试开销，太长则无法及时发现节点故障或性能变化。
    • fallback 如果设置为 0，则只在当前节点连接失败时触发检查和切换，这样可以减少后台流量，但反应可能不如周期性检查及时。设置一个较短的间隔（如 60-180 秒）可以在节点故障时更快切换。
  • tolerance: url-test 独有参数，用于设置延迟容忍度。值越小，Clash 越倾向于切换到延迟更低的节点；值越大，Clash 会“容忍”当前节点更大的延迟差异，减少不必要的切换。根据你的网络环境和对速度的要求调整。

嵌套代理组：构建复杂策略

Clash 的强大之处在于代理组可以相互嵌套。一个代理组的 proxies 列表中不仅可以包含基础的代理节点名称，还可以包含其他代理组的名称。这允许我们构建非常灵活和复杂的策略。

常见嵌套模式：

  1. 顶级 select 组包含自动化组： 这是最常见的组织方式。创建一个顶级的 select 组，将不同的自动化组（如 url-test 组、fallback 组）以及直连、拒绝等选项包含在内。用户可以在客户端手动选择使用哪种策略。

    “`yaml
    proxy-groups:
    – name: “ManualSelect”
    type: select
    proxies:
    – “AutoSpeedTest” # 包含上面的 url-test 组
    – “ReliableGroup” # 包含上面的 fallback 组
    – “DIRECT”
    – “REJECT”

    # AutoSpeedTest 和 ReliableGroup 的定义跟上面一样…
    – name: “AutoSpeedTest”
    type: url-test
    proxies: […]
    url: …
    interval: …

    • name: “ReliableGroup”
      type: fallback
      proxies: […] # 注意顺序
      url: …
      interval: …

    rules:
    – MATCH,ManualSelect # 所有流量先进入 ManualSelect 组
    ``
    这样，你可以在客户端选择是让 Clash 自动选择最快节点 (    AutoSpeedTest)，还是选择按优先级自动切换节点 (ReliableGroup`)，或者直连/拒绝。

  2. 自动化组包含 select 组： 例如，一个 fallback 组中包含一个 select 组作为备用选项。这不太常见，因为自动化组期望内部是可测试健康的节点或自动化组，但理论上可以将 select 组作为一个“节点”对待（当选择到它时，用户需要手动在其中再做选择）。

  3. 自动化组包含其他自动化组： 例如，一个 fallback 组包含多个 url-test 组。这可以用来实现更复杂的优先级策略：

    “`yaml
    proxy-groups:
    – name: “PrimaryRegion”
    type: url-test # 在主区域节点中选择最快的
    proxies:
    – “PrimaryNode-1”
    – “PrimaryNode-2”
    url: …
    interval: …

    • name: “BackupRegion”
      type: url-test # 在备用区域节点中选择最快的
      proxies:

      • “BackupNode-A”
      • “BackupNode-B”
        url: …
        interval: …

    • name: “FinalReliable”
      type: fallback # 优先使用主区域的最快节点，如果都失效，再用备用区域的最快节点
      proxies:

      • “PrimaryRegion” # 第一个优先级：主区域组
      • “BackupRegion” # 第二个优先级：备用区域组
      • “DIRECT” # 最后手段：直连

    rules:
    – MATCH,FinalReliable
    ``
    这个例子展示了如何结合    fallback的优先级和url-test` 的速度测试，实现“优先使用主区域最快节点，主区域全跪后切换到备用区域的最快节点”的策略。

  4. load-balance 组包含其他自动化组： 例如，将多个 url-test 组或 fallback 组作为 load-balance 组的成员。这可能用于在多个策略组之间分散流量，但不如直接在 load-balance 组中放置基础节点常见和直观。

通过嵌套，你可以根据自己的需求构建出层层递进、灵活多变的代理策略。

实践配置示例与分析

下面提供几个更贴近实际应用的配置片段，帮助你理解如何将上述概念组合起来。

示例 1：速度优先 + 备用保障

目标：优先选择一组节点中最快的，但如果主组节点都失效，自动切换到一组备用节点。

“`yaml
proxies:
# … 定义你的所有节点，例如：
– name: “JP-Node-1” # 日本节点1
…
– name: “JP-Node-2” # 日本节点2
…
– name: “SG-Node-A” # 新加坡节点A
…
– name: “SG-Node-B” # 新加坡节点B
…
– name: “US-Backup” # 美国备用节点
…

proxy-groups:
– name: “JP-SG-Fastest” # 在日本和新加坡节点中选最快的
type: url-test
proxies:
– “JP-Node-1”
– “JP-Node-2”
– “SG-Node-A”
– “SG-Node-B”
url: http://www.gstatic.com/generate_204
interval: 300
tolerance: 80

  • name: “MainStrategy” # 主要策略组：优先使用 JP-SG-Fastest，失效后用 US-Backup
    type: fallback
    proxies:

    • “JP-SG-Fastest” # 注意这里包含了上面的 url-test 组
    • “US-Backup”
    • “DIRECT” # 如果所有节点都失效，则尝试直连
      url: http://www.gstatic.com/generate_204 # fallback 组也需要健康检查，但检查的是子组/节点是否“健康”
      interval: 60 # 快速检查，失效时能及时切换

  • name: “Proxy” # 顶级选择组，用户可以选择 MainStrategy 或其他
    type: select
    proxies:

    • “MainStrategy”
    • “DIRECT”
    • “REJECT”

rules:
– DOMAIN-SUFFIX,google.com,Proxy
– DOMAIN-SUFFIX,youtube.com,Proxy
# … 其他规则
– MATCH,DIRECT # 默认直连
“`

分析：

  • JP-SG-Fastest 组负责在几个亚洲节点中通过延迟测试找出当前最快的。
  • MainStrategy 组是 fallback 类型，它首先检查 JP-SG-Fastest 组。如果 JP-SG-Fastest 组中的所有节点都失效（根据其自身的健康检查），那么 MainStrategy 组会认为 JP-SG-Fastest 这个子组“不健康”，然后尝试列表中的下一个代理——US-Backup。如果 US-Backup 也失效，最后会尝试 DIRECT。
  • Proxy 组作为用户手动选择的入口，你可以选择启用自动策略（MainStrategy）或强制直连/拒绝。

这个例子巧妙地结合了 url-test 的速度选择和 fallback 的可靠性保障。

示例 2：按地区分流 + 地区内负载均衡

目标：将流量按地区分发，每个地区的流量在其区域内的节点中进行负载均衡。

“`yaml
proxies:
# … 定义你的所有节点，例如：
– name: “US-1” # 美国节点1
…
– name: “US-2” # 美国节点2
…
– name: “EU-A” # 欧洲节点A
…
– name: “EU-B” # 欧洲节点B
…
– name: “Asia-X” # 亚洲节点X
…

proxy-groups:
– name: “US-LoadBalance” # 美国节点负载均衡
type: load-balance
proxies:
– “US-1”
– “US-2”
url: http://www.gstatic.com/generate_204
interval: 300
strategy: least-conn # 或 round-robin, consistent-hash

  • name: “EU-LoadBalance” # 欧洲节点负载均衡
    type: load-balance
    proxies:

    • “EU-A”
    • “EU-B”
      url: http://www.gstatic.com/generate_204
      interval: 300
      strategy: consistent-hash # 根据目标保持连接一致性

  • name: “RegionSelect” # 用户手动选择区域或策略
    type: select
    proxies:

    • “US-LoadBalance” # 选择美国组，流量将在 US-1 和 US-2 间分配
    • “EU-LoadBalance” # 选择欧洲组，流量将在 EU-A 和 EU-B 间分配
    • “Asia-X” # 选择单个亚洲节点
    • “DIRECT”
    • “REJECT”

rules:
# 可以根据访问目标分发到不同区域组
# 例如，访问美国网站走美国组，访问欧洲网站走欧洲组 (但这需要更复杂的规则)
# 更常见的用法是，用户手动在 RegionSelect 选择一个区域策略作为全局或特定规则的出口
– DOMAIN-SUFFIX,hulu.com,US-LoadBalance # 访问 Hulu 走美国组
– DOMAIN-SUFFIX,bbc.co.uk,EU-LoadBalance # 访问 BBC 走欧洲组
– MATCH,RegionSelect # 其他流量默认走手动选择的区域或策略
“`

分析：

  • US-LoadBalance 和 EU-LoadBalance 分别是针对不同区域节点的 load-balance 组，它们会根据配置的策略将流量分散到组内的多个节点。
  • RegionSelect 是一个 select 组，用户可以在其中选择是使用美国负载均衡组、欧洲负载均衡组、单个亚洲节点，还是直连/拒绝。
  • 规则部分可以更精细地根据目标域名/IP 将流量直接导向特定的负载均衡组，实现地域性分流。

这个例子展示了如何使用 load-balance 来分散流量，并通过 select 或规则来实现基于区域的策略选择。

故障排除与最佳实践

掌握了这些策略后，在使用过程中可能会遇到一些问题。以下是一些故障排除建议和最佳实践：

常见问题：

  1. 节点无法连接或切换不及时：

    • 检查代理节点本身是否工作正常。
    • 检查 url 参数是否设置正确且可达。尝试更换测试 URL。
    • 检查 interval 参数，如果设置过大，Clash 会很久才进行下一次测试和发现节点失效。
    • 检查 Clash 的日志输出，可以看到健康检查的结果和节点切换信息。
    • 对于 url-test，tolerance 参数可能导致在性能略有波动时不切换。

  2. url-test 选择的不是期望中最快的节点：

    • 延迟测试结果与实际使用速度可能不完全一致（例如，测试服务器带宽很高但目标服务器带宽有限）。
    • 测试 URL 本身的延迟可能受网络环境影响。
    • 确保所有节点都能正常访问测试 URL。

  3. load-balance 流量分配不均或某个节点负载过高：

    • 不同的 strategy（consistent-hash, round-robin, least-conn）有不同的分配逻辑，尝试更换策略。
    • consistent-hash 依赖目标地址，如果大部分流量都流向少数几个目标，可能导致那几个目标对应的节点负载较高。
    • 确保组内的所有节点都是健康且性能相近的。如果混用性能差异很大的节点，即使分配均匀，整体体验也受慢节点影响。

最佳实践：

  1. 选择合适的测试 URL： 使用稳定、快速响应且不会被你所在区域直连访问的 URL。常用的如 http://www.gstatic.com/generate_204 是不错的起点。你也可以测试你经常访问的服务的地址，但要确保测试结果能反映真实的网络质量。
  2. 合理设置 interval： 太短会增加系统开销和测试流量，太长则响应不及时。对于大多数用户，300-600 秒（5-10 分钟）是一个比较均衡的选择。如果节点非常不稳定，可以适当缩短。
  3. 理解并选择合适的策略 (url-test, fallback, load-balance)：
    • 如果追求速度，使用 url-test。
    • 如果追求稳定性/可靠性并希望按优先级使用备用节点，使用 fallback。
    • 如果希望分散流量到多个节点，使用 load-balance。
    • 结合使用可以构建更灵活的策略。
  4. 利用嵌套组组织节点： 将不同区域、不同类型的节点先组织成子组（如按地区分 url-test 组），再将这些子组加入到顶层策略组中，可以使配置更清晰、管理更方便。
  5. 给代理组和节点起有意义的名称： 清晰的命名可以让你更容易理解配置结构和在客户端选择策略。
  6. 定期维护节点列表： 移除失效或性能低下的节点，添加新的优质节点。自动策略依赖于健康的节点池。
  7. 查看 Clash 日志： 当遇到问题时，查看 Clash 的详细日志通常能帮助你定位问题所在，比如哪个节点测试失败，为何没有切换等等。
  8. 谨慎使用 tolerance 参数： 对于 url-test，过小的 tolerance 可能导致过于频繁的切换，影响部分服务的连接稳定性；过大则可能长时间使用一个并非最优的节点。根据实际体验进行调整。

总结

Clash 的代理组和负载均衡（自动化节点选择）功能是其强大之处的重要体现。通过 url-test、fallback 和 load-balance 这三种主要类型，我们可以实现速度优先、可靠性优先或流量分散等多种复杂的代理策略。

  • url-test：为你挑选最快、最健康的节点，适合对速度要求高的场景。
  • fallback：按照优先级顺序使用第一个健康的节点，适合构建高可靠性的备份链路。
  • load-balance：将流量分散到多个健康的节点，适合分散风险、充分利用多节点资源的场景。

结合代理组的嵌套功能，你可以根据自己的节点资源、网络环境和使用需求，构建出既稳定又高效的个性化代理方案。

掌握这些知识并勤于实践和调整，你就能充分发挥 Clash 的潜力，获得更稳定、更流畅的网络体验。开始动手配置你的 Clash，告别手动切换节点的时代吧！

发表评论

您的邮箱地址不会被公开。 必填项已用 * 标注

滚动至顶部