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 上直接看到「這筆為什麼沒進去」——但這只解決了「你比較快知道」的問題，沒有解決「這筆單真的沒下去」的事實。冷靜期就是為了讓你冷靜，任何「幫你自動繞過冷靜期」的服務都跟這個功能設計初衷相反，我們不做，你也不該用做這件事的第三方服務。

常見問題