和 url-test / fallback 差在哪里
url-test 的核心是：在一组候选里挑出一条当前探测结果较优的出口，并在容差与周期约束下维护这条「当前选中」。fallback 则是按列表顺序做主备，仅当当前成员探测失败时才下移到下一个。二者都是在回答「这一策略组此刻用哪一条链路」的二选一或顺位问题。
load-balance 回答的是另一类问题：在同一策略组生命周期内，能不能让多条连接在多个出口之间分摊，或者按某种哈希规则把相同五元组或相同目标反复映射到同一条出口。你若看到面板里「命中的是同一个组名，但实际连出去的节点在轮换或按站点稳定」，多半是这一类组在与内核调度打交道，而不是 url-test 那种「全组共用一个当前节点」的模型。
规则层仍然只做一件事：把流量送进哪个策略组名。更细的「组内怎么分摊」由内核在运行时调度；若使用订阅合并或覆写，请以图形客户端导出的完整配置为准。与 规则顺序与 MATCH 兜底 的关系，和 url-test 组并无不同——规则没把你送进这个组，后面都是空谈。
两种 strategy：轮询与一致性哈希
round-robin：依次把新建连接分摊到 proxies 列表中的不同成员上，宏观上接近「多节点轮流扛活」。它不保证同一会话或同一站点永远走同一条线；适合你想拉高聚合带宽、或让池子里节点别被单连接压死的主观场景，但可能遇到需要出口 IP 稳定的业务抱怨。
consistent-hashing：按哈希函数把「连接特征」映射到固定桶，再落到某个代理上；Meta 系列实现里通常表现为对同一远端地址（或内核用于哈希的键）倾向使用同一出口，从而获得「粘滞」体验。注意这是内核调度语义，不等于应用层 Cookie 或 TLS 会话必然永不漂移；节点列表若增删导致哈希环重建，映射仍可能变化。
若你的订阅里已经把多个国家拆成不同组，优先在同国同池里做负载均衡；跨国混哈希往往只会把「延迟方差」放大，而不是真正的容灾。
1准备节点列表与扁平结构
确认 proxies: 段里已有可引用的叶子节点名（或可被当作成员的子组名，视客户端合并结果而定）。入门写法保持扁平：一个 load-balance 组直接引用三到十个节点名，避免一开始就 relay 套 load-balance 再套 url-test，排错成本会指数上升。链式双跳仍建议独立阅读 relay 教程，不要与负载均衡语义混在一起理解。
节点名必须与订阅/本地 proxies 完全一致：空格、大小写、emoji 都会导致组加载失败或静默回退，表现成「规则明明指向这个组，却始终走 DIRECT 或其他默认出口」。
2写法 A：round-robin 轮询骨架
将下列骨架中的 NODE_* 换成你的真实代理名，把 POOL-RR 换成想要展示在面板上的组名，再在 rules 中让目标域名或 GEOIP 指向该组。
# Example — round-robin; replace names; rules must point to POOL-RR before being shadowed
proxy-groups:
- name: POOL-RR
type: load-balance
strategy: round-robin
proxies:
- NODE_A
- NODE_B
- NODE_C
rules:
- MATCH,POOL-RR
轮询只影响新连接的分配；已经建立的 TCP 不会因为你在面板里看到「组概念在轮换」而瞬间搬家。浏览器里多标签、HTTP/3、DoH 并行解析都会制造大量短连接，主观感受可能与「理想中的平均带宽」不一致，这属于现象层面的落差，未必能靠单一 YAML 就完全抹平。
3写法 B：consistent-hashing 粘滞骨架
把 strategy 换为 consistent-hashing，其余字段保持同一模式，即可让同一目标更倾向于走同一出口，减轻「刷新一次换一个 IP」带来的风控敏感业务困扰。
# Example — consistent hashing / sticky-ish scheduling for same destinations
proxy-groups:
- name: POOL-STICKY
type: load-balance
strategy: consistent-hashing
proxies:
- NODE_A
- NODE_B
- NODE_C
rules:
- MATCH,POOL-STICKY
若你希望「人工可干预默认出口」，可在外层再套一个 select，把 proxies 写成 POOL-STICKY、单独精品线等；记住最终仍是规则第三列指向那个外层组名。规则与 GEOIP、geosite 的配合方式见 GEOIP / GEOSITE 分流。
4与健康检查的低耦合说明
某些版本在负载组上仍允许附带探测字段，用于在调度前排掉明显 dead 的成员；各字段含义与 url-test 组相同。本文不展开 url / interval / tolerance 的调参叙事，请直接按 健康检查专文 对照：你只需要记住——探测误判与业务侧 reset 仍要先看日志再改参，负载均衡并不会替你消灭坏上游。
5如何验证：面板、连接记录与对比实验
改配置并热重载后，建议并行做三件事：① 在策略组面板确认组类型与成员列表无报错；② 打开连接日志，对同一目标域名多次发起访问，观察 round-robin 下出口是否轮换、consistent-hashing 下是否相对稳定；③ 临时把池子收成单节点对照，排除规则根本没进组这一类「低级误诊」。
若日志显示频繁 connection reset，先用 连接 reset 与时间线 把规则命中与断开点对齐，再决定是换节点还是换策略，而不是盲目加池子数量。
常见踩坑清单
长连接不随调度切换：已建立的 TLS 会话、视频会议、游戏对战等长连接不会因为你把 strategy 从 round-robin 改成 hashing 就立刻迁移；需要断线重连或重启相关应用才有「新调度」机会。
UDP / QUIC：语音、部分游戏与 HTTP/3 走 UDP 路径时，调度与 NAT 行为可能与纯 TCP 观测不一致；以你使用的客户端版本说明为准，遇到异常可先对单业务域名单独指向手动 select 做对照。
列表顺序与「心理主次」：负载均衡组不像 fallback 那样表达「先主后备」；若你要容灾语义，请用 fallback 或 url-test，而不是指望 round-robin 自觉跳过坏线。
订阅覆写打乱命名：远程包若重新定义了同名 proxy-groups，本地 patch 可能与想象的不一致。使用 mixin / 覆写时，请以图形客户端导出的完整合并结果为准，这一点与 mixin 合并教程 描述的一致。
把哈希当作精确风控承诺：一致性哈希是内核调度优化，不提供「合同级」出口固定；关键合规场景仍应用专线或明确的单出口策略。
什么时候不该用负载均衡
当你核心诉求是「坏了就换」「谁延迟低用谁」，应优先 url-test 或 fallback；当你必须「永远手选一条线」做对照实验，用 select。load-balance 适合已经确认池内多节点都可接受，且你希望统计意义上分摊或按目标粘滞的场景。强绑账号的风控业务若对 ASN 极其敏感，往往反而需要收窄池子而不是扩大池子。
合规提醒：请仅在法律与运营商政策允许的场景使用代理；勿利用多出口轮换规避安全验证或违反服务条款。
关于下载：开源仓库适合跟踪 Issue 与提交记录；日常安装包获取请优先使用 本站下载页，与「从哪下客户端」类指引保持一致。
小结
Clash Meta / Mihomo 中的 load-balance 为多出口协同提供了与 url-test 不同的一层语义：round-robin 倾向轮换分摊，consistent-hashing 倾向按目标粘滞。规则层命中正确的 proxy-groups 仍是前提；健康检查参数交给专文，本篇只保留与负载均衡直接相关的交叉引用。把调度目标说清楚后，再与 GEOIP、relay、DNS 叠加，整条链路会远好于在社交群里抄一段不知出处的 YAML。
相比单纯「多节点随便塞给 url-test」，明确自己在要带宽聚合、出口稳定 还是故障转移，会少一半反复试错时间；内核做调度，你仍然要为名单质量与规则真源负责。