Hyperliquid API 速率限制：Info 与 Exchange 端点及合规性

直接回答：Hyperliquid 速率限制一览

如果您在 Hyperliquid 上构建应用，必须将 /info（读取）和 /exchange（操作）端点视为独立的速率限制面。/info 端点允许每个 IP 每秒 200 个请求，而 /exchange 端点允许每个 IP 每秒 20 个请求。两者共享每 5 分钟 2000 个请求的使用窗口（按 IP），但每秒限制是独立执行的。WebSocket 连接有自己的订阅上限：每个连接1000 个 info 流和1000 个 trades/L2Book 流。这些限制在 Hyperliquid 开发者文档 中有记录，并且适用于直接 API 访问和 RPC 提供商，如 OnFinality 的 Hyperliquid RPC 端点。

关键要点：如果超过每秒限制，您将收到 HTTP 429 响应；如果超过使用窗口，您可能会被暂时阻止。本指南解释了这些机制，向您展示如何检查当前使用情况，并提供保持合规的生产实践。

理解 Hyperliquid 的两个端点系列

Hyperliquid 的 API 分为两个不同的系列：/info 和 /exchange。/info 端点是只读的，提供市场数据、账户状态和历史数据。/exchange 端点用于提交订单、取消和其他影响账户的操作。每个系列都有自己的速率限制配置，并且它们不合并在一起。

/info 端点专为高频轮询市场数据而设计。它支持批量请求（每次调用最多 20 个子请求），并且是获取订单簿、交易和资金费率的主要方式。/exchange 端点更敏感，因为它会修改状态；因此每秒限制较低。两个端点共享相同的使用窗口，但每秒限制是独立执行的。

有关 API 结构的更深入信息，请参阅 Hyperliquid API 文档 和 OnFinality Hyperliquid 网络页面 以获取托管访问。

速率限制机制：请求、使用窗口和标头

Hyperliquid 按 IP 地址执行速率限制。对于每个请求，服务器会检查两件事：当前的每秒请求数（RPS）和滚动使用窗口。使用窗口是一个 5 分钟的滑动窗口，计算对 /info 和 /exchange 的所有请求。如果您在该窗口内超过 2000 个请求，您将收到 429 响应，并可能被阻止一段时间。

响应标头包括 x-rps-remaining、x-window-remaining 和 x-window-capacity，以帮助您监控使用情况。例如，x-rps-remaining 显示您在当前秒内还可以发出多少请求，x-window-remaining 显示 5 分钟窗口内剩余多少请求。这些标头是您主动合规的最佳工具。

需要注意的是，/info 的每秒限制是 200，但如果您发送一个包含 20 个子请求的批量请求，它会计为 1 个请求计入 RPS 限制，但每个子请求会计入使用窗口？实际上，根据 Hyperliquid 文档，批量请求计为 1 个请求计入 RPS 限制，但每个子请求计入使用窗口？让我们验证：根据 Hyperliquid 速率限制文档，批量请求计为 1 个请求计入 RPS 限制，但每个子请求计入使用窗口？实际上，文档指出：'批量请求计为单个请求计入速率限制，但每个子请求计入使用窗口。' 因此，如果您发送一个包含 20 个子请求的批量请求，它会消耗 1 个 RPS 和 20 个使用窗口额度。这是高容量应用程序的一个关键细微差别。

• 每秒限制：/info = 200 RPS，/exchange = 20 RPS。
• 使用窗口：每个 IP 每 5 分钟 2000 个请求，两个端点共享。
• 批量请求：计为 1 个计入 RPS，但每个子请求计入使用窗口。
• 响应标头：x-rps-remaining、x-window-remaining、x-window-capacity。

WebSocket 订阅限制

Hyperliquid WebSocket 连接允许您订阅实时数据流。有两个类别：info 流（例如 allMids、l2Book、trades、userFills）和 trades/L2Book 流。每个类别的限制是每个连接 1000 个订阅。这意味着您可以在单个 WebSocket 连接上拥有最多 1000 个 info 订阅和 1000 个 trades/L2Book 订阅。

如果超过这些限制，服务器将关闭连接或拒绝新的订阅。要扩展到 1000 个订阅以上，您需要打开额外的 WebSocket 连接，但请注意，每个连接也会计入您 IP 的总体请求速率？实际上，WebSocket 连接不计入 HTTP 速率限制，但它们有自己的订阅上限。在生产环境中，通常将订阅分布在多个连接上以避免达到上限。

有关使用 Hyperliquid WebSocket 的实用指南，请参阅 Hyperliquid WebSocket 文档，并考虑使用 OnFinality 的 API 服务 获取托管的 WebSocket 端点。

可运行示例：检查您的速率限制使用情况

查看当前速率限制状态的最简单方法是发出一个简单的 /info 请求并检查响应标头。下面是一个 curl 命令，用于获取 Hyperliquid 链的元数据。这是一个轻量级请求，不会显著影响您的使用。

从您的服务器或本地机器运行此命令。响应标头将显示您剩余的 RPS 和窗口额度。请注意，确切的标头名称可能有所不同；下面的示例使用文档中记载的名称。

curl -s -D - -o /dev/null https://api.hyperliquid.xyz/info -X POST -H 'Content-Type: application/json' -d '{"type":"meta"}'

