Clash load-balance 策略组与 consistent-hashing：多节点会话保持 YAML 配置

1 为什么光有 url-test 可能不够

url-test 的核心逻辑非常清晰：在一组候选节点里周期性探测延迟，选出当前相对更优的一个出口，让所有命中该策略组的流量都走这条线。它适合「我只想自动用最快节点」的日常场景；但如果你手里有多台可用机、或两个机场订阅希望分摊连接、降低单点被打满的概率，「永远只选最快」反而会把压力集中到同一条线路上。

load-balance 类型策略组的设计目标不同：在列表中的多个 proxies 之间分配新连接，而不是长期只锁一个。具体怎么分配，由 strategy 决定——这正是本文后半部分要展开的 consistent-hashing 与 round-robin。在动手改配置前，请确认你使用的是支持该类型的内核分支（社区常说的 Clash Meta / Mihomo）；经典 Clash Premium 的能力集合与字段名可能不一致，应以当前发行说明为准。

一句话对齐预期 url-test 是「多选一、择优常驻」；load-balance 是「多路分摊」——二者解决的是不同层面的问题，可以并存于不同策略组，由 rules 把不同业务指到不同组。

2 consistent-hashing 与 round-robin：怎么选

round-robin（轮询）通常按某种顺序把新连接依次派到列表中的各个成员上，力求在宏观上均匀占用多条线路。它的直觉很接近「负载均衡」四个字本身：大家轮流扛活。代价是：同一会话若被拆成多条并行连接，理论上可能落到不同出口；部分站点若对出口 IP 频繁变化敏感，可能触发二次验证或风控提示。

consistent-hashing（一致性哈希）则试图在「分摊」与「稳定」之间折中：对连接相关的键做哈希，使相同或相近的流量特征在较长一段时间内映射到同一个候选节点，从用户体感上更接近「会话级粘连」——注意这是内核侧的调度行为，不是网站 Cookie 本身；站点是否仍认为你是「同一用户」，还取决于其风控与账号体系。

实务上，如果你最关心「登录态、表单、购物车别因为出口乱跳而异常」，可以优先尝试 consistent-hashing；若你更关心「把连接尽量均匀摊到所有节点、对单 IP 压力最小」，且目标站点对 IP 变化不敏感，可评估 round-robin。没有放之四海皆准的最优解，只有与业务目标和机场线路质量相匹配的选择。

3 proxy-groups YAML：最小可用模板

下面示例中的 JP-A、JP-B、US-1 必须与你 proxies: 段里的 name 完全一致；若你从两个订阅合并节点，请先保证名称不冲突，或在订阅转换阶段加前缀区分。订阅链接与转换流程可参考《订阅转换完全指南：把 SS/V2Ray/Trojan 机场链接转成 Clash YAML》。

YAML (proxy-groups, load-balance)

proxy-groups:
  - name: MULTI-LB
    type: load-balance
    strategy: consistent-hashing
    proxies:
      - JP-A
      - JP-B
      - US-1
    # url: http://www.gstatic.com/generate_204
    # interval: 300

部分版本在 load-balance 组上仍支持 url 与 interval，用于与成员节点相关的健康探测或统计展示；是否必填、语义是否与 url-test 完全相同，请以你所用的 Mihomo 版本文档为准。若在图形客户端里看到策略类型不可用或启动报错，优先核对内核类型与字段拼写，再排除节点名称引用错误。

改为轮询时

只需将 strategy 改为 round-robin，其余结构可保持不变。建议在变更后用日志观察一段时间：新连接是否按预期分布、目标站点是否出现异常验证。命令行部署用户可结合《Linux 安装 Mihomo 并开机自启》中的校验与排错思路，先 -t 测语法再加载。

4 「会话保持」到底保证什么

用户口中的「同一会话走同一节点」，在工程上常被拆成几层：浏览器里 Cookie / LocalStorage 是否连续、TLS 会话是否复用、以及出口 IP 是否稳定。consistent-hashing 主要影响的是代理侧如何把连接映射到具体节点：在哈希键未变化、候选集合未变、且连接仍被内核视为「同类」的前提下，你更容易得到可重复的出口路径。

