Client Portal Gateway 限制

Client Portal Gateway 不是一个可以随便部署给任意远程浏览器访问的公共 API 服务。它的设计目标是让同一台电脑上的程序通过 Gateway 访问 Client Portal API。

官方限制

限制	中文解释
同机登录	用户必须在运行 Gateway 的同一台机器上通过浏览器登录认证。
同机请求	API endpoint 调用应从 Gateway 已认证的同一台机器发出。
不支持部分路径	以 `/gw/api`、`/oauth`、`/oauth2` 开头的 endpoint 不支持通过 Client Portal Gateway 使用。
不能自动登录	个人账户没有官方机制自动化 Gateway brokerage session 登录。
至少每日重新认证	Gateway 会话至少每天午夜后需要重新认证一次。

Gateway 默认是给同一台电脑使用的认证桥。把它直接暴露到公网会带来几个问题：

问题	风险
认证页面暴露	外部网络能访问登录入口，安全风险显著增加。
自签名证书	浏览器和 HTTP 客户端会遇到证书警告或证书校验失败。
session 绑定	登录、请求、会话和浏览器环境之间有同机假设。
重新认证	每日重新认证和 2FA 仍需要人工处理。
支持边界	出现异常时，IBKR 支持可能要求回到官方支持的同机使用方式排查。

服务器并非完全不能运行 Gateway，但要把它当作“有图形登录和人工认证要求的本地进程”来管理，而不是普通无状态 REST 服务。

更稳妥的分工是：

场景	建议
桌面学习和调试	Windows 或 macOS 电脑运行 Gateway，浏览器登录。
服务器模拟账户调试	服务器需要图形环境、浏览器、人工 2FA、端口保护和日志告警。
面向用户的公开产品	不直接让用户访问你的 Gateway；应设计自己的后端和权限层。
长期生产交易系统	优先评估 TWS API / IB Gateway、官方 OAuth Web API 或机构级接入方式。

Client Portal API brokerage session 如果一段时间没有请求，会超时。官方文档建议定期调用 /tickle 保活，常见做法是大约每分钟调用一次。即使有保活，也不能绕过每日重新认证和 IBKR 的登录安全要求。