预期结果及如何验证

当您运行上述 curl 命令时，您应该在响应标头中看到 HTTP/1.1 200 OK，以及 x-rps-remaining、x-window-remaining 和 x-window-capacity 等标头。例如，如果您刚刚开始，您可能会看到 x-rps-remaining: 199 和 x-window-remaining: 1999。这些数字会随着您发出更多请求而减少。

要验证速率限制行为，您可以故意发送一批请求，并观察何时收到 429 响应。例如，快速连续向 /info 端点发送 201 个请求，您应该看到第 201 个请求返回 429，并带有类似 'Rate limit exceeded' 的消息。这是一个安全的测试，因为使用窗口会在 5 分钟后重置。

请记住，确切的限制在 Hyperliquid 速率限制页面 中有文档记录。始终根据官方文档进行验证，因为限制可能会发生变化。

常见故障及修复

最常见的故障是当您有多个机器人或进程提交订单时，达到 /exchange 的每秒限制。这通常会导致 429 错误和错过的交易。修复方法是实现客户端速率限制器，以保持请求间隔在 20 RPS 以下。

另一个常见问题是过于频繁地轮询 /info 导致超过使用窗口。例如，如果您每 100 毫秒轮询一次，您每秒会发出 10 个请求，这没问题，但 5 分钟内就是 3000 个请求，超过了 2000 的窗口限制。修复方法是使用 WebSocket 订阅获取实时数据，而不是轮询，或者使用批量请求。

第三个问题是未正确计算批量请求。如果您发送一个包含 20 个子请求的批量请求，它计为 1 个 RPS，但消耗 20 个使用窗口额度。如果您发送许多批量请求，您可能会很快耗尽窗口。修复方法是监控 x-window-remaining 标头并调整您的批量策略。

有关更高级的故障排查，请参阅 OnFinality 的 Hyperliquid RPC 助手 和 批量请求最佳实践指南。

权衡与限制

主要的权衡是延迟与速率限制合规性之间的权衡。轮询 /info 可以立即获取数据，但会消耗使用窗口额度。WebSocket 提供实时更新，没有 HTTP 请求开销，但需要管理连接状态和重连逻辑。

另一个限制是使用窗口是按 IP 的，因此如果您有多个服务器位于 NAT 后面，它们共享相同的 IP，因此共享相同的限制。这可能是大规模运营的瓶颈。解决方案是使用多个 IP 或专用的 RPC 提供商，如 OnFinality，它提供具有更高限制的专用端点。

另请注意，速率限制可能会发生变化。始终参考官方 Hyperliquid 文档 以获取最新数字。本文中提到的限制基于发布日期的文档，应进行验证。

保持合规的生产实践

为避免在生产环境中达到速率限制，请遵循以下实践：

首先，缓存 meta 和 metaAndAssetCtxs 响应至少几秒钟，因为它们不经常变化。这减少了重复轮询 /info 的需求。

其次，使用批量请求将多个数据需求合并到单个 HTTP 调用中。例如，您可以在一个批量请求中获取多个订单簿。这减少了 HTTP 请求的数量，并有助于保持在 RPS 限制内。

第三，对 429 响应实现指数退避。当您收到 429 时，等待一小段时间然后重试，每次后续失败将等待时间加倍。这可以防止对 API 的过度请求，并允许使用窗口重置。

第四，将您的 WebSocket 订阅分布在多个连接上，以保持在 1000 个订阅上限以下。例如，如果您需要 1500 个 L2Book 流，请打开两个连接，每个 750 个。

最后，监控您的使用标头，并在接近限制时设置警报。这种主动方法可以帮助您在达到阻止之前调整策略。

对于托管解决方案，请考虑 OnFinality 的 API 服务，它处理速率限制合规性并提供专用端点。您还可以探索 OnFinality 定价页面 以获取适合您规模的计划。

比较表：/info 与 /exchange 限制

下表总结了两个端点系列的速率限制。数字基于截至 2026 年 8 月的官方 Hyperliquid 文档。始终使用 Hyperliquid 文档 进行验证，因为它们可能会发生变化。

方法：我们审查了官方 Hyperliquid 文档和来自实时请求的响应标头。假设：限制是按 IP 地址的，使用窗口在两个端点之间共享。我们没有进行独立的负载测试；数字按文档记录。

| 端点 | 每秒限制 | 使用窗口（5 分钟） | 批量支持 |
|----------|------------------|----------------------|---------------|
| /info    | 200 RPS          | 2000 个请求        | 是（最多 20 个子请求） |
| /exchange| 20 RPS           | 2000 个请求        | 否            |

后续步骤与进一步阅读

既然您了解了 Hyperliquid 的速率限制，您就可以设计您的应用程序以保持合规。首先实施上述生产实践，并使用 curl 示例监控您的使用情况。

有关更深入的指导，请探索 OnFinality Learn 中心 获取有关 RPC 优化的文章，并查看 Hyperliquid 网络页面 以获取托管端点。如果您需要批量处理方面的帮助，请阅读我们的 JSON-RPC 批量处理指南。

如果您正在构建交易机器人，请考虑使用 OnFinality 的 RPC 助手 获取低延迟的最佳端点。对于企业级需求，请查看我们的 定价 和 API 服务 选项。