Hyperliquid 限流指南 2026：REST 权重、WebSocket 上限与地址额度

一句话：Hyperliquid 的限流分两层。按 IP，REST 请求共享每分钟 1,200 权重（多数 info 为 20；少数为 2；userRole 为 60）。另外，每个交易地址有基于累计成交量的 操作额度（初始缓冲 10,000 次请求）。WebSocket 另有上限（10 个连接、1,000 个订阅、10 个唯一用户）。若对大量钱包轮询，很容易触顶——这也是只读追踪器 Hyperfolio 存在的原因。

如果你在 Hyperliquid 上做机器人、看板或钱包追踪器，通常会先撞上 rate limit，而不是 API 里的冷门字段。官方文档准确，但分散在 REST 权重、WebSocket 上限和按地址的操作限制里。本指南把数字放在一处，说明真实轮询循环要花多少配额，以及何时该停掉自建轮询、改用现成追踪器。

Hyperliquid 的三层限流

并没有单一的“每秒 N 次请求”。限制是叠加的：

1. 按 IP 的 REST 权重 — 每次 HTTP 调用从该 IP 每分钟 1,200 的共享桶里扣权重。
2. WebSocket 连接与订阅上限 — 独立于 REST 权重；按币种或按用户各开一条连接很容易打满。
3. 按地址的操作限制 — 适用于已签名的交易动作（下单、撤单等），不适用于公开 info 读取。子账户视为不同用户。

公开的行情与账户读取（info）不收费，但不是无限。写操作走 HTTP 时仍占 IP 权重，并额外消耗地址额度。

REST 权重：每 IP 每分钟 1,200

同一 IP 上所有已文档化的 REST 请求共享合计 每分钟 1,200 权重。权重因接口而异：

请求类型	权重	说明
交易所动作（下单、撤单…）	1 + floor(batch_length / 40)	未批量 = 1；79 笔批量订单 = 2
l2Book、allMids、clearinghouseState、orderStatus、spotClearinghouseState、exchangeStatus	2	便宜的读接口——每秒轮询仍会积少成多
userRole	60	很贵；热循环里尽量别用
其他已文档化的 info	20	fills、funding、meta、K 线等的默认值
Explorer API	40	blockList 还有按区块附加权重

部分 info 会按返回条数加权重：每 20 条额外计一次（如 recentTrades、historicalOrders、userFills、userFillsByTime、fundingHistory、userFunding、nonUserFundingUpdates、twapHistory、userTwapSliceFills、userTwapSliceFillsByTime、delegatorHistory、delegatorRewards、validatorStats）。candleSnapshot 则按每 60 根 K 线加权重。大跨度历史拉取远比“权重 20”的标签更重——详见历史数据指南。

1,200 权重实际能买多少调用

在 IP 上限下的大致预算（忽略按条附加）：

• Clearinghouse / mids / L2 盘口：权重 2 → 约 600 次/分钟（约 10 次/秒）。
• 常见 info（成交、资金费、meta）：权重 20 → 约 60 次/分钟。
• userRole：权重 60 → 约 20 次/分钟。
• 混合追踪循环：每个钱包一次 clearinghouseState（2）+ 一次 userFillsByTime（20+）→ 大约每分钟 ~50 个钱包就会掏空 IP 桶，成交分页变长时更少。

批量交易所请求在 IP 权重上算 1 次（用上面的 batch 公式），但在地址限制上算 n 次。做市商批量撤单时这个不对称很关键。

WebSocket 上限（独立于 REST 权重）

官方上限：

• 最多 10 条 WebSocket 连接
• 每分钟最多新建 30 条连接
• 最多 1,000 个订阅
• 用户相关订阅合计最多 10 个唯一用户
• 所有连接合计每分钟最多向 Hyperliquid 发送 2,000 条消息
• 所有连接合计最多 100 个进行中的 post 消息

主网：wss://api.hyperliquid.xyz/ws。测试网：wss://api.hyperliquid-testnet.xyz/ws。若服务器在 60 秒内没有向你推送消息，会关闭连接——在安静频道发送 {"method":"ping"}，应收到 {"channel":"pong"}。自动化客户端必须处理重连；断连可能无公告发生，漏掉的数据会出现在重连快照 ack 中，或可用对应 info 补齐。

“10 个唯一用户”会直接打垮天真的多钱包追踪器：你无法在同一 IP 上为几十个地址订阅 userFills / clearinghouseState。要规模化监控投资组合，要么谨慎分摊 IP，要么使用已经聚合公开状态的产品——Hyperfolio 正是为此而建，且从不索取私钥。

按地址限制（仅交易动作）

按用户生效；子账户是独立用户。不适用于 info 读取。

• 额度大致为自地址启用以来每累计成交 1 USDC 对应 1 次请求，并有 10,000 次初始缓冲。
• 文档示例：名义 100 USDC 的订单，按该模型长期约需要 1% 的成交率来支撑请求消耗。
• 被限流后，该地址大约只能每 10 秒发 1 次请求。
• 撤单有更高累计上限：min(limit + 100000, limit * 2)，以便在普通操作额度用尽时仍能降低风险。

