加密貨幣交易所 API 頻率限制：429 錯誤是什麼意思，如何不觸發

HTTP 429 表示你在一段時間內傳送了太多請求，伺服器要求你慢一點。它不是當機。每家交易所的計數方式不同：幣安為每個介面設定權重，並封禁 429 之後仍繼續請求的 IP；Bybit 在 IP 五秒內超過 600 次請求時封鎖；OKX 按介面設定限制並返回錯誤碼 50011。要不超限，就要讀響應頭、正確退避，並儘量使用 WebSocket。

429 到底是什麼意思

HTTP 429 Too Many Requests 是標準狀態碼，就是為這種情況定義的。MDN 文件將它描述為客戶端在一定時間內傳送了太多請求，並提到 Retry-After 頭可能告訴你要等多久。頻率限制可能作用於整個伺服器或單個資源，通常基於 IP 地址，也可能繫結到某個應用或使用者。

這是一條有用的訊息，而不是失敗。它告訴你服務在工作，你已被識別，以及接下來該做什麼。我們在本站測量可用率時，把頻率限制單獨歸類，不會僅僅因為請求被限流就把交易所報告為當機。

幣安的計數方式：請求權重和 IP 封禁

幣安合約 API 文件描述了一套權重系統。每條路由都有權重，較重的介面或處理多個交易對的介面消耗更多。限制針對的是每個時間視窗內的總權重，而不是簡單的請求次數。當前限制見 /fapi/v1/exchangeInfo 的 rateLimits 陣列。

文件的要點：

• 每個響應都包含 X-MBX-USED-WEIGHT-(intervalNum)(intervalLetter)，顯示你的 IP 當前已用權重。
• 任一頻率限制被超過時都會返回 429。
• 反覆超限或收到 429 後不退避，會導致 IP 被自動封禁，狀態碼 418。
• 對屢犯者，封禁時長會逐步增加，從 2 分鐘到 3 天。
• IP 限制基於 IP 地址而不是 API 金鑰，所以一臺機器上的多個程式共用一份額度。
• 下單頻率限制單獨計算，下單響應也有自己的計數頭。

Bybit 的計數方式：按 IP 和按使用者

Bybit v5 文件描述了兩層限制。在 IP 層，預設每個 IP 在五秒視窗內允許 600 次請求，針對其主要 API 主機名的流量。超過後會收到「403, access too frequent」，文件說應該停止所有 HTTP 會話並等待至少 10 分鐘，之後封禁自動解除。注意這是 403 而不是 429，常讓人意外。

在 API 層，限制針對每個使用者的滾動視窗，超過時在 JSON 中返回 retCode 10006 和「Too many visits!」。響應頭會報告你的情況：

• X-Bapi-Limit-Status 顯示當前介面的剩餘請求數。
• X-Bapi-Limit 顯示當前介面的限額。
• X-Bapi-Limit-Reset-Timestamp 顯示超限後限額何時重置。

Bybit 還建議不要讓應用貼著這些限制執行，因為網路異常可能造成意外超限。WebSocket 連線有自己的限制。

OKX 的計數方式：按介面和按合約

OKX API 文件說，請求被拒時返回錯誤碼 50011，每個介面的限制不同，並列在介面詳情中。公開未認證的 REST 限制基於 IP 地址，WebSocket 登入和訂閱限制基於連線。交易 API 方面，下單、改單和撤單的限制相互獨立，通常按合約定義，並由 REST 和 WebSocket 共用。

這三家的共同教訓是，不要把一家交易所的規則套到另一家。狀態碼、計數單位和處罰都可能不同，而且都會隨時間變化，所以請回到最新文件。

為什麼會無意中觸發限制

大多數頻率限制問題不是來自一個忙迴圈，而是來自不那麼明顯的原因。

• 共用 IP 地址。多個機器人、雲 NAT 閘道器或共用 VPN 都算在一個地址上。鄰居可能消耗你的額度。
• 重型介面。獲取全部行情或深度委託簿的成本可能是單個交易對請求的很多倍。十次這樣的請求可能相當於幾百次簡單呼叫。
• 重試風暴。短暫故障讓所有 worker 同時重試。這波請求把你推入 429，又引發更多重試。
• 重啟迴圈。啟動時重新載入狀態的程式，如果反覆崩潰重啟，光啟動就可能用完全部額度。
• 輪詢本可以用資料流獲取的資料。50 個交易對每秒問一次價格，就是每分鐘 3,000 次請求，而 WebSocket 能以低得多的成本提供同樣的資料。

