支持的 2FA 方式

TWS API 官方文档列出了几种可支持的 Two Factor Authentication（2FA）方式。这里的“支持”不是说程序可以自动完成认证，而是说这些认证方式可以用于 TWS / IB Gateway 登录，从而让 API 客户端在登录完成后连接。

官方入口：TWS API Documentation

先分清认证发生在哪里

TWS API 代码本身不处理账号密码和 2FA。认证发生在 TWS / IB Gateway 登录阶段：

用户登录 TWS / IB Gateway
  -> 完成 2FA
  -> TWS / IB Gateway 进入已登录状态
  -> Python / Java / C++ 程序通过 Socket 连接

所以“支持某种 2FA”不是指 EClient.connect() 能自动输入验证码，而是指这种安全登录方式可以配合 TWS / IB Gateway 使用。

支持列表

2FA 方法	中文说明	开发建议
IB Key	通过 IBKR Mobile / IB Key 完成认证。	优先推荐。适合本地开发、TWS 登录和日常维护。
Handy Key	手机认证应用。	可用，但具体体验以账户安全设置为准。
SMS / Text Messages	短信验证码。	可用，但依赖运营商和短信到达速度，不适合追求稳定的服务器场景。
Digital Security Card+ (DSC+)	实体安全卡。	通常面向特定账户或更高安全要求场景，适合有人工运维流程的环境。

推荐选择

对大多数开发者，建议优先使用 IB Key。

原因很简单：

• 不依赖短信网络。
• 操作路径更清晰。
• 适合 TWS、IB Gateway 和 Client Portal 等多种登录场景。
• 排查时更容易判断问题是登录、网络还是 API。

短信虽然在官方支持列表里，但它不适合作为长期服务器部署的唯一方案。服务器部署应假设“有时需要人工重新认证”，并准备远程桌面或运维流程。

不同场景怎么选

场景	建议 2FA	说明
Windows 桌面学习 TWS API	IB Key	手机确认后登录 TWS，最容易排查。
Linux 服务器跑 IB Gateway	IB Key 或账户可用的受支持方式	仍要保留人工重新认证通道。
只偶尔手动运行脚本	IB Key 或短信	短信可用但稳定性不如 App 认证。
多人团队维护	以账户安全策略为准	不要把个人 2FA、密码或恢复码写进代码仓库。
机构级账户	按 IBKR 安全配置和运维流程确认	可能涉及实体安全卡、权限分工和审计。

和 API 代码的关系

2FA 不会出现在普通 TWS API Python 代码中。下面这些代码层面的对象不会处理 2FA：

API 对象	作用
EClient	发起 API 请求。
EWrapper	接收回调。
connect()	连接已登录的 TWS / IB Gateway。
nextValidId	连接握手完成后返回下一个订单 ID。

如果登录卡在 2FA 阶段，Python 代码通常连不上 TWS / IB Gateway，或者无法稳定收到回调。这个问题要先在 TWS / IB Gateway 登录层面解决。

服务器部署注意事项

服务器上跑 IB Gateway 时，2FA 会直接影响自动化稳定性。程序不能假设“服务启动后永久可用”。

风险	正确处理
初次启动需要 2FA	准备远程桌面、VNC 或受控人工登录流程。
每日重启后需要确认	监控 Gateway 登录状态，失败时通知人工。
每周或周期性重新认证	不要让交易程序无限重试下单，先确认登录状态。
多个应用抢登录会话	明确 TWS、IB Gateway、Client Portal Gateway 的使用边界。
误把认证问题当代码问题	先检查 TWS / Gateway 是否已登录，再查 Python 回调。

排查顺序

如果 API 程序突然不能用了，按下面顺序查：

1. TWS / IB Gateway 是否还在运行。
2. 是否仍处于已登录状态。
3. 是否弹出 2FA、重新认证或会话冲突提示。
4. API 设置是否仍允许 Socket 连接。
5. Python 程序是否能收到 nextValidId。

只有前五步都正常，才继续排查行情、账户、合约或订单参数。