负载均衡能叠加机场网速吗？多节点与单连接下载区别

启用Mihomo的负载均衡，不代表机场节点的网速能直接相加。它可以按策略把不同连接交给不同节点，但不会仅凭这个开关，就把一条下载连接拆成多条线路同时传输。几辆出租车能分别接客，不代表一位乘客坐三辆车就能提前到家。

先看它怎样处理一条连接

当前实现在建立TCP连接时，先按策略选出代理，再交给该代理连接目标。

据此可以理解，这个组负责选择连接出口，而不是自动进行单连接的多线路带宽聚合。因此，即使假设两个候选分别标称100Mbps，也不能直接推导出一次下载能达到200Mbps。标称值本身还需要结合实际条件核对。

三种策略，分配方式不同

官方负载均衡文档列出以下策略。表中按未自定义哈希键的情况解释：

策略	可以怎样理解
round-robin	将请求轮流分配给不同候选
consistent-hashing	按目标地址映射到相应节点
sticky-sessions	相同来源和目标在缓存期内使用相同节点

当前文档说明，黏性会话的缓存为10分钟；哈希键也可以通过额外配置调整。所以不能只看组名叫“均衡”，就认定每个网站、每个时刻都平均分到所有节点。实际应核对客户端版本、策略及最终配置。

同一目标的多条请求仍落到一个节点，可能正是哈希策略的作用，不一定是设置坏了。

多连接任务可能分担，仍要看实际结果

若任务确实建立了多条连接，分配策略又允许它们走不同候选，就可能由多个节点分别承担连接。但这与让一条已有连接同时经过几个节点是两件事。

节点数量也不是吞吐量计算器。是否改善，应该比较同一任务的结果；单连接速度与多个连接的总速度不能直接混为一谈。别把列表里的十面国旗，当成已经装好的十台涡轮增压器。

用四步确认是否适合自己

1. 先备份配置，记下当前策略与候选节点，明确要改善的是单个下载还是多个并行任务。
2. 检查目标请求是否真的命中这个组，避免调整了一个没有被规则使用的组。
3. 固定设备、文件和接入环境，先用单一节点作对照，再只改变策略。
4. 重新发起连接，查看各连接实际选中的节点，分别记录单连接表现与整体完成时间。

这些是机制分析与核对建议，不是本站测速结果。已有长连接也不适合只凭组设置变化来判断新策略是否生效，应以实际连接记录为依据。

只想自动选一条合适线路呢？

先比较本站的自动测速与故障切换说明。若问题是某个下载始终很慢，则按速度排查指南定位瓶颈，再决定是否需要复杂策略。

作者：仓老师机场观察

资料来源

资料核对日期：2026年10月30日。依据官方文档与当次Meta分支实现整理；具体功能以所用版本为准，本文没有提供节点实测成绩。

• MetaCubeX：负载均衡：页面标注2026-10-22。
• MetaCubeX/mihomo：loadbalance.go：当次查阅Meta分支实现。