如何正確退避

收到限流響應時，正確的做法很簡單，值得在一個地方實現一次。

• 在要求的時間內停止向這家交易所傳送。如果有 Retry-After 頭或重置時間戳，就遵守。否則等待，從一秒左右開始。
• 使用帶抖動的指數退避。每次連續失敗後等待時間翻倍，設上限，並加入隨機量，避免多個 worker 同時重試。
• 在 worker 之間共用限流器。一個 IP、一家交易所一個令牌桶，由這個地址上所有程序共用，比每個 worker 各自猜測有效得多。
• 持續跟蹤用量。讀取每個響應的已用權重頭，接近限制時就減速，不要等到被告知。
• 把 418 和 IP 封禁當作停止訊號。停下來，通知人工處理。繼續請求會延長封禁。

如何減少請求

最便宜的請求是不發的請求。

• 行情資料和賬戶更新用 WebSocket。一個資料流代替持續輪詢，更新還更快到達。
• 快取變化慢的資料。合約規格和費率表很少變化，偶爾獲取一次就好，不要每次執行都請求。
• 謹慎使用批次介面。它們能省很多請求，但要查權重，因為單次成本更高。
• 只請求需要的深度。深度委託簿請求成本更高，很多工只需要前幾檔。
• 不要迴圈輪詢訂單狀態。使用者資料流會告訴你訂單何時成交。

如果你只需要資金費率或可靠性資料，可能根本不用輪詢交易所。我們以免費 JSON 檔案形式公開資料，定期更新，不過它們不應用於需要實時資料的交易決策。

緊急時刻的 429

最糟糕的情況是在下跌行情中想撤單時撞上限制。你的迴圈一直在猛打 API，額度用完了，現在撤單被拒。要提前規劃：把訂單相關流量放在單獨預留的額度內，和行情輪詢分開。公開資料走資料流，不佔 REST 額度。幣安文件提到，當伺服器節點處於系統級保護並限流時，平倉、只減倉和撤單訂單不受影響，所以用這些訂單型別來降低風險是個明智的習慣。當機時怎麼辦指南講了相關準備。

是限流還是當機？

兩者在監控面板上可能很像，因為都產生失敗。用狀態碼區分。

• 429、418 或交易所自己的限流碼：很可能是你自己的流量造成的。
• 403：可能是網頁防火牆、地區封鎖或 Bybit 的 IP 限制。見 403 和 451 指南。
• 5xx 或超時：可能在交易所一側或線路上。檢視它是否當機。

每次失敗都記錄狀態碼、介面和響應頭。沒有這些，你只能靠猜。

關於頻率限制的常見問題

用多個 API 金鑰能繞過限制嗎？

對基於 IP 的限制不能，比如幣安的 IP 權重。同一地址的多個金鑰共用同一額度。下單頻率限制可能按賬戶計算，所以要查清每種限制如何計數。專門為躲避限制而把流量分散到很多地址，可能違反交易所條款，我們不建議。

頻率限制封禁持續多久？

取決於交易所。幣安文件說明封禁對屢犯者逐步增加，從 2 分鐘到 3 天。Bybit 說「403, access too frequent」之後至少等 10 分鐘。封禁期間繼續請求可能延長封禁。

可以申請更高的限額嗎？

有些交易所向做市商、VIP 等級或申請者提供更高限額，見其文件。通常更好的第一步是減少不必要的流量，這也會讓系統更健壯。

保持在限制之內

1. 讀你使用的具體 API 的頻率限制規則。
2. 記錄已用權重頭，在接近限制前減速。
3. 一個 IP 上的所有 worker 共用一個限流器。
4. 收到限流響應時帶抖動退避，並遵守 Retry-After。
5. 遇到 418 或封禁時停止並告警。
6. 把行情資料改用 WebSocket。
7. 為撤單預留額度。

相關閱讀：交易所 API 為什麼返回 403 或 451 · 如何修復幣安 -1021 錯誤 · 如何判斷交易所是不是當機了

來源

幣安 · 頻率限制 · Bybit · 頻率限制規則 · OKX · API 文件 · MDN · 429 · 關於 Tickmark