加密货币交易所 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