OKX API限流触发时需立即暂停60秒并重置计时窗口；实盘默认每秒5次请求，接口权重不同，应采用分级限流或令牌桶算法控制调用频率，并优化订阅与查询方式规避超限。
OKX程序化交易中遇到“API rate limit reached”或错误码5、6004等提示，说明当前API调用已超出平台设定的频率阈值，请求被服务端主动拒绝，交易下单、账户查询等操作将立即失败。
欧易（OKX）官方认证入口：
点击获取官方APP☞☞☞☞☞：
确认当前限流类型与阈值
登录OKX官网→进入API管理页面→点击对应API Key右侧的「详情」，查看「访问限制」栏。实盘环境（flag=0）默认为每秒5次请求（含所有私有+公有接口），测试网（flag=1）为每秒10次；若开启IP白名单，该限制仍生效，但未绑定IP的Key在闲置14天后会被自动删除。
注意：不同接口权重不同——例如/api/v5/trade/order下单接口消耗1点配额，而/api/v5/market/tickers公有行情接口仅消耗0.1点，高频轮询行情却忽略下单频次，极易误触总量上限。
紧急暂停并重置计时窗口
立刻停止所有API调用，等待60秒。OKX的速率限制按自然分钟重置（如从10:05:00到10:05:59为一个窗口），不是滑动窗口。强行在第59秒重试仍会失败。
【必须等待满60秒再发起首次新请求】。若使用脚本自动恢复，务必用time.sleep(61)而非60，避免系统时钟微小偏差导致重试即失败。
代码层主动限流：三种落地方法
方法一：全局请求间隔控制（适合单线程轻量策略）
在每次调用client._request_*前插入固定延迟：time.sleep(0.25)。该设置可将理论峰值压至每秒4次，留出余量应对网络抖动与后台处理耗时。
方法二：令牌桶算法轻量实现（推荐用于中频网格/套利）
引入threading.Lock与时间戳计数器，每秒向桶中添加5个令牌，每次请求消耗1个。桶满则阻塞，不依赖第三方库，15行内可完成。
方法三：按接口类型分级限流（适用于混合型复杂策略）
对交易类接口（order/cancel/position）单独启用sleep(0.3)，对行情类接口（tickers/books）启用sleep(0.05)，对账户类接口（balance/positions）启用sleep(0.5)。这样既保障关键交易指令不被限，又避免行情拉取拖垮整体配额。
规避限流的硬性配置调整
第一步：关闭非必要订阅→WebSocket连接中，只保留books5或tickers中的一项，禁用trades和liquidation等高更新率频道。
第二步：合并批量查询→不要循环调用get_order_history(instId="BTC-USDT")查单个合约，改用get_order_history(instType="SWAP")一次拉取全部永续合约订单，再本地过滤。
第三步：切换环境验证→将flag=0临时改为flag=1，用测试网密钥运行相同逻辑。若测试网不报错，即可确认是实盘配额不足，而非代码逻辑问题。
【测试网密钥必须重新申请，不可复用实盘密钥】。测试币需通过OKX测试网Faucet领取，余额归零后接口调用会返回模拟成功，但不产生真实成交。
