load-balance 解决什么问题、和 url-test 差在哪

在 Clash 系列内核里，策略组（proxy-groups）回答的是「这条流量最终交给哪一类出站逻辑」。select 把决定权交给你在界面里点选的那一条；url-test 周期性对探针地址测延迟，试图让整组长期挂在相对更快的那条上；fallback 则按列表顺序做健康检查与主备切换。与此不同，load-balance 的语义是在池内成员之间分散连接负载：适合多线程下载、并发抓包、需要把连接铺到多条中继上的场景，而不是「每次打开网页都希望毫秒数第一名」的路径优化。

许多检索词会直接命中「负载均衡」四个字，但心里想的其实是自动选最快——这时更值得读 姊妹篇里的 url-test 段落。若你把两者混用，会出现典型错觉：配置了 load-balance 却在抱怨「为什么没有永远走延迟最低的节点」。反向情况也同样成立：只用 url-test 去扛超高并发上传下载，单体节点很快被提供商限速或拒绝大量并行会话，与其期待魔法，不如正视「分散连接」与「优选 RTT」是两种目标。

在Windows 11 桌面场景中，常见于以下动机：你希望某个「下载专用」策略组名下的流量在三条线路间铺开；或你希望工具链里大量短时 TCP 会话不要都打穿同一 POP。做到这一点的最短路径往往不是继续堆更贵的单线，而是在Mihomo 内核里把那一个proxy-groups条目的 type 改成 load-balance，并选对 strategy。下文默认你已在 CfW 中启用 Meta/Mihomo 路线且配置能被当前内核解析；若仍在极旧构建上反复报字段错误，应优先升级内核或迁移到仍在发版的客户端壳层。

ℹ 与站内文章分工：本文只讲 Clash for Windows + YAML 内核编辑器 下的 load-balance；Win11 CfW 图形界面测速与切组帮你建立 Proxies 心智模型；url-test／fallback 专文覆盖自动选快与主备链；若你要 TUN、Strict Route 与 Party 壳的菜单路径，请另读 Mihomo Party 系列，不在此重复截图级操作。

动手前：Mihomo 内核、Profile 与命名冲突

打开编辑器之前，先完成三件核对。第一，Profiles 里正在使用的那份机场配置必须处于激活状态，且托盘或主窗口显示核心已运行；否则你改的是磁盘上的文本，却未必是内存里那份。第二，确认你的 Clash for Windows 实际加载的是 Mihomo（Meta）内核——load-balance 的 strategy 行为以当前内核文档为准，旧版闭源核心若直接忽略未知字段，会在界面上表现为「保存成功但行为像普通组」。第三，给新组起一个不与订阅自动段落冲突的名字：许多远程配置会生成诸如 PROXY、♻️ 自动选择 之类条目，若你本地新增同名组，轻则合并失败，重则覆写顺序难以排查。

还要提前接受一个事实：若你的整份 config.yaml 完全由订阅 URL 每次拉取覆盖，那么你在本地手写的 proxy-groups 可能在一次「更新订阅」后消失。长期方案通常是：把机场下发当作基础，再用 provider 覆写、patch、或拆出本地 include 文件做增量合并——这部分因机场工具链而异，不在此展开成品牌教程，但你在排障时要优先问一句：「我改的文件是不是下一次更新还会被冲掉？」若答案是肯定的，应先把合并策略定下来，再谈负载均衡细节。

最后，准备一份节点英文别名列表：YAML 的 proxies 小节里每个 name 必须与 proxy-groups 中 proxies 数组引用的字符串完全一致，包含大小写、空格与 emoji。许多新手在这里卡住，是因为复制了界面显示名，却与文件里的 name 差了一个不可见字符。若你不确定，可在编辑器里全文搜索该节点在 proxies: 下的定义块，再原样粘到组内。

Clash for Windows：从 Profiles 进内核编辑器的顺序

经典 Clash for Windows 把「当前工作配置」挂在 Profiles 选项卡。实测可在该列表里选中你的机场 profile，然后使用与编辑相关的入口（不同小版本可能显示为编辑图标、右键菜单或「在文件夹中打开」旁的文本编辑）进入内核可读的同一份 YAML。若你更习惯外部编辑器，也可以从配置目录直接打开对应文件，但务必保证 CfW 保存与重载时指向的是同一路径，避免出现「磁盘已改、界面未载」的双份真相。

