OKX 错误码 54094
冷静期扩到 REST／WebSocket，webhook 被 server-side 拒单

你把 TradingView alert 接到 OKX，某天开始 webhook 送过去只拿回一个 54094。API key 没过期、IP 白名单没动、额度也还在——但 OKX 冷静期 API 拒单这件事从 2026-07-07 起就是系统设计上的预期行为，不是你哪里设错。这篇把 OKX 官方《Notice on Upgrade to the Futures Cool-off Period》与 OKX API v5 changelog 那两份原文，跟你的 webhook payload 对到字段，把「哪些单会被拒、哪些不会、既有用户要不要担心」讲清楚。

这篇不评论 OKX 这个机制设计得好不好——冷静期本身是保护散户的功能，我们没有立场否定它。这篇也不教你怎么绕过去，因为它是 server-side 执行的，没有任何客户端做法可以绕。范围缩在这里：告诉你 54094 是什么、你的 webhook 为什么会踩到、以及可以怎么调整流程。

症状长什么样子：HTTP 200 但单没进去

这个错误最容易把人绕晕的地方，是它的 HTTP status code 是 200——不是 4xx、也不是 5xx。你的 HTTP client 会告诉你「请求成功」，但 OKX 回的 JSON body 里的 sCode（下单细项状态码）是 54094，消息是官方 changelog 原文写的一句：

Order rejected. The cool-off period is active for the current instId.

意思是：这根本不是一笔订单。OKX 收到你的请求、验过签名、跑过风控、然后在下单那一层被冷静期挡掉——所以整个 HTTP request 的 lifecycle 是「成功」的，但你以为的那笔单根本没送进撮合。这种情况如果你的 webhook consumer 只看 HTTP status code 就当成成功，就会出现「响应码是 200，但持仓没动」——这种错不会吵，它会安静地坏掉，一直安静地坏到你去对账才发现。

为什么会这样：机制在 API 层，不在你的代码里

OKX 在 2026-07-03 贴出公告、2026-07-07 生效、2026-07-16 起在特定地区逐步启用，把原本只在 web／app 上生效的冷静期扩到「REST API, WebSocket, third-party authorization (including Broker OAuth, Agent Trade Kit, etc.), trading bots」这几个通道（原文出自公告第二段）。这意味着：只要你在 OKX 账号上主动开了冷静期，这段时间内从任何通道送进来的开仓／加仓单都会被 server-side 拒掉。

官方公告讲到哪里为止？公告白纸黑字写的是「any orders to open or increase positions submitted through the above channels will be rejected. Orders to reduce or close positions are not affected.」——open／increase 拒、reduce／close 放行。策略单与跟单另有一句「Strategy orders and copy trading orders will be rejected regardless of whether they are for opening or closing positions.」——不管开平一律拒。这两句是本篇所有推导的基础，其他都是我们把它跟 webhook payload 对到字段得出的结论，不是官方原文另外写的一句。

错误码 54094 本身是 2026-07-07 API changelog 新加进去的，changelog 的 Cool-off period order rejection 段落原文写着「While a user's cool-off period is active, non reduce-only orders on SWAP and FUTURES instruments covered by the cool-off are rejected server-side.」——所以受影响的品种也框好了：SWAP（永续）与 FUTURES（交割合约）。现货与期权在原文里没被列进去。

哪些单会被拒、哪些不会

这张表是把公告与 changelog 两份原文交叉出来的结果——第一栏是下单通道，后面三栏是三种常见场景。你可以拿它对照自己的部署，看每一条路径会不会被 54094 挡。

TVSBot／TradingView webhook 的 payload 对到哪个字段

TVSBot 的 webhook payload schema 里有一个字段叫 reduce_only，类型 bool、默认 false。这个字段就是决定 OKX 端会不会把这笔单当「reduce-only 平仓」放行的关键——是不是布尔 true，效果差非常多：

