你的 Hyperliquid 机器人一直返回 429？彻底修复它。

你写了一个每秒轮询 Hyperliquid 价格的机器人，测试时运行完美。然后你加了第二个资产，然后五个，然后以同样的频率检查持仓和资金费率——反正为什么不呢。几分钟内，API 开始返回 HTTP 429，你的机器人在最糟糕的时刻彻底失明。

这是新 Hyperliquid 开发者最常见的故障模式，解决方案几乎从来不是"升级到更高套餐"。问题出在架构上：大多数机器人把每个端点当作成本相同的东西来对待，以同样的频率轮询几乎不变的数据和每个区块都在变动的数据，并且忽略 Hyperliquid 提供的可以完全绕开 REST 的工具。一旦你真正理解权重系统的运作原理，429 错误就会从不可避免的事变成可以从架构层面永久规避的问题。

本文拆解 Hyperliquid 强制执行的每一个速率限制，解释每个端点类别背后的权重计算逻辑，并介绍让生产环境机器人始终保持在预算之内的缓存、WebSocket 和批处理模式。

权重预算：每分钟 1,200，但并非所有请求成本相同

Hyperliquid 的 REST API 使用基于权重的系统。每个 IP 地址共享每分钟 1,200 权重的预算。但每次请求的消耗因端点不同而差异显著。

Exchange API 请求（下单、取消、修改）的权重为 1 + floor(batch_length / 40)。单个订单消耗 1 点。39 个订单的批次也只消耗 1 点。40 个订单的批次消耗 2 点。这使得批处理成为速率限制工具箱中最有效的手段之一。

Info 端点分为三个层级：

| 层级 | 权重 | 端点 | | --- | --- | --- | | 轻量 | 2 | l2Book、allMids、clearinghouseState、orderStatus、spotClearinghouseState、exchangeStatus | | 较重 | 20 | 所有其他有文档记录的 info 请求（持仓、成交记录、资金费率历史、排行榜） | | 最重 | 60 | userRole |

部分端点还会随响应体大小增加权重。recentTrades、historicalOrders、userFills、userFillsByTime、fundingHistory 等端点每返回 20 条数据额外增加一定权重。candleSnapshot 端点每 60 条数据额外增加权重。Explorer API 请求起始权重为 40，blockList 每个区块再加 1。

让人栽跟头的是具体的计算。如果你的机器人每秒轮询一次 allMids（每次权重 2），仅价格数据每分钟就消耗 120 权重。以相同频率检查 clearinghouseState（再加 120），还没下一单，你就已经用掉了 20% 的预算。再以同样频率加入权重为 20 的端点（比如 userFills），光成交记录每分钟就烧掉 1,200 权重，预算耗尽。

大多数开发者忽视的地址级限制

基于 IP 的速率限制是所有人都知道的，因为 429 错误很显眼。但 Hyperliquid 还针对每个钱包地址单独执行限制，这个更隐蔽，但触发时同样棘手。

每个地址初始有 10,000 次请求的缓冲额度。此后，额度根据交易量增长：自该地址创建以来每累计交易 1 USDC 获得额外 1 次请求。交易总量达到 $500,000 的账户拥有 510,000 次请求的预算。一个从未交易过的全新测试网地址，激进轮询几小时就能耗尽缓冲额度。

触发地址级限制时，API 会将你限速为每 10 秒一次请求。这不是硬封锁，而是一根绳索。你的机器人仍然能运行，但慢如蜗牛。值得庆幸的是：取消操作享有更宽松的预算，为 min(limit + 100,000, limit * 2)，所以即使在其他操作受限时，你也能平仓。

子账户在地址级限制上被视为独立用户，因此将操作分散到子账户有一定帮助。但不要将其与 IP 级限制混淆——IP 级限制在同一 IP 的所有流量中共享，与发起请求的是哪个地址无关。

WebSocket 限制：1,000 个订阅，而非每个连接 1,000 个

从 REST 轮询切换到 WebSocket 订阅，是大多数开发者能做的最大的速率限制优化。订阅在数据变动时推送给你的机器人，消耗零 REST 权重。但 WebSocket 连接有自己的一套限制，最常见的误解在于订阅数量的计算方式。