建议的操作节奏是：先备份整份 YAML（复制为带时间戳的副本），再在 proxy-groups: 段落附近动手。编辑时保持缩进用空格、列表项前短横线后有空格，这是避免解析失败的基本功。改完后不要急于关窗，先执行一次保存，再回到 CfW 主界面观察是否有红色报错条；若内核拒绝启动，优先回滚备份，再二分查找是哪一段 YAML 破坏了结构。

与「只点 Proxies」相比，这条路径的心智负担更高，但回报是：你能只改一个组的类型，而不被图形壳的预设卡片限制。对于已经在 Win11 上稳定使用 CfW 的用户，这是把高级策略落盘的最短通道；若你长期厌恶 YAML，可评估 Verge Rev 等壳层的覆写 UI，但那就属于另一条产品链的叙事，本文保持 CfW 口径。

可照抄的 proxy-groups：type、strategy、proxies

下面是一段结构正确、需替换名称的示例：把 MY-LB-POOL 换成你的组名，把 node-a、node-b 换成 proxies: 小节里真实存在的 name。strategy 在 Mihomo 系常见选项包括 consistent-hashing 与 round-robin：前者更倾向「同一目标地址落在相对固定成员」，后者更倾向「在成员间轮换」；具体可用值以你当前内核版本说明为准，若保存时报未知字段，应回去核对发行注记而非硬猜拼写。

proxy-groups snippet 
proxy-groups:
  - name: "MY-LB-POOL"
    type: load-balance
    strategy: consistent-hashing
    proxies:
      - node-a
      - node-b
      - node-c

若你更关心「把连接尽量均匀摊开」而不强调目标维度的一致性，可以把 strategy 换成 round-robin 做对照实验。无论哪种策略，都要意识到：池里若有一条质量差的成员，它仍会承接一部分连接，除非你在 health-check 语义或其他层把它摘掉——这与 fallback 那种「顺位跳过失效项」的主观体验不同。实践上很多人会先精简池子，只留下延迟与丢包在同一量级的三至五条，再上负载均衡，而不是把整份订阅上百节点无脑塞进来。

也可用同一模式嵌套：load-balance 组的 proxies 列表里除了裸节点名，也能写其它策略组名，从而先让上游完成地区或手选，再在子层做会话分散。嵌套越深，调试越依赖 Connections 日志；初学者建议先用「扁平池」验证负载确实被铺开，再加入嵌套以降低认知负荷。

把规则接到你的新组名上

光有组不会自动接管流量：rules: 里的第三列必须出现你的组名字符串，或由上层的默认 MATCH 链路间接引用到它。最典型的写法是把某个域名后缀或 Geo 规则指向 MY-LB-POOL。注意规则从上到下匹配——若前面早有更泛的条目把同类流量送去了别的组，你在后面新增的负载均衡规则可能永远不会被执行。调校时建议对照 规则分流最佳实践，先画一条从域名到组名的路径，再保存。

rules example 
rules:
  - DOMAIN-SUFFIX,large-cdn.example,MY-LB-POOL
  - MATCH,MY-LB-POOL

以上第二行仅作演示：把「兜底」直接绑到负载均衡池在真实机场配置里可能过于激进，更多时候你会让 MATCH 仍指向一个手动 select 组，只在下载或特定进程相关域名上使用 load-balance。关键原则是：业务上需要会话粘性的站点（登录态、金融、部分 API）不要与大杂烩负载池混在同一规则里，除非你已理解哈希策略如何影响出口切换。

保存、重载与 Connections 验证

保存 YAML 后，回到 Clash for Windows 触发一次配置重载（具体按钮随版本在 General 或 Profiles 附近）。成功时，Proxies 里应出现新组名，且类型行为符合「自动分散」而不是手动点选。若界面仍显示为可选手动组，多半是你其实编辑了未被激活的 profile，或内核未能解析该段 YAML 从而回退到默认呈现。

