跳转到内容

日志文件

TWS API 的很多问题,单看代码或界面提示很难判断原因。日志文件的作用,是把“客户端到底向 TWS / IB Gateway 发送了什么、TWS / IB Gateway 又返回了什么”记录下来,让开发者和支持人员能按时间线还原一次请求。

官方文档把日志放在故障排查章节,是因为它通常不是第一步,而是在问题可以复现、错误回调已经收集、代码参数已经核对后,用来确认底层通信细节。

日志适合回答这些问题:

  • 程序有没有真正把请求发给 TWS 或 IB Gateway。
  • 请求参数和程序里以为发送的参数是否一致。
  • TWS 是否返回了错误码、警告、拒单原因或权限提示。
  • 多个客户端连接时,哪个 clientId 发出了哪条请求。
  • 订单、行情、账户请求是否已经进入 TWS API 消息流。

日志不适合替代业务判断。比如“策略为什么亏损”“订单为什么没有按预期价格成交”“某个第三方库应该怎么改代码”,这些通常要回到策略逻辑、交易所规则、行情权限、订单类型和程序实现本身来分析。

在打开大量日志之前,建议先按这个顺序确认:

  1. 在 TWS 里手动尝试同类操作。TWS 本身看不到的数据或不能提交的订单,API 也通常拿不到或提交不了。
  2. 用最小脚本验证连接,例如 reqCurrentTime()
  3. 确认错误回调已经打印出来,尤其是 error()orderStatus()openOrder()execDetails()
  4. 确认 hostportclientId、账户类型、行情权限和交易产品都正确。
  5. 问题能够稳定复现后,再打开对应日志并重新操作一次。

这样做的好处是日志更短、时间点更清楚,也更容易判断问题是来自 API 通信、TWS 设置、账户权限,还是程序自身逻辑。

类型中文解释常见用途
TWS / IB Gateway 日志客户端平台自己的运行日志排查登录、连接、平台状态、通用报错
API 日志API 应用和 TWS / IB Gateway 之间的通信记录排查请求参数、返回消息、错误码、订单通信
Debug 日志更详细的平台调试日志排查复杂平台问题或支持人员要求的场景
导出后的日志从 TWS / IB Gateway 中解密导出的可读日志本地阅读、提交给支持或对照消息编号

API 日志比普通 TWS / IB Gateway 日志更聚焦,因为它只记录 API 消息;但它也不会包含所有平台诊断信息。因此真正排查时,经常需要同时知道“API 日志”和“平台日志”的区别。

官方说明中,日志保存在用户电脑上,只有用户主动上传或导出时才会发送给 Interactive Brokers。日志也不是永久保存,通常会循环保留最近 7 天,也就是当天加前 6 天。

Windows 上常见设置目录是 C:\Jts 下的用户子目录;macOS / Linux 常见为 IBJts 相关目录。实际位置可以在 TWS 或 IB Gateway 中查看,后面的“Interactive Brokers 日志位置”会专门说明。

因为日志可能包含账户、订单、连接、行情或请求参数信息,处理日志时要当作敏感文件:

  • 不要直接把完整日志发到公开论坛。
  • 对外展示日志或界面状态前,隐藏账户号、用户名、订单编号和资金信息。
  • 如果开启了 “Include Market Data in API Log”,API 日志会包含更多行情数据。
  • 删除旧日志前,先确认问题还能复现,避免把关键证据删掉。

当你准备看日志或提交问题时,建议同时记录:

信息为什么重要
发生时间方便在日志中定位请求前后几秒
TWS / IB Gateway两者界面、路径和行为可能不同
模拟账户或真实账户端口、权限、风控提示可能不同
clientIdAPI 日志文件名和消息来源会用到它
请求类型行情、历史数据、账户、下单、撤单的排查方向不同
错误码和错误文本先看回调,再对照日志
最小复现代码排除框架、策略和第三方库干扰

这个目录会按日志生命周期展开:

子页主要解决的问题
API 日志如何启用只记录 API 通信的日志,以及文件名如何对应 clientId
如何启用 Debug 日志如何为 TWS / IB Gateway 打开更详细的平台调试日志
Interactive Brokers 日志位置如何找到登录会话对应的用户日志目录
如何删除日志日志过大或需要重新复现时,如何清理旧日志
上传日志按支持要求把日志上传给 IBKR
导出日志将本地加密日志导出为可阅读文件
读取导出的日志对照消息编号理解 API 请求与返回方向

日志不是为了把排查变复杂,而是为了让问题有证据链:先复现,再记录,再对照请求、回调和 TWS 行为。