Hyperliquid 每个 IP 最多允许 10 个同时存在的 WebSocket 连接，每分钟最多新建 30 个连接。订阅上限为所有连接合计 1,000 个。开 5 个连接并不给你 5,000 个订阅，共享上限仍然是 1,000。

出站消息上限为每分钟 2,000 条，最多 100 条同时在途的 post 消息。用户专属订阅（如 UserEvents）每个 IP 最多追踪 10 个唯一用户。

订阅数量的计算不容忽视。Hyperliquid 上线了 200 多个永续合约，每个资产与数据类型的组合都需要独立订阅。仅订阅每个资产的 Trades 和 L2Book，就需要 400 多个订阅。再加上哪怕一个时间框架的 Candle，就超过 600 个。两个时间框架直接突破 1,000 的上限。

动态管理订阅

生产环境的机器人很少需要随时监听所有资产的所有数据流。更有效的做法是维护一个观察列表，根据策略当前实际需要来轮换订阅。用一个 AllMids 订阅获取所有价格（一个订阅），然后仅为正在交易或观察入场机会的币种添加特定资产的数据流。

当某个资产离开观察列表时，取消订阅并释放槽位。即使你的资产池有数百个，这种模式也能让你远低于 1,000 的上限，因为任意时刻的活跃集通常要小得多。

触发 429 后实际发生了什么

Hyperliquid 返回 429 意味着你的请求被拒绝，但这是一个警告信号。API 会在响应体中返回错误信息，并可能包含 Retry-After 响应头，告诉你确切需要等待多长时间。短暂的限速事件只会导致请求被拒，不会封号。但持续的滥用流量可能升级为更严重的后果。

机器人在收到 429 后最糟糕的反应是立即在紧密循环中重试。这只会制造更多 429 错误，延长限速窗口，可能把短暂的波动变成持续的中断。指数退避是标准解法：

1. 检查 Retry-After 响应头，如有则严格等待该时长。
2. 如无，从 1 秒延迟开始。
3. 每次连续失败后将延迟翻倍：1 秒、2 秒、4 秒、8 秒、16 秒、32 秒。
4. 上限设为 60 秒。如果到这里仍在收到 429，说明有更深层的问题。
5. 成功请求后重置退避计时器。

async def request_with_backoff(endpoint, payload, max_retries=6):
    delay = 1
    for attempt in range(max_retries):
        response = await client.post(endpoint, json=payload)
        if response.status_code != 429:
            return response
        retry_after = response.headers.get("Retry-After")
        wait = int(retry_after) if retry_after else delay
        await asyncio.sleep(wait)
        delay = min(delay * 2, 60)
    raise RateLimitExceeded(f"Still 429 after {max_retries} retries")

批处理：最被低估的优化手段

Hyperliquid 的批处理机制出乎意料地慷慨。最多 39 个 exchange API 请求（下单、取消、修改）的批次与单个请求成本相同：权重 1。40 个请求的批次权重为 2，79 个请求的批次仍然是权重 2。这意味着单独下 30 个订单消耗 30 权重，而将同样的 30 个订单打包成一次批次只消耗 1 权重。

不过有一个关键细节需要注意：批量请求在 IP 级限制中计为一次请求，但在地址级限制中计为 n 次请求。批处理节省的是 IP 预算，而非地址预算。对大多数开发者来说，IP 限制是主要瓶颈，所以批处理仍然带来最大收益。只需注意，每分钟发送数百个批量订单的高频机器人仍会持续消耗地址级缓冲额度。

缓存：停止重复拉取几乎不变的数据

Hyperliquid 的资金费率每小时结算一次。未平仓量每个区块更新，但对大多数资产来说，逐秒的变化并不显著。交易所元数据（资产列表、规格、保证金参数）可能一周才变一次，在新上线时更新。然而大多数机器人以与价格数据相同的激进频率轮询所有这些数据。

带有 TTL 过期机制的本地缓存层可以消除大多数冗余请求：

• 价格（allMids）： 迁移到 WebSocket，REST 权重消耗为零。
• 持仓（clearinghouseState）： 每隔几秒轮询一次（例如 5-15 秒），轮询间隔内使用缓存。
• 资金费率： 缓存数分钟（例如 10-15 分钟）。费率每小时结算，即使缓存 15 分钟，每个结算窗口最多检查 4 次。
• 成交记录（userFills）： 通过 UserEvents WebSocket 订阅实时更新，仅将 REST 轮询作为对账兜底。
• 元数据（资产列表、规格）： 积极缓存（元数据变化频率极低），启动时读取一次，周期性刷新。