但它不是万能的风控豁免器：若网站按账号 + 行为 + 设备指纹综合判定，单纯换哈希策略无法保证「永不跳验证」。反过来，若你使用 round-robin 导致同一页面短时间内从多个地区 IP 访问，部分服务会明显更敏感。排错时应先看规则是否把流量指到了预期的策略组，再看组内策略是否与业务匹配——这与《URL-Test 与 Fallback》里强调的「组名与 rules 一致」是同一类基本功。

5 与延迟、测速的关系：别用错 KPI

url-test 优化的 KPI 往往是「探测 URL 上的 RTT 谁更低」；load-balance 并不以「每条连接都走全局最低延迟节点」为目标。你在测速面板里看到的最快节点，未必是负载均衡组当前映射会选中的那条——这是正常现象，而不是配置一定写错了。

若你的首要痛点是「打游戏 / 语音要极致低延迟」，通常仍应优先考虑精选少量低延迟节点配合 url-test 或手动 select，而不是把大量异质节点丢进同一个 load-balance 组 expecting 自动最优。负载均衡更适合「多条线路质量接近、希望分散压力」或「希望哈希稳定」的场景，而不是替代全局测速逻辑。

别把「分摊」当成「更快」 若延迟明显变差，先检查列表里是否混入了高延迟或高丢包成员；负载均衡只会在参与者之间调度，不会魔法式地把慢线变成快线。

6 双机场、多订阅时怎么组织策略组

常见做法是：每个订阅先在客户端或覆写里整理出地区或用途清晰的子列表，再在一个 load-balance 组里只引用你信任且名称稳定的那几项。不要把几十个未经筛选的节点一次性塞进同一组——那会让哈希空间与故障域都变得难以解释。若你需要在「负载均衡」之外保留「主备」语义，可以在外层再套一层 fallback 或在外层用 select 做场景切换，形成链式策略组结构。

订阅更新后节点改名是高频事故源：一旦 proxies 里的 name 与 proxy-groups 引用不一致，轻则该成员被跳过，重则配置无法加载。建议为生产环境保留一份最小可启动备份，变更后先在测试配置里验证，再替换主配置。

7 常见坑与不适合 load-balance 的场景

内核不支持或字段过时：报错或静默回退时，先核对 Mihomo / Meta 版本与官方示例，避免照抄旧版社区片段。
把流媒体账号共享与负载均衡混为一谈：多出口可能触发地区与设备策略，需自行评估风险；本文仅讨论技术调度。
列表里混入质量差异极大的节点：哈希或轮询都会让「慢线」稳定占用一部分流量，体感就是「时快时慢」。
UDP / QUIC 行为与 TCP 不一致：游戏、语音、部分视频通话对路径更敏感，若出现异常应优先简化拓扑（减少组嵌套、减少候选数量），而不是继续堆策略。
误以为 consistent-hashing 等于「永远不换节点」：候选变更、连接复用策略、应用侧多连接等都会让你「看到的结果」与直觉略有偏差，要以日志与抓包辅助验证。

8 总结

load-balance 类型策略组让你可以在 Clash Meta / Mihomo 中把流量分配到多个节点，而不是像 url-test 那样长期只锁一个「最快」；strategy: consistent-hashing 侧重可重复的映射与类会话稳定，round-robin 侧重轮流分摊。它与延迟优化不是同一件事：若 KPI 是 RTT，请回到测速与精选节点；若 KPI 是多路利用与粘连平衡，再优先评估本模式。把 rules、proxy-groups 与订阅命名维护清楚，比单纯追求花哨 YAML 更能减少线上故障。

图形化客户端在导入订阅、切换内核与查看日志上通常更省力；相比手工对齐系统代理路径，一体化工具能把「改 YAML → 热重载 → 验证」闭环缩到几次点击之内。若你希望从安装到分流一站完成，可优先通过站内下载页获取适合自己系统的客户端，再套用本文模板做最小增量修改。

最后仍建议保留稳定基线配置：先让 select 与基础规则跑通，再引入 load-balance；一旦异常，可快速回退到已知良好的 YAML，避免在大量并行改动中难以定位问题。

→ 立即免费下载 Clash，开启流畅上网新体验

Clash load-balance 策略组与 consistent-hashing：
多节点会话保持与 YAML 配置