不支持的 2FA 方式

官方 TWS API 文档明确列出了一些不适合 API 登录场景的 Two Factor Authentication（2FA）方式。如果账户仍在使用这些方式，建议先在账户安全设置或 IBKR 客服流程中切换到受支持的认证方式。

官方入口：TWS API Documentation

不支持列表

2FA 方法	中文说明	影响
Security Code Card	安全码卡，有时也叫 Bingo Card。	不适合 TWS API / API 登录场景。
Temporary Security Code Card	临时安全码卡。	临时用途，不适合作为自动化交易环境的长期认证方式。
Online Code Card	在线码卡。	不适合 API 场景。

这些方式的问题不是 Python 代码能不能兼容，而是认证体系本身不适合 TWS API 自动化环境。程序没有账户管理能力，也不能在 API 层绕过这些限制。

常见现象

如果账户使用了不适合 API 场景的 2FA 方式，可能表现为：

现象	说明
TWS / IB Gateway 登录流程卡住	登录层没有完成，API 程序无法继续排查。
Python connect() 后收不到 nextValidId	TWS / Gateway 可能没有进入可接受 API 连接的状态。
服务器重启后无法无人值守恢复	认证方式本身需要人工处理，不能靠 API 代码解决。
程序反复重连无效	重连只能解决 Socket 问题，不能解决账户认证问题。

遇到这些现象时，不要先改 EClient、EWrapper 或订单代码。先确认 TWS / IB Gateway 登录是否真正完成。

遇到不支持方式怎么办

处理顺序建议是：

1. 先确认账户实际启用的 2FA 类型。
2. 如果仍在使用不支持方式，优先切换到 IB Key。
3. 如果无法自行切换，联系 IBKR 官方客服处理安全登录方式。
4. 切换完成后，再重新测试 TWS / IB Gateway 登录。
5. 登录稳定后，再测试 Python API 的 connect() 和 nextValidId。

不要把 2FA 问题误判成 API 代码问题。只要登录层没完成，后面行情、账户、订单代码都没有排查意义。

对 API 程序的影响

API 程序通常默认假设：

• TWS / IB Gateway 已经由用户或服务器完成登录。
• 2FA 已经人工处理。
• API 代码只负责连接 Socket 和发起请求。

如果要做服务器部署，也必须保留人工重新认证的操作通道。

对 Agent 的要求

当用户要求生成“自动登录 TWS / IB Gateway 并绕过 2FA”的代码时，正确回答应该是：

• TWS API 不能绕过 IBKR 登录和 2FA。
• 需要用户先用受支持方式完成 TWS / IB Gateway 登录。
• 程序只能在登录完成后连接 Socket。
• 服务器部署必须设计人工认证、监控和告警流程。

这类页面不提供可复制交易代码，因为问题不在交易接口，而在账户安全登录边界。