处理连接中断与请求限流。
让 API 恢复终端，让客户端有序运行。
分步文字说明
- 0:00
处理连接中断与请求限流。
本教程介绍如何处理 MT5 连接中断和请求限流：等待 API 恢复、重新订阅行情，并安全地重试读取请求。演示使用模拟账户的真实响应。
- 0:18
先检查现有会话。
打开 mt5.mrpc.pro，保留 API 密钥和已保存的终端 id。录制的 ConnectState 响应显示 Connected，isConnected、isAlive 和 apiIsAlive 都是 true，表示终端正常。浏览器断线或一次请求失败，并不意味着需要创建新终端。
- 0:45
让自动恢复机制完成工作。
MetaRPC 会监测终端健康状态，并在需要时自动尝试恢复符合条件的活动会话，保留原有终端 id。客户端应暂停受影响的操作，给服务恢复的时间，而不是反复调用 Reconnect 或 ConnectEx。间隔检查状态，再通过 AccountSummary 确认账户可读取后恢复操作。恢复需要时间，不会在每次请求失败后立即完成。
- 1:23
根据原因采取行动。
主动断开、会话过期、暂停服务或凭据无效，都需要采取对应措施。先阅读错误原因，必要时更新凭据或解决账户问题。Reconnect 和 ConnectByToken 是显式恢复工具，不应放进每次请求的重试循环。若符合恢复条件的会话仍不可用，继续暂停相关操作，并向支持人员提供错误代码和发生时间。
- 1:58
恢复客户端的 WebSocket。
终端连接和应用的 WebSocket 是两条不同的连接。账户读取恢复后，关闭故障套接字，再使用已保存的终端 id 和 API 密钥打开 OnSymbolTick，恢复交易品种订阅。这里的真实 EURUSD 消息包含 bid、ask 和时间戳。确认收到新数据，并避免重复订阅。正常工作的现有连接无需关闭。
- 2:32
识别真实的限流响应。
这是通过有界只读测试取得的真实 AccountSummary 限流响应。HTTP Status Code 200 表示 API 返回了响应。非空的 error 包含 TERMINAL_RATE_LIMIT_EXCEEDED，并明确指出调用未执行。测试时，每个终端的所有客户端共享每滚动一分钟三百次非交易调用的额度。请查看当前请求限制，不要在代码中永久写死这个数值。
- 3:10
按服务器提示等待。
在这个真实响应中，error.properties 包含名为 RetryAfterSeconds 的键值对，值为 1。至少等待一秒，再加入少量随机延迟后重试读取。使用同一终端额度的其他工作进程也应暂停。再次被限流时，采用新的等待时间。遇到 HTTP Status Code 429，还要遵守 Retry-After 响应头。
- 3:45
逐步恢复请求。
等待后，真实账户读取再次成功：HTTP Status Code 200，没有 API 错误，且返回模拟账户数据。逐步恢复请求，不要一次性补发积压请求。缓存重复账户数据，协调各工作进程的请求频率，用 OnSymbolTick 获取实时行情。限流意味着需要等待，不意味着需要重连终端。
- 4:20
重试规则应明确且有限。
配套 Python 示例仅用于 AccountSummary。遇到明确的限流或忙碌响应，并提供有效等待时间时，才会加入随机延迟并重试，最多尝试三次。其他错误交由调用方处理。凭据保存在环境变量中。连接中断应有独立且有上限的处理策略，不要把读取重试函数直接套在连接命令或交易方法上。
- 4:54
先确认结果不明的交易。
交易请求的响应丢失时，券商可能已经处理该请求。自动恢复并不能说明这笔交易的结果。恢复访问后，检查 OpenedOrders 和 DealsHistory。优先使用已知的订单和成交编号，再比较品种、方向、数量和时间。相似交易可能难以区分，因此不要自动重发尚未确认结果的交易请求。
- 5:28
正确结束会话。
主动结束会话时，先停止订阅，再调用 Disconnect。本次演示的行情流已停止，终端已断开，未修改任何交易。记住：由 MetaRPC 恢复符合条件的终端，客户端按需恢复自己的套接字，限流时等待，交易结果不明时先核对，再决定是否提交新交易。