挂单上限：默认 1,000 张，每 5M USDC 成交量可多 1 张，封顶 5,000。当已有至少 1,000 张挂单时，新的只减仓或条件单可能被拒绝。

高拥堵时，地址大约只能使用其前一日 maker 份额的 2 倍区块空间（按类似手续费档位成交量贡献缩放；HIP-3 growth mode 资产贡献更少）。对已经返回结果的撤单反复重发会浪费额度。

账户抽象相关：unified account 与 portfolio margin 模式每天最多 50,000 次用户操作；standard 模式无此日上限。收取 builder fee 的地址须保持 standard 模式。

示例：每 5 秒轮询 20 个钱包

假设每 5 秒刷新 20 个地址的 clearinghouseState（权重 2）：

• 每分钟调用：20 × (60/5) = 240
• 每分钟权重：240 × 2 = 480 — 单独看还能接受

再为每个钱包每分钟加一次 userFillsByTime（权重 20 + 按条附加）：

• 额外权重：附加前 20 × 20 = 400
• 合计约 880 — 在成交分页变长或再加 metaAndAssetCtxs、funding、spot 之前仍低于 1,200

若改成每秒刷新做“实时”UI，仅 clearinghouse 就是 20 × 60 × 2 = 2,400 权重——已是 IP 预算的两倍。多数自制追踪器的 429 就从这里开始。对真正需要实时的少量地址用 WebSocket，缓存 mids/OI，其余交给已解决扇出的追踪器。

import time, requests

INFO = "https://api.hyperliquid.xyz/info"
WALLETS = ["0xabc…", "0xdef…"]  # 每个 IP 保持名单精简

def clearinghouse(user: str):
    r = requests.post(INFO, json={"type": "clearinghouseState", "user": user}, timeout=30)
    r.raise_for_status()
    return r.json()

# 每次约权重 2。控制节奏，留约 1000/分钟余量。
while True:
    for w in WALLETS:
        state = clearinghouse(w)
        equity = state.get("marginSummary", {}).get("accountValue")
        print(w, equity)
        time.sleep(0.2)  # 粗糙节流；生产环境请用令牌桶
    time.sleep(5)

对带签名的交易机器人，保持 agent wallet 与 nonce 干净（见API 钱包指南），并在接近地址上限时把撤单当作宝贵额度。

实操：如何留在限额内

1. 优先 WebSocket，少用 REST 轮询 — 针对你真正关心的少数用户推送 mids、trades、L2、成交与 clearinghouse。
2. 缓存重型 info — meta、资产上下文、OI、手续费档位相对 mark 变化更慢。
3. 有计划地分页历史 — 大批量历史用 S3 归档，而不是猛打 explorer（历史数据指南）。
4. 批量交易所动作可降低 IP 权重，但地址限制仍按子动作计数。
5. 只在必要时跨 IP 分摊只读负载 — 且不要在无限用户间共享一套 socket（10 用户上限）。
6. 做组合追踪可直接跳过基建 — 把地址粘贴到 app.hyperfolio.fun（免费 PWA、只读、无需 API key）。

Hyperfolio vs 自建轮询器

做一个私有 PnL 视图是周末项目——直到你要处理子账户、资金费、手续费、HIP-3 DEX、重连和 rate limits。Hyperfolio 已用公开数据展示权益、未平仓永续、已实现盈亏、资金费与多场所持仓。你不必烧掉 IP 配额、不必存密钥，还能把主账户与子账户一起看（见子账户与多钱包）。

若在 Hyperliquid 交易，使用推荐码 HYPERFOLIO 可在前 2,500 万美元成交量上获得 4% 手续费折扣：app.hyperliquid.xyz/join/HYPERFOLIO。详见推荐码指南。

常见问题

Hyperliquid 的 REST 限流是多少？

已文档化的 REST 流量共享每 IP 每分钟 1,200 权重。不同接口权重不同（常见 info 为 2、20 或 60；交易所动作为 1 + floor(batch/40)）。

info 请求计入按地址限制吗？

不计入。按地址限制只针对交易动作。info 读取只消耗 IP（以及 WebSocket）预算。

可以开多少条 WebSocket？

最多 10 条连接、每分钟 30 条新建、 1,000 个订阅，用户相关订阅最多 10 个唯一用户。

为什么一堆撤单和下单后会被限流？

很可能耗尽了地址额度（按成交量），即使 IP 权重看起来还行。撤单上限更高，但不是无限。被限流后降到约每 10 秒 1 次。

如何在不触顶的情况下追踪很多 Hyperliquid 钱包？

不要在同一 IP 上订阅几十个用户。使用 Hyperfolio 这类只读聚合器，或自建带缓存的队列、对少量白名单用 WebSocket、历史走 S3。

跳出限流跑步机：在 Hyperfolio 添加钱包，无需 API key 即可查看实时 PnL。在 Hyperliquid 交易？使用代码 HYPERFOLIO 享 4% 手续费折扣。