跳转到内容

管理多个会话

Client Portal API 的多会话问题,本质上是同一个 IBKR 用户名不能同时拥有多个 active brokerage session。它可以有基础 Web 会话,但交易会话只能有一个。

场景结果
同一用户名已登录 TWS,再让 Client Portal API 初始化 brokerage session可能出现竞争会话,或者其中一个交易会话被断开。
同一用户名已登录 IBKR Mobile,再用 Gateway 登录交易功能移动端和 API 可能互相竞争。
程序重启后旧 Gateway session 没退出干净新 session 可能遇到认证状态不一致。
多个后端服务共用同一用户名容易相互抢占 brokerage session,订单和行情状态难以追踪。

/iserver/auth/status 中的 competing 表示该用户名存在竞争 brokerage session。它不是普通网络错误,而是会话模型冲突。

处理顺序:

  1. 确认是否还有 TWS、IB Gateway、IBKR Mobile 或 Client Portal 在使用同一用户名。
  2. 如果需要 API 优先,先从其他平台正常 Log Out。
  3. 如果必须并行使用,考虑创建第二个用户名。
  4. 再重新初始化 brokerage session。

IBKR 支持创建额外用户名,用于把不同平台的交易会话隔离开。例如:

用户名用途
主用户名人工登录 Client Portal 或 TWS。
API 用户名Client Portal API 或自动化程序。
Paper 用户名Paper Trading 测试。

需要注意:行情订阅通常是按用户名计费或授权的。第二用户名不一定自动继承主用户名所有市场数据权限。

第二用户名也不等于第二个账户。它只是另一个登录凭证,能看到哪些账户、能交易哪些产品、能读取哪些行情,仍取决于 IBKR 后台授权和账户配置。

目标建议
人工看盘 + API 读报表尽量用非 /iserver endpoint,避免占用 brokerage session。
人工 TWS 下单 + API 交易使用不同用户名,避免互相挤掉交易会话。
API 只做 Paper 测试使用 Paper 专用用户名。
API 做服务器长期运行设计会话监控、重新认证提醒和竞争会话告警。

如果程序检测到 competing=true,不要自动无限重试。更好的处理方式是停止交易动作、记录告警、提示人工确认由哪个平台接管 brokerage session。

认证日志至少记录:

  • 请求的 endpoint
  • authenticated
  • connected
  • competing
  • message
  • 请求时间
  • 服务实例名称

不要记录账号密码、2FA 内容、完整 cookie、token 或账户敏感资产信息。