验证阶段不要只看延迟数字：打开 Connections，用浏览器或下载工具制造多个并行连接，观察若干秒内不同 TCP 会话是否落在不同成员上。若所有连接仍钉死在同一条出口，优先检查规则是否真的命中该组、是否有下游组再次覆盖、以及应用是否走了系统代理/TUN 以外的旁路。若只有部分应用异常，还要怀疑分流对象是否绕过了 Clash（见 mixed-port 与系统代理 相关说明）。

这一验证思路与 图形界面教程里强调的「看日志再下结论」一致，只是本文目标从「选节点」换成了「确认分散是否发生」。对于需要科学对照的人，可以临时把组改回 select 单点，确认业务本身无独立故障，再切回 load-balance，避免把应用层 TLS 问题误判为策略组类型无效。

常见坑：订阅覆写、脏节点、UDP 与加密站点

第一类坑是远程配置把本地修改冲掉，上文已提。第二类是脏节点混池：负载均衡不会替你「智能避开慢的那条」，只会按策略分配份额；若成员之间延迟差一个数量级，体感可能是「忽快忽慢」而不是「整体更快」。第三类与 UDP、游戏或语音相关：不同节点对 UDP 支持差异很大，分散后可能放大丢包感知，必要时为游戏单独保留 select 或 url-test 组，勿与下载池共用规则。

第四类与安全站点有关：银行、企业 VPN、以及对出口 IP 漂移敏感的 SAML 登录，往往假设客户端 IP 在长会话内相对稳定。哈希策略能减少一部分抖动，但不等于合同级别的「固定出口」。若你为此类域名误配了负载均衡，很容易出现偶发跳转登录或风控提示——这不是 Clash 「坏了」，而是你把它用在了不匹配的风险模型里。

⚠ 合规提醒：请只在你被授权的网络与账号环境中使用代理与负载策略；本文为技术说明，不涉及任何绕过管控或侵犯他人权益的用法。提供商条款、公司法务要求与当地法规始终优先于个人调参偏好。

常见问题

界面里还能看到 load-balance 组里面的「当前节点」吗？

可视化客户端通常仍会显示某种「代表项」或子成员列表，但语义上它不是纯手动锁死。要以 Connections 实测为准，而不是死记卡片高亮。

可以把机场自带的「自动选择」直接改成负载均衡吗？

技术上可以改写同名组的 type，但若该组由订阅每次重生，你的改动无法持久。更稳妥是新建一个独立组名，再在规则里显式引用它，避免与提供商命名更新打架。

负载均衡能否提升单线程测速条上的「 Mbps 数字」？

单线程往往仍受单条 TCP 路径限制；负载均衡更多改善的是多连接叠加时的总吞吐或把压力摊到多条会话上。若你只有单连接测速需求，优先期待线路质量本身，而不是策略组类型魔法。

安装与订阅 baseline：Windows 11 安装 Clash for Windows；图形测速与模式：延迟测速与策略组界面教程；自动选快与主备：url-test 与 fallback 实配；日志排障：timeout 与 TLS 入门。五篇文章串联成「能装、会点、会写、会查」的 Win11 CfW 学习链。

结语

把 Windows 11 上 Clash for Windows 的某一个 策略组切成 load-balance，本质是承认：你要的是连接级分散而不是延迟榜第一名。按 Profiles → 内核编辑器 写入 proxy-groups、选对 strategy、用 规则第三列把目标流量喂进该组，再用 Connections 做多连接复核，这条链路就闭合了；需要 url-test／fallback 精细字段时回到姊妹篇即可，不必在一篇里混写所有类型。

停更或闭源的旧桌面壳层，常见痛点是：YAML 能力暴露不完整、与新版 Mihomo 字段脱节、以及把「策略类型」藏得太深，用户只能在外围点按钮却改不了底层语义。相较之下，Clash V.CORE 所强调的发行思路，是把可持续更新的内核与清晰可得的客户端对齐到同一套文档语言里——你在 CfW 里学会的 load-balance 写法，可以迁移到仍在维护的壳与规则链路上，而不是锁死在一份historic 二进制里。

→ 到本站统一下载入口获取与当代 Mihomo 生态对齐的客户端，在继续写规则、负载与分流时，先有可验证的底座，再迭代你的 Win11 桌面临场配置。