Clash Meta 负载均衡策略组怎么设置？一致性哈希逐步教程
你已经会用 Clash Meta（Mihomo 内核）做规则分流，也读过 url-test 与 failover 专文；下一类常见需求是「不只选一个最快节点，而是让多条线路一起干活」。在 YAML 里这对应 type: load-balance 的负载均衡策略组：strategy: consistent-hashing（一致性哈希）把相同目标稳定映射到同一出口，round-robin 则在成员之间轮替分配。本文按步骤写清 proxy-groups 字段、健康检查 url、以及 rules 如何引用组名，并说明与自动测速组的取舍，避免把「均衡」当成「自动选优」的同名功能。
先建立心智模型：负载均衡在做什么
url-test 的核心产出通常是单一当前出口：在候选里比一轮延迟，选一个（再在容差内防抖）。fallback 则是按顺序找第一个可用，像主备接力。load-balance 不一样：它刻意让多条代理同时参与，按策略把不同连接分发到不同成员。你不会只想「这一条线够不够快」，而会问「这几条线怎么分摊才不乱号、不拆session、不把风控惹毛」。因此，搜「Clash Meta load-balance」而不是「断线自动换节点」时，你的真实意图更接近多出口编排，排查思路也该从「连接分配规则」出发，而不是只看 ping。
一句话对照
url-test ≈ 挑冠军；fallback ≈ 排队补位；load-balance ≈ 多窗口同时叫号——但叫号规则由 strategy 决定。
策略算法怎么选：round-robin、consistent-hashing、sticky-sessions
官方文档对三种 strategy 的描述可以概括为：round-robin 把请求轮流分给组内不同节点；consistent-hashing 把相同目标地址的请求固定到同一个节点（目标为域名时按顶级域匹配）；sticky-sessions 则按相同源地址与目标地址的组合映射到同一节点，并带大约十分钟量级的缓存过期。直觉上round-robin 更容易「均分连接数」，但同一网站的多条请求可能落在不同出口 IP 上，对少数站点的登录态、支付风控、游戏大区检测并不友好。consistent-hashing 是你搜「一致性哈希」时最常想要的：它牺牲了一点「绝对平均」，换来按目的地黏住出口，更像 CDN 调度里熟悉的思路。
| strategy | 分配依据（文档语义） | 常见适用 |
|---|---|---|
round-robin |
轮流分配到不同成员 | 希望连接粗略均摊、对出口 IP 是否固定不敏感的一般浏览或下载 |
consistent-hashing |
相同目标地址 → 同一成员（域名按顶级域） | 希望同一站点长期走同一出口，降低会话、验证码、风控抖动 |
sticky-sessions |
相同源 + 相同目标 → 同一成员；缓存过期 | 多应用、多设备出口仍希望「这条业务流」相对黏住时（需结合版本行为验证） |
不要期待「均衡」自动拯救单条慢线路
负载均衡只会让流量按规则分散到你列出的成员；若列表里全是高负载或被封 ASN，分配再漂亮也改变不了上限。瓶颈仍在节点质量与路由，不在策略关键字本身。
第一步：列出可用的 proxies 成员名
load-balance 的 proxies 数组只能引用已存在的节点名或其他策略组名，和 url-test 一样吃字符串完全匹配。合并订阅、本地补节点、或 GUI 改名之后，最容易出现的故障是「保存成功但组内全灰/全红」——十有八九是名字与 proxies: 段落不一致。建议先在客户端里展开节点列表，复制**最终渲染名**到 YAML；若你把机场多套模板互相覆盖，请再在「配置文件原文」里搜一遍确认，不要只相信面板上的缓存标签。
成员至少两条才有「均衡」意义；只有一条时等价于固定出口，仅多了一层健康检查壳子。若你其实只想自动测速，请回到 url-test 专文，不必硬上 load-balance。
第二步：在 proxy-groups 中声明 type 与 strategy
新建一段策略组，将 type 设为 load-balance，并按上文选择 strategy。健康检查字段与同文件里其他动态组类似：url 提供探针地址，interval 控制探测周期（秒）。部分配置里可设 lazy: true，含义与你在 url-test 里见到的类似——在组**真正被用到之前**可以推迟全员探测，减轻冷启动流量；是否写入取决于你的客户端版本是否透传该字段到内核。
# Illustrative load-balance group — replace proxy names with yours
proxy-groups:
- name: LB-GLOBAL
type: load-balance
strategy: consistent-hashing
proxies:
- 节点甲
- 节点乙
- 节点丙
url: http://www.gstatic.com/generate_204
interval: 300
# lazy: true
若你暂时不写 strategy，应以你所用内核版本的文档默认行为为准；教学上仍建议**显式写出**，这样六个月后再打开文件仍能读懂当时的意图。需要把同一批节点既做「自动测速 finalists」又做「均衡池」时，可以拆成两个组名，让一个 url-test 组嵌进另一个结构里，但避免循环引用——嵌套越深，越要用连接日志验证真实命中链。
第三步：校准健康检查 url 与 DNS
探针 url 不是摆设：失败的成员可能在调度中被判不可用，进而把所有压力挤到剩余节点上，表现为「均衡组突然只走一条线」。这与 url-test、fallback 共用同一种心智：url 必须是轻量、可达、且**走代理路径时不易被恶意拦截**的地址。常用 generate_204 类端点即出于此考虑。
若探针全灭，请先排除本机侧问题：系统时间、是否混用了系统代理、TUN 与浏览器扩展是否打架、以及 DNS 是否把探针域名解析到异常结果。《已连接却无网：DNS 与 fake-ip》 里的排查顺序往往比「狂加进口节点」更快见效；负载均衡只是把故障在成员之间**重新分配**，并不会治好解析层级的硬伤。
第四步：在 rules 里挂载策略组名称
策略组写得再正确，只要 rules 没引用它的 name，业务流量就不会走进去。规则表仍是从上到下首次命中；这与负载均衡内部如何把连接分给成员是两层逻辑——前者决定「这一类流量进哪个组」，后者决定「进组之后走哪条出口」。实务上，你可以把 LB-GLOBAL 用在泛用浏览器出口上，也可以只为下载域名单独写一行 DOMAIN-KEYWORD 或远程规则集引用，其余流量继续走直连或地区专用组。
# Example rules fragment — order matters; expand for your policy
rules:
- DOMAIN-SUFFIX,example.com,DIRECT
- GEOIP,CN,DIRECT
- MATCH,LB-GLOBAL
使用 rule-providers 时，注意远程集默认插入位置与优先级：合并结果若把你的 MATCH 提前到意外位置，会出现「我以为走了负载均衡，其实在更靠前就被别的组截胡」。合并后建议在客户端的「连接日志 / 匹配规则」视图里抽查几条真实域名的命中行，而不是只看 YAML 表面顺序。
挂载前自查
rules中的组名与proxy-groups.name字符级一致；- 若策略组嵌套，确认不存在互相指向的闭环；
- 对关键业务单独开组，避免「一个大杂烩 LB」难以调参。
与 url-test / fallback 如何配合
常见架构是：LB-* 负责**把流量摊到多条平行好线**，而 FALLBACK-* 负责**这条平行池整体挂掉时跳到下一层**。你也可以在 load-balance 的 proxies 里直接填若干 url-test 组的符号名，让每个地理池内部自动挑延迟，再由负载均衡在池与池之间散列——复杂度上升，但适合「多地区多活」订阅。每加一层，请在文档或注释里写一句「为什么」，否则三个月后的你会看不懂自己当年的 YAML 雕塑。
反过来，如果你只是想让「浏览器自动用当前延迟最低的那一个节点」，没有多线并发诉求，那就不要强行 load-balance：url-test 更贴近目标，日志也更直观。搜索词里同时出现「负载均衡」和「故障切换」时，往往是两篇文章都要读：一篇解决分摊，一篇解决主备——本页专注前者。
排障：为什么感觉「没在均衡」
第一类症状是始终只看见一个出口 IP：检查 strategy 是否为 consistent-hashing 且你长时间访问同一顶级域——这在设计上是「正确的黏性行为」，不是 bug。第二类是站点行为怪异、频繁掉登录：若你用的是 round-robin，尝试改成一致性哈希或粘性会话，让同一业务域名固定到同一成员。第三类是短暂卡顿后全挤一条线：回到健康检查与 DNS，确认失败成员是否被暂时摘除。第四类是规则命中错了组：用客户端内置的匹配信息核对，而不是凭记忆猜 YAML。
升级内核大版本后，偶尔会有字段默认值或策略细节微调，建议在发行说明里搜 load-balance 与 strategy。若你与 GUI（如 Verge 系列）混用，保存时观察是否把稀疏字段洗掉——必要时用「仅编辑器模式」锁原文。
常见问题
负载均衡与 url-test 会不会冲突？
不会「冲突」，但会「叠乘复杂度」。同一流量只会按规则进入一个策略组；进入负载均衡组后，再由内核按策略切分连接。避免对同一域名在规则层反复指向多个自动组，否则调试时很难从日志还原真实路径。
一致性哈希具体按什么字段算？
以官方文档为准：目标地址；若目标是域名，使用顶级域名匹配语义。不要把「我以为的子域」当成独立桶，除非你验证过当前版本实现与文档一致。
机场订阅已经自带均衡组，还要自己写吗？
若供应商已提供经过验证的 load-balance 组且命名清晰，直接复用即可；只有在名字与分流意图不匹配、或你需要和本地直连规则精细咬合时，才在本地补丁里二次包装一层自己的组名，便于 rules 阅读维护。
实操清单
proxies与proxy-groups.proxies名称完全一致；- 为用途显式选择
strategy，并理解 round-robin 与哈希的差异； url可解析、体积轻、在政治/路由意义上对你的节点现实可达；rules中有明确行引用该组，且顺序符合预期；- 升级或换 GUI 后复查 YAML 是否被静默改写。
写在最后
不少泛用工具把「策略组」藏在二级菜单里，要么只暴露开关不解释 strategy，要么生成的远程配置把负载均衡与自动测速混在一个名词下——出问题时你只能对着订阅提供者的模板猜。把一致性哈希、轮询、健康检查与规则挂载拆清楚，你才能判断现象是「分配逻辑」还是「节点/DNS」层级的问题。
Clash 的路线是让你直接落到可读、可版本化的 YAML：同样的 load-balance 声明在桌面、NAS、轻量服务器的 Meta 内核上语义一致，配合规则提供者与本地覆写，可以把「多出口编排」从玄学参数变成可复核的工程配置；GUI 负责提效，但不剥夺你对关键字段的控制权。
如果你也希望在**看得见的配置**上把负载均衡跑稳，而不是反复试错订阅模板，不妨试试 免费下载 Clash，用本文的结构对照你自己的 proxy-groups 与 rules 走一遍验证。