Clash 策略组里负载均衡怎么配：load-balance 与散列选节点分步操作

1. 为什么「自动选最快」不是负载均衡

url-test 的核心是：在一组通过健康检查的候选里，周期性地做延迟探测，并选出一个当前认为最快的节点，让该策略组承载的流量集中走这一条出口（在容差等约束下可能切换）。它解决的是「谁当下最快」的择优问题，而不是「把并发摊到多台」的并行问题。于是你会看到：即便列表里有十个节点，长期活跃的往往只有少数几条测速数据里排头的成员，下载线程或多连接仍可能挤在同一条线路上，只是这条恰好在测速上胜出。

load-balance 型策略组则面向另一类目标：在多连接或多路会话存在时，把出口节点分配到组内不同成员上，从整体上降低单点饱和风险，并可通过散列让「同一类连接」长期落到固定节点，满足站点对出口一致性的要求。它不以延迟榜单为唯一决策依据，因此与 url-test 的「赛马选快」是互补关系。若你尚未区分 url-test 与 fallback，建议先读站内 《Clash 策略组 url-test 与 fallback》，再回来看负载均衡，心智模型会清晰很多。

2. 第一步：在 proxy-groups 里声明 load-balance

在合并后的 config.yaml（或你客户端写入的最终配置）中，proxy-groups 下增加一项，将 type 设为 load-balance，并在 proxies 中列出参与节点分配的成员名称（与 proxies 段或 provider 中定义的名称完全一致，建议复制避免手误）。strategy 取 round-robin 或 consistent-hashing。多数 Clash Meta 系实现中，为与 url-test 类似，仍可为该组配置 url 与 interval 做健康检查，只有标记为健康的成员才参与轮询或散列；若某成员被判定异常，实现会从可用集合中剔除，避免把流量导到死节点。

下面给出一段示意结构，节点名、探测地址与秒数请按你实际订阅与网络环境调整。若合并配置后内核报错，优先核对：缩进、组名、以及所用 mihomo 版本是否支持 load-balance 与所选 strategy 组合。

  - name: "下载-多出口-LB-RR"
    type: load-balance
    strategy: round-robin
    proxies:
      - 香港-01
      - 香港-02
      - 新加坡-01
    url: "http://www.gstatic.com/generate_204"
    interval: 300

  - name: "会话-稳定绑定-LB-CH"
    type: load-balance
    strategy: consistent-hashing
    proxies:
      - 美国-01
      - 美国-02
    url: "http://www.gstatic.com/generate_204"
    interval: 300

与订阅导入、文件结构不熟悉的读者，可对照 订阅导入教程 找到 proxy-groups 在整份配置中的位置；多数 GUI 客户端在「策略组 / 代理组」界面里增删成员，本质仍是向这段 YAML 读写。

3. 第二步：round-robin 与 consistent-hashing 的取舍

round-robin（轮询）通常按新连接、新会话或实现定义的粒度，在健康成员之间轮流分配，使多连接更容易分散到不同节点，适合希望「别让几百条连接全砸在同一台小水管上」的场景，例如大文件多线程、浏览器大量并行请求、或你想宏观上均摊组内各节点的利用率。其代价是：同一源到同一目的地的两条连接，未必长期落在同一出口，若对端服务对 IP 变动敏感，偶尔会遇到风控或会话不连续，需要按业务换策略或收窄规则。

consistent-hashing（常见译法：一致性哈希/散列选路）则依据连接或数据包的可哈希特征，把同一条「逻辑上应稳定」的流映射到组内某固定节点。效果是：同一对端、同一类特征在节点集合不变、算法一致的前提下，会稳定地走到同一台，有利于与「同出口长时间会话」相关的体验，同时组内多不同来源仍会被不同哈希槽位分到不同机器，整体上避免所有人都挤在列表第一项。你若是「多连接要分摊，但同一设备或同一对地址不要老换出口」，往往优先考虑散列。具体哈希输入以内核实现为准，升级版本时若行为有微调，可观察日志与出口 IP 变化。

4. 与 url-test、fallback 对照

一表概括三类常见策略组在决策逻辑上的区别，避免把「测速单选」与「负载多出口」混用同一段配置期待。

因此：追求「总延迟最低、全体跟一台」仍用 url-test；追求「主挂再换」用 fallback；追求「多连接别全挤一机或按散列长期落到固定节点」再考虑 Clash 负载均衡 的 load-balance。三者都可挂在 rules 里作为动作目标，规则自上而下匹配的特性不变，与策略组内部算法无关。关于规则与策略顺序的更多讨论见 规则分流基础说明。

5. 在 rules 里引用与典型场景

定义好组名后，在 rules: 里把需要「多路分摊或散列稳定」的业务指向该组即可，例如 DOMAIN-SUFFIX,download.example,下载-多出口-LB-RR，或在更细的匹配之后用独立一行指向你的 load-balance 组。常见动机包括：大文件多连接下载工具希望并行连接落在不同家宽或不同机房、浏览器对同一主域并发大量子请求时期望宏观分散、以及明确只希望某类目标域名走一组节点而不是全局限速的 url-test 单点。

与「把全局默认设成 load-balance 组」相比，更稳妥的做法往往是：仅对确有多连接/分摊需求的域名或应用走负载均衡组，其它仍用 MATCH 或 url-test 组，既减少无意义多跳，也避免把对延迟敏感、且未必能从多机获益的流量强行拆开。配完后建议打开客户端或内核日志，看命中规则与实际出口是否符合预期，而不是只盯着 YAML 表面。

6. 健康检查、UDP 与调参

url 与 interval 若指向在你网络下高延迟或间歇失败的地址，健康检查会频繁波动，节点分配集合随之抖动，轮询与散列的稳定性都会变差。可更换为内核文档与社区常推荐的轻量探测目标，并避免把间隔压得过短。部分场景下 UDP 与游戏、语音相关，负载均衡对 UDP 的支持程度因版本与实现而异，若出现「TCP 已分摊、UDP 仍单点或异常」应在对应版本的 issue 与文档中核对是否需额外开关或是否不建议对该规则使用 load-balance。

另外，列表成员过少时谈「多机均衡」意义有限，成员越多、单节点带宽越小，多连接带来的整体吞吐优势越容易体现；但成员过多又会使健康检查与排错成本上升，需要在可维护性与效果之间取平衡。最后，机场/订阅方若禁止多会话或多出口策略，请在遵守服务条款的前提下使用，本文仅作技术能力说明。

7. 配置清单