机场负载均衡会影响登录吗？用固定节点检查出口保持
打开测速网站很快，进入常用网站却反复要求验证，问题可能出在账号、浏览器、网站风控，也可能与代理分组的选择方式有关。选机场时，如果需要长时间编辑文档或保持登录，除了速度，还应测试一次完整会话。
本文适用于使用 mihomo 内核、且配置中确实存在 load-balance 分组的客户端。分组名字写着“智能”或“均衡”并不足以判断类型，先查看实际配置或客户端显示的策略。
先看三种策略怎样选节点
mihomo 官方说明列出了以下策略：
| 策略 | 选择依据 | 试用时应观察什么 |
|---|---|---|
| round-robin | 在组内节点之间轮询分配请求 | 新连接是否进入不同节点 |
| consistent-hashing | 同一目标地址映射到同一节点 | 同一业务的多个目标域名是否走不同路径 |
| sticky-sessions | 相同来源和目标使用同一节点，缓存期限为十分钟 | 重新连接或等待后是否仍符合你的会话需求 |
官方还注明：目标为域名时采用顶级域名匹配。这里的“同一节点”不是永久固定出口 IP 的承诺；服务端出口、节点可用性和连接复用都可能影响观察。页面中的多个请求也不一定每次重新选节点。
用三组对照缩小范围
先备份当前配置，选择一个允许你测试的常用业务。避免反复输入密码或连续触发验证码；只做正常阅读、刷新和保存操作。
- 固定节点 A：在手动选择组中选 A，关闭并重新打开业务页面，按正常流程使用一段时间。
- 固定节点 B：只换节点，其余设备、网络、浏览器和业务操作相同。
- 原负载均衡组：恢复原策略，重复相同操作，同时查看客户端连接记录中各目标使用的节点。
如果仅均衡组出现异常，这是继续检查策略和目标分流的线索；它不能单独证明网站绑定了 IP。若 A、B 和均衡组都异常，应继续排查账号状态、Cookie、扩展和网站侧故障。
记录业务路径，别只看一个查 IP 页面
建议用下表保留证据。IP 检测页面只能说明访问它的那条路径，不代表文档、登录接口和上传接口也使用同一出口。
| 时间与模式 | 业务动作 | 相关目标与节点 | 页面结果 |
|---|---|---|---|
| 固定 A | 打开文档、等待、保存 | 从连接记录读取 | 成功或具体报错 |
| 固定 B | 重复同一动作 | 从连接记录读取 | 成功或具体报错 |
| 均衡组 | 重复同一动作 | 标记是否更换节点 | 成功或具体报错 |
对外提交记录前删去账号标识、Cookie、订阅链接和带令牌的 URL。需要客服确认的是“该套餐与该节点能否满足会话需求”，而非让客服保证所有网站都免验证。
怎样算完成验收
先写下自己的验收条件，例如一次正常编辑和保存、页面闲置后再操作、重开客户端后重新连接。条件是你的需求，不是行业统一标准。
选定策略后，在常用时段复测并确认原业务正常，再恢复不需要改动的配置。若固定节点明显更适合这项工作，可以仅让相关业务使用该选择组；应按客户端支持的规则方式设置并备份，避免改写整份订阅。
有帮助的机场推荐，应说明适用任务和测试条件。单次测速最快的策略，未必就是长期会话最合适的策略。
评论