将 WebSocket 订阅用于快速变动数据，将缓存 REST 轮询用于慢速变动数据，两者结合通常能将 REST 权重总消耗减少 90% 以上（相比简单的全轮询架构）。对大多数机器人而言，这意味着每分钟 1,200 权重的预算足以支撑多年增长，而无需触碰任何限制。

将数据预算与交易预算分开管理

Hyperliquid 文档指出，info 端点类别和 exchange 端点类别的限制是独立的。这是一个关键的架构洞察。你的行情数据查询永远不应该与订单执行争夺速率限制空间。

在实践中，这意味着将机器人设计为两条独立的请求路径：一条用于数据摄取（info 端点、分析、监控），一条用于执行（下单、取消、修改）。如果数据层有 bug 导致请求突发，交易路径不受影响。如果执行层正在清算事件中批量取消订单，数据流照常流动。

对于使用预计算分析数据的开发者，这种分离可以做得更彻底。与其把 info 端点预算烧在原始数据处理上（拉取数百个地址的成交记录、计算群体聚合数据、追踪排行榜变化），你可以通过专用层来消费这些分析数据。HyperTracker 的 API 以预计算端点的形式提供群体持仓、Smart Money 聚合数据和清算风险评分，让你机器人的 Hyperliquid 速率限制预算完全专注于只有 Hyperliquid 才能提供的数据：价格、你自己的持仓和订单执行。

更快构建，更少轮询

HyperTracker 跨 16 个行为群体计算群体分析数据，让你的机器人无需爬取数百个钱包。一次 API 调用替代数千次持仓查询。从免费套餐开始。

探索 API

在生产环境中监控你的预算

"测试时好用"与"生产环境稳定运行"之间的差距，在于监控。Hyperliquid 提供了 userRateLimit info 端点，返回你当前的地址级速率限制状态、剩余预算和使用量。定期查询该端点（例如每 30 秒一次），可以在触碰上限之前及早预警。

除了 Hyperliquid 内置端点，还要对你的机器人进行埋点，追踪以下指标：

• 按端点类型统计的每分钟请求数： 掌握哪些端点消耗权重最多。
• 429 频率： 任何非零计数都意味着你的预算计算存在偏差。
• WebSocket 重连频率： 频繁重连可能意味着连接断开在消耗你每分钟 30 个新连接的配额。
• 缓存命中率： 命中率低意味着 TTL 设置过短，或者有些本该缓存的端点没有缓存。
• 响应延迟百分位（p50、p95、p99）： 延迟上升可能是 429 实际触发前接近速率限制的信号。

记录这些指标，设置告警，每周复盘。随着你不断添加资产或策略，机器人会逐渐趋近速率限制，最终越界。早发现趋势并调整，总好过在剧烈行情中才发现问题。

可扩展的速率限制架构

以下是让生产环境 Hyperliquid 机器人无论追踪多少资产都远低于预算的技术栈：

1. WebSocket 优先： 用 AllMids 获取价格，用 L2Book 获取活跃资产深度，用 UserEvents 获取成交记录。消除最高频的 REST 轮询。
2. 缓存所有慢速数据： 资金费率、元数据和历史查询使用本地 TTL 缓存，按计划刷新，而非按需刷新。
3. 批量执行所有写操作： 将下单、取消和修改打包成批次。根据权重公式，40 个以下的批次权重为 1。
4. 数据与执行分离： 使用各自独立监控的不同请求管理器，数据层的 bug 永远不应阻断交易。
5. 外包分析计算： 让 HyperTracker 这样的预计算 API 处理群体智能。把你的 Hyperliquid 预算花在只有 Hyperliquid 才能提供的数据上。
6. 监控与告警： 追踪每个端点的权重消耗，关注 429 趋势，在触及限制前调整 TTL 或订阅数量。

每个 Hyperliquid 开发者都至少会遇到一次 429。那些构建出持久产品的人，是在遇到问题后重新设计架构，确保它永不再发生。工具都已备好：基于权重的预算系统、慷慨的批处理机制、原生 WebSocket 支持，以及能告诉你当前状态的 userRateLimit 端点。用好它们，速率限制就会变成一条你永远不会触碰的护栏。