Clash/Mihomo 负载均衡会频繁换 IP 吗？三种策略别混用
解释 Mihomo load-balance 的 round-robin、consistent-hashing 与 sticky-sessions，以及登录验证、账号地区跳变时为何更适合固定节点。
先看重点会不会换出口，取决于策略。round-robin 会把请求分给不同节点；consistent-hashing 让相同目标地址使用同一节点；sticky-sessions 还会考虑来源地址，但映射缓存 10 分钟过期。负载均衡不是把一条连接的带宽叠加起来；登录、支付或账号地区敏感时，固定一个 select 节点通常更合适。
网页刚登录又让你验证，IP 查询页一会儿显示香港，一会儿变成日本。节点没有报错，当前策略组却写着“负载均衡”。如果你选它是想把几条线路叠在一起提速，问题可能就出在这个名字带来的误会。
Mihomo 的 load-balance 分配的是请求使用哪个代理节点，不是把一条连接拆到多个节点上叠加带宽。 官方文档只定义了请求如何分配，没有承诺单个下载、视频或游戏连接能获得几条线路的带宽总和。
三种策略，稳定出口的程度不同
load-balance 组可以放入多个节点，strategy 决定新请求落到哪里。Mihomo 当前文档列出三种方式：
| 策略 | 官方定义的分配依据 | 对出口变化的影响 |
|---|---|---|
round-robin |
把请求分配给组内不同节点 | 同一次浏览过程最容易用到多个出口 |
consistent-hashing |
相同目标地址使用同一节点 | 同一目标较稳定，不同目标仍可能走不同节点 |
sticky-sessions |
相同来源地址和目标地址使用同一节点 | 映射更细，但缓存 10 分钟后过期 |
目标是域名时，官方说明 consistent-hashing 使用顶级域名匹配。它约束的是“这个目标分到哪个节点”，不是“这个浏览器从此只用一个出口”。一个网页可能同时连接登录、接口、静态资源和第三方服务等不同目标，它们仍可能被分到不同节点。
sticky-sessions 的 10 分钟是映射缓存有效期。缓存过期不等于第 10 分钟一定强制切换，只表示原有映射不再受到这项缓存保证。组内节点、目标或健康状态变化时，也不能把它理解成永久固定 IP。
为什么登录和支付页面更容易暴露问题
网站是否追加验证，可能同时受 IP、Cookie、设备和请求行为影响，具体规则只有网站自己能确认。负载均衡只能解释“为什么不同连接可能用了不同节点”，不能证明某次验证码或风控就是 IP 变化触发的。
不过，出现账号地区来回跳、重复登录或支付确认中断时，固定出口是一个干净的对照变量。把相关流量临时放到单一 select 节点，只有多次对照都显示问题随多出口出现，才把它列为相关变量；这仍不等于节点质量差，也不能推出网站采用了哪一种风控规则。
验证码或 429 没有随着出口稳定而消失，就应继续检查账号、Cookie、扩展和请求频率。可以对照换代理后验证码变多或提示 429，不要反复切节点和刷新，把限流越撞越重。
“负载均衡”也不会自动挑最快节点
策略组里的健康检查用于判断节点能否对测试地址给出预期响应。测试地址、间隔、超时和 lazy 都会影响检查结果；通过健康检查，只说明这次检查满足条件，不代表目标网站速度最快，也不代表出口 IP 在整个会话中不变。
想按延迟自动选择时，Mihomo 的 url-test 才是另一类策略；想让当前节点失效后再换到可用项，则是 fallback。官方对 fallback 的定义是：当前节点超时时，按节点顺序选择第一个可用项。它会在故障时换出口，但不会像 round-robin 那样主动把所有请求轮流分散。
url-test、fallback 和容差的区别已经展开了自动选择逻辑。低延迟也不等于高带宽，下载或视频慢时还要看持续吞吐、丢包和目标线路，可参考节点延迟低但实际速度慢。
先确认组的真实类型，别只看显示名称
客户端或订阅可以把策略组命名为“自动”“高速”或“智能”，这些名字不能证明它属于哪种类型。真正有意义的是最终运行配置中的 type 和 strategy：只有 type: load-balance 才适用本文的三种分配方式。
需要账号出口稳定时，单一 select 组的边界最清楚：选择哪个节点，就由哪个节点处理流量，直到你手动改选或配置发生变化。需要故障自动切换，可以接受故障发生时更换 IP，再考虑 fallback。多设备路由器确实要把连接分散到多个节点时，load-balance 才与需求相符，但仍要按登录会话能否接受多出口选择策略。
固定 select 后公网 IP 仍然变化，原因就不应继续锁在负载均衡组。节点服务端可能使用多个出口，IP 数据库也可能对同一地址给出不同地区；先核对是否真的是 IP 数字改变，再看节点地区与网站识别不一致。
本文没有对具体机场、客户端界面、节点出口或网站风控做实际测试。能从 Mihomo 官方资料确认的是三种请求分配方式、sticky-sessions 的缓存期限，以及健康检查与自动回退的定义；单个网站为何追加验证，仍需用固定节点对照和该网站自己的提示判断。
资料来源
以下来源于 2026/8/27 复核。版本、支持平台和发布状态以后续官方页面为准。
持续更新
收到新教程，也欢迎纠错
想收到新文章，可以关注 TG 频道；发现下载失效、套餐变化或步骤不一致，请附上页面链接和可公开的截图。不要发送订阅链接、密码或完整账户信息。
读者互动
这篇内容对你有帮助吗？
最新评论
- 正在加载评论……