对 Pine Script 策略作者的意义是：你如果在 strategy.entry() 触发的 alert 里送 webhook，它天然是开／加仓，冷静期会挡。strategy.close() 或 strategy.exit() 触发的 alert 如果你在 payload 模板里有把 action 设成 "close"（或直接写 reduce_only: true），那条路就会通。这篇讲 qty_type 的陷阱里有 payload 完整字段对照，一起看比较快。

三种修法，选一个

收到 54094 之后你只有三种选择：撤掉冷静期、等它自然到期、或者把整个下单流程改成「用 reduce-only 平仓为主」的模式。没有第四种选项——这是 OKX server-side 拒单，客户端做什么都没用。

既有用户会不会被影响？

不会，但有条件。官方公告的第三段写着「Users who configured the cool-off period before this upgrade will remain on the existing service, which only restricts orders placed via the web and app. These users will not be subject to the expanded restrictions introduced in this upgrade.」——2026-07-07 升级前就设过冷静期的用户，会沿用旧制（只挡 web／app）直到本轮冷静期结束。

但接下来会有一个切换点：如果你想要新的完整保护，官方建议「we recommend re-enabling the cool-off period after your current one expires」——旧冷静期到期后再重新开一次，就会套用新规则。所以「我以前设过冷静期、我 API 一直正常」这件事，会在你下一次重置冷静期那一刻自动转成新制。如果你想维持 API 不被冷静期影响，就不要重置。

收到 54094 时的排查顺序

这张清单是给你收到 54094 时照顺序跑一遍用的——不用背，卡在哪一步就停在那里处理。前三条先确认是不是这件事，后三条决定要怎么修。

• 看 HTTP body，不是只看 status code。 OKX 对这个错回 HTTP 200 + sCode: "54094"，只信 HTTP status 的 consumer 一定会漏掉。你的 webhook consumer 一定要 parse JSON body 拿 sCode。
• 确认你的 OKX 账号目前有冷静期在跑。 进 OKX web 端 Account > Trading > Cool-off Period，看 status 是不是 Active、剩余时间多少。如果是 Inactive，那 54094 不是这个原因，去查子账号设置或 Broker OAuth 的授权范围。
• 确认品种是 SWAP 或 FUTURES。 Changelog 只把这两类写进覆盖范围。如果你的 instId 是 BTC-USDT（spot）或 options，看到 54094 可能是别的原因，不是这里讨论的机制——回头去 OKX 官方 API 文档的 sCode 表查一次那个代号目前的最新定义。
• 看你这笔单是不是 reduce-only。 Payload 里的 reduce_only 有没有带、值是不是 true。TVSBot 用户把 action 改成 "close" 也算——下单 service 会自动翻成 reduce_only=true。
• 看是不是策略单／跟单。 走 OKX 内建策略下单、或跟单交易的 sub-account，冷静期期间开平都会被拒。这种情况要么切换去自己的 REST 下单、要么等冷静期过。
• 决定要撤冷静期还是改流程。 如果是旧版冷静期，官方明讲不能提前中止，只能等；新版可以主动关。长期解法是把策略逻辑拆成「开仓可能被冷静期挡、平仓一律 reduce-only」，之后再遇到就不会全流程停摆。

诚实的一段：我们也挡不掉这件事

任何跑在 OKX 上的自动化交易系统——包括我们自己的 TVSBot——遇到冷静期都只能照规则走。这是 OKX server-side 执行的规则，不在客户端；没有任何 SaaS、broker、bot 服务能替你绕过去。举例来说，TVSBot 的做法是在下单前不做冷静期的预先检查（OKX 也没开这种查询 API），拒单回来后把 54094 的原始消息保留在该次下单记录里，让你在 dashboard 上直接看到「这笔为什么没进去」——但这只解决了「你比较快知道」的问题，没有解决「这笔单真的没下去」的事实。冷静期就是为了让你冷静，任何「帮你自动绕过冷静期」的服务都跟这个功能设计初衷相反，我们不做，你也不该用做这件事的第三方服务。

常见问题