> For the complete documentation index, see [llms.txt](https://docs.nexus.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.nexus.xyz/api-reference/zh-cn/guides/rate-limits.md). # 速率限制 一个请求的成本是多少、速率限制响应头的含义、哪些预算彼此独立，以及超出每项预算时会发生什么。 交易所不按每秒请求数来分配您的流量预算，而是按**每秒权重**分配。每个请求都要计费，大多数请求花费一个单位，少数花费更多。按请求数自行限速的客户端，会在自身计数器看起来仍然正常时就被拒绝。这是集成此 API 时最常见的意外。 本页说明这一模型：各项操作的成本、哪些预算彼此独立，以及如何读取响应头。**规范性**定义是 OpenAPI 契约，发布于 [`nexus-xyz/nexus-exchange-api`](https://github.com/nexus-xyz/nexus-exchange-api)，并通过 `/openapi.json` 提供。API 描述中的“Rate limits”一节规定响应头的语义，每个操作都带有自身机器可读的成本。本页与契约不一致时，以契约为准。 ### 一个请求的成本 您的预算是一个**令牌桶，按您所在等级的每秒速率持续补充**，容量恰好为一秒的令牌。这一容量带来两个结果。持续速率与突发额度是同一个数字，因此无法通过闲置积攒多秒的储备。并且 `remaining` 永远不会超过 `limit`。 大多数请求的成本为**1**。例外情况如下： | 成本 | 适用于 | 原因 | | --------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------- | | **5** | `GET /account/summary`、`GET /fills`、`GET /orders/history`、`GET /account/portfolio-history`、`GET /positions/pnl`、`GET /account/activity`、`GET /stats/referrals`，以及除最后一项外所有操作的 `/api/v1` 对应版本 | 每个操作都要归并或扫描一个较大的单账户缓冲区（成交记录、订单历史、资产组合时间序列、合并后的活动流），或遍历所有未平仓仓位，或从账户后端汇总全交易所的邀请计数 | | **`1 + floor(order_count / 40)`** | `POST /orders/batch` | 最多40笔订单的成本与一笔相同；每多40笔增加一个单位 | | **1** | 契约记录的所有其他操作 | 默认值 | 因此，`limit: 20` 的 Pro 调用方在同一等级、同一预算下，每秒可以读取20次行情，**或读取4次 `/fills`**。请按权重限速，而不是按请求数。 两项安全属性限定了最坏情况。单个请求的收费上限为一秒的令牌，因此过大的批量请求永远不会变得无法满足。它会在令牌桶补满后耗尽整整一秒的令牌并得以通过，而不是在一个永远负担不起的重试上无限循环。此外，服务器无法解析的批量请求体按基础单位收费，而不会因权重问题被拒绝。 与其硬编码上表，不如从契约中读取成本：成本超过一个单位的操作带有 **`x-nexus-rate-limit-weight`**，成本取决于请求体的操作还带有 **`x-nexus-rate-limit-weight-formula`**。**对于契约记录的操作，没有该标记即表示权重为1**。客户端限流器应以此为依据构建。 这一限定条件很重要。契约列出了受支持的操作，该规则适用于所有这些操作，但契约对恰好能响应的其他路径只字未提。契约未列出的路由不带标记，不受该规则约束，其收费方式可能与没有标记所暗示的不同。请针对契约记录的操作进行构建，而不是针对通过探测发现的路径。权重和本页描述的正是这些操作。 ### 四项预算，而非一项 共有四个相互独立的资源类别。消耗其中一个不会消耗其他类别，并且每个类别都有自己的拒绝方式： | 类别 | 涵盖范围 | 计入 | | ----------------- | --------------------------------------------------------------------- | ----------------------------------------------- | | **请求** | 所有非订单写入的 REST 操作 | 您的按密钥和按所有者请求桶 | | **交易操作** | `/orders` 下的 `POST` 和 `PATCH`，标记为 `x-nexus-rate-limit-class: trading` | 一个专用的订单桶，每秒容量与请求桶相同 | | **撤单** | `/orders` 下的 `DELETE`，同样标记为 `x-nexus-rate-limit-class: trading` | 一个**独立的**撤单桶，每秒容量同样相同 | | **WebSocket 控制面** | 连接、订阅和客户端入站帧 | 按等级设定的上限。参见 [WebSocket 上限](#websocket-ceilings) | 订单写入**改为**计入交易桶，而不是计入请求桶，也不会在请求桶之外额外计费。由于这种拆分，大量轮询不会挤占您的下单额度，订单流也不会挤占您的读取额度。由此可知，**上一次读取时 `x-ratelimit-remaining` 显示充足，并不能说明您的下单余量。** 它们是不同的池，因此请读取您即将消耗的那个池。`GET /account/rate-limit` 在 `buckets` 中分别报告每项预算，`buckets.order` 可以回答您能否下单。 #### 撤单从不与提交共用令牌 撤单是唯一从交易中拆分出来、拥有独立预算的操作。对订单端点的 `DELETE`（撤销单笔、全部撤单或按市场撤单）计入撤单桶而非订单桶，因此**一个已用完全部下单提交额度的密钥，仍然拥有完整、未被动用的撤单额度。** 这是该模型中唯一刻意设计的不对称。提交可以等待，降低风险不能等待。如果限流器在仓位对您不利时拒绝您的撤单，就会把公平性控制变成亏损。因此该规则是无条件的。耗尽提交额度永远不会导致撤单被拒绝，因为二者从不消耗同一个令牌。 对客户端而言，这意味着： * **切勿从提交时收到的 `429` 推断您的撤单余量。** `order` 桶为空并不能说明 `cancel` 桶的情况。一次下单被拒绝后就对所有订单调用进行退避的客户端，恰恰限流了它仍然应该发出的那个调用。 * **独立的桶并不是绕过限制的途径**。撤单与其他操作一样按等级的每秒速率计量，因此撤单循环仍可能收到 `429`。它带有 `bucket: cancel`，这是唯一表示您的撤单通道已饱和的拒绝。对这种拒绝，请遵循 `retry-after`。 修改订单按提交计费，而不是按撤单计费。`PATCH` 并不表明修改是减少还是增加敞口，而增加数量的修改无论怎么看都是一次提交。因此，上述保证仅适用于始终降低风险的那种方法。如果您需要这一保证，请撤单。 `POST /orders/preview` 也是一项交易操作，这一点很容易被忽略。它是 `/orders` 下的写入操作，花费一个交易类单位，与下单相同。因此，每次下单前都预览会使您的有效下单速率减半。以这种方式下的每笔订单，请按两次交易类收费来规划预算；或者在已经确定数量后跳过预览。 出示 HMAC 密钥的调用方要依次通过**按密钥**的桶和其等级对应的**按所有者**的桶，有效上限取先触及的那一个。`GET /account/rate-limit` 报告这一最小值，并且轮询它是免费的。它是唯一不消耗令牌的操作，因此用它来自行限速不会导致您被限流。 如果您刚刚升级了等级，请注意，密钥自身的上限在创建密钥时记录（默认20/s），等级变更不会改写它。因此，仍在使用按默认值创建的密钥的 Market Maker 账户，可能会受限于密钥的数值而非等级的数值。升级后请读取 `/account/rate-limit`，而不是假定为等级对应的数值；如果报告的最小值不符合预期，请创建一个新密钥。 ### 读取响应头 * 在**每个**经过认证的响应上：`x-ratelimit-limit` 和 `x-ratelimit-remaining`。 * **仅在 `429` 上**额外提供：`x-ratelimit-reset`（Unix 秒）和 `retry-after`（秒，从不低于1）。 不要指望在成功响应中看到后两者。从2xx 响应中读取 `x-ratelimit-reset` 的客户端什么也读不到。 **`remaining` 和 `retry-after` 使用不同的单位，这是有意为之。** `remaining` 以单位成本请求计数，因此 `x-ratelimit-remaining: 10` 表示十个权重为1的请求，*或*两个重型请求。`retry-after` 由被拒绝请求的加权成本推导得出。如果限流器把 `remaining` 理解为“我即将发送的那类请求的数量”，就会在重型端点上超发，自己触发429。 拒绝响应为 `HTTP 429`，响应体如下： ```json { "code": "RATE_LIMIT_EXCEEDED", "message": "Order placement rate limit exceeded", "bucket": "order", "tier": "Pro" } ``` 先按 `code` 分支，再按 **`bucket`** 分支。它的取值为 `key`、`owner`、`order`、`cancel`、`ip` 或 `login` 之一，对于前四个，它就是在 `GET /account/rate-limit` 的 `buckets` 中查找所用的键。`ip` 和 `login` 从不出现在那里。二者计量的都是连接而非账户，并且 `login` 在账户尚未建立之前就会被拒绝。同样的值也通过 `x-ratelimit-bucket` 响应头发送，因此代理或重试封装无需解析响应体即可读取。`message` 指明是哪个池耗尽了（`Rate limit exceeded`、`API key rate limit exceeded`、`Order placement rate limit exceeded` 或 `IP rate limit exceeded`）。它仅用于**诊断**。其措辞并不稳定，因此不要以编程方式匹配它。 与因司法辖区而返回的 `403` 拒绝不同，`429` **可以**重试：请遵循 `retry-after` 并进行退避。依据 `x-ratelimit-remaining` 限速，胜过撞上上限后才发现它。 免费的 `GET /account/rate-limit` 无需消耗令牌即可报告同样的状态。顶层字段对应请求类别，`buckets` 涵盖每项预算： ```json { "tier": "pro", "limit": 20, "remaining": 17, "reset_at_ms": 1750000000123, "buckets": { "key": { "limit": 20, "remaining": 17, "reset_at_ms": 1750000000123 }, "owner": { "limit": 20, "remaining": 19, "reset_at_ms": 1750000000051 }, "order": { "limit": 20, "remaining": 20, "reset_at_ms": 0 }, "cancel": { "limit": 20, "remaining": 20, "reset_at_ms": 0 } } } ``` **`buckets` 的键与 `429` 所用的标签相同**，无论是其 `bucket` 字段还是 `x-ratelimit-bucket` 响应头。因此，一次拒绝可以直接映射到导致它的状态：`buckets[error.bucket]`。请围绕这一查找来构建您的限流器。`key` 仅在按密钥的桶对您起限制作用时出现，而 `ip` 和 `login` 从不出现，因为二者计量的都是连接而非账户。 顶层的 `limit`、`remaining` 和 `reset_at_ms` 对应**请求**类别，保持不变，因此读取它们的代码无需任何改动。它们无法回答“我能否下单”。`buckets.order` 可以。对于一个刚刚通过报价触及提交上限的密钥，二者会完全不一致：`remaining: 20` 与 `buckets.order.remaining: 0` 同时出现。 同时使用此端点和响应头时，有两个细节需要处理。`reset_at_ms` 以**毫秒**为单位，而 `x-ratelimit-reset` 响应头以 Unix **秒**为单位。此外，等级名称在这里为小写（`pro`），在 `429` 响应体中则不是（`Pro`），因此请以不区分大小写的方式比较，而不是与字面值比较。 对于 `Unlimited` 调用方，这三个数值字段均为 `null`，因为它按 IP 而非按账户分桶。`buckets` 返回 `{}`，因为没有任何账户范围的预算对该调用方进行计量。 ### 等级与当前上限 等级是同一模型上的倍数，而不是不同的模型。**Pro** 是每个账户的默认等级。**MarketMaker** 由管理员分配。请通过您的 Nexus 联系人申请，并参阅[做市商指南](https://docs.nexus.xyz/exchange/apis-and-rates/market-maker-guide)。**Unlimited** 用于复用许多用户的网关密钥，从不分配给交易账户。 | 等级 | 请求 | 交易操作 | WS 连接 | WS 订阅 | WS 入站帧 | | ------------- | --------- | ------------------- | ----- | ----- | ------ | | `Pro` | 20/s | 20/s | 5 | 50 | 10/s | | `MarketMaker` | 2,000/s | 2,000/s | 100 | 1,000 | 50/s | | `Unlimited` | 按 IP，50/s | 按 IP，50/s，与读取共用同一个桶 | 豁免 | 豁免 | 豁免 | 有三项限制与等级无关，全部作用于您持有凭证之前。未经认证的行情数据读取**按客户端 IP 分桶，速率为50/s**。`POST /auth/login` 单独计量，且严格得多，为**每个客户端 IP 5/s**，拥有独立的池。一次登录尝试需要对 EIP-191 签名执行一次 ecrecover，任何能访问该端点的人都能让服务器承担这一成本。该限制并非防范猜测密钥，因为被签名的消息是一个固定常量，没有什么可以暴力破解。它是一种成本防护。完全无法解析客户端 IP 的流量也不会被不加限流地放行。读取共用一个严格的5/s 桶，登录共用**另一个独立的**桶，因此去除了 `x-forwarded-for` 的洪泛流量无法耗尽其余无法解析来源的流量所依赖的池。无法解析的来源会得到一个较低的上限，而不是没有上限。 登录拒绝带有 `bucket: login`，这是唯一表示登录关口本身已饱和的拒绝。它是按 IP 的上限，因此您与同一 NAT 或出口代理后的所有人共享它，它不能说明您账户的任何情况。此时账户还不存在。 撤单拥有独立的预算，速率与交易操作相同（`Pro` 另有20/s，`MarketMaker` 另有2,000/s）。表中没有为撤单单独设列，因为这两个数字按设计相等。 `Unlimited` 的豁免范围比其名称所暗示的更窄。它的订单写入**和撤单**都**不**豁免速率限制。它们既不经过专用交易桶，也不经过撤单桶，而是与其读取计入同一个按 IP 的桶。因此，上述类别独立性和撤单保证在这里都不成立，网关自身的轮询可能挤占其订单流，而这恰恰发生在流量构成最难预测的等级上。它所豁免的 WS 上限是*按账户*的上限。下文按 IP 的连接上限仍然有效。 **这些数字是当前的默认值，而不是契约**。它们属于部署配置（其中一些仍是代码常量），并会随着等级体系的最终确定而变化。请读取 `/account/rate-limit`，而不是硬编码这些数字。 ### WebSocket 上限 WebSocket 上限自成一个资源类别，独立于 REST 请求预算和交易操作预算。耗尽其中一个不会影响其他类别。 **连接**数按等级对每个账户设限（Pro 5，MarketMaker 100）。另有一个独立的**按 IP 上限，默认为5**，在升级连接时优先生效，并适用于包括 `Unlimited` 在内的所有等级，因此单个来源地址无法独自达到按账户的上限。在此被拒绝的连接会在升级请求上收到 `HTTP 429`（`ws_conn_limit_exceeded`），而不是关闭帧。无论哪种情况，一次性流令牌都会被消耗，因此重新连接前请创建一个新令牌。 **订阅**数受同一个数字的双重限制：按连接*以及*跨账户的所有连接。因此，打开更多套接字并不能换来更多订阅。重新订阅您已持有的 `(channel, market)` 键会原地替换它，且不计费。超出上限会返回一个 `error` 帧（`subscription_limit_exceeded`），而不是状态码，因为套接字打开后就不再有 HTTP 响应。 **入站帧**（您的订阅、取消订阅和 ping）限制在按等级的持续速率内，并允许在其之上有**2倍突发**，因此重新连接并重新订阅的高峰不会受到惩罚。超出之后，服务器会**丢弃**超限帧，并且每个计量时间窗口只发送一次 `error` 通知，而不是每帧一次，这样入站洪泛就不会变成出站洪泛。持续洪泛，即在一个时间窗口内被丢弃的帧达到足够数量，会以代码 **`1008`**（违反策略）关闭连接。服务器不会处理被丢弃的帧，也不会通知您。如果您没有看到 `subscribed` 确认，请在退避后重新发送订阅，而不要假定它已生效。 ### 预算按网络划分 每个网络都是独立的部署，因此**每个网络都有自己的桶**。主网上线后，在测试网上的消耗不会减少主网的余量，反之亦然。凭证也不能跨网络使用。密钥绑定到创建它的网络。参见[网络](/api-reference/zh-cn/guides/networks.md)。 ### 当前的执行位置 有一项当前的限制可以从外部观察到，它对您有利而非不利。 网关进程将限流器状态保存在**内存中**，而不是共享存储中。这带来两个结果。第一，它不持久。重新部署会重置您的桶，等级升级可能会短暂回落到基础等级，直到重新应用为止。第二，当一个网络的网关运行多个副本时，每个副本都持有自己的桶，因此客户端观察到的*总体*上限可能高于公布的每秒数值，具体取决于其连接落在哪些副本上。 不要依赖这部分余量进行设计。请把公布的数字当作您有权使用的上限，并据此限速。额外的余量来自当前执行所在的位置，分布并不均匀，并且会在计数器迁移到共享存储后消失。按公布数值构建的客户端在那之后仍能正常工作。按观察到的总体上限调优的客户端则会开始收到429。 ### 您的签名器跟得上吗？ 客户端在每个经过认证的请求发出前对其签名，因此签名器在上述预算之下又设定了一个自身的上限。选择 SDK 之前请先检查这一上限。它取决于签名方案和加密库的程度，远大于取决于编程语言的程度。 交易所接受两种请求签名方案（参见[身份验证](/api-reference/zh-cn/guides/authentication.md#signing-a-request-with-the-key)和[代理](/api-reference/zh-cn/guides/agent-keys.md)）： * **HMAC**（`hmacAuth`）。对五字段规范字符串计算 HMAC-SHA256，密钥为经十六进制解码的 API 密钥 secret。对称 MAC 在任何语言中都只需几微秒。 * **代理密钥**（`agentAuth`）。对六字段规范字符串的 `keccak256` 进行 secp256k1 ECDSA 签名，采用 low-S，以65字节的 `r||s||v` 发送。它是椭圆曲线签名，因此其成本取决于底层库是原生代码还是纯解释执行的代码。 测量方法：通过每个 SDK 自身的签名路径，针对一个固定的 `POST /api/v1/orders` 请求体，在单线程上运行。这与客户端在每个请求上执行的调用相同，包括构建规范字符串、对请求体做哈希和对结果做十六进制编码，但不含网络 I/O： | SDK | 方案 | 底层加密库 | p50 | p95 | 签名次数/秒 | 5次运行的 p50 范围 | | ------------------------------- | ---- | ------------------------------ | -----: | -----: | ----------: | ------------ | | Rust（`nexus-exchange-rs`） | HMAC | `hmac` + `sha2` | 0.9 µs | 0.9 µs | \~1,080,000 | 0.88–0.96 µs | | Rust（`nexus-exchange-rs`） | 代理密钥 | `k256` | 79 µs | 91 µs | \~12,500 | 74–79 µs | | TypeScript（`nexus-exchange-ts`） | HMAC | Web Crypto（异步） | 27 µs | 43 µs | \~29,000 | 24–35 µs | | TypeScript（`nexus-exchange-ts`） | 代理密钥 | `@noble/curves` | 319 µs | 470 µs | \~2,900 | 293–645 µs | | Python（`nexus-exchange-py`） | HMAC | 标准库 `hmac` | 2.1 µs | 2.2 µs | \~460,000 | 1.96–2.25 µs | | Python，默认安装 | 代理密钥 | `eth-keys` 纯 Python 后端 | 3.5毫秒 | 4.2毫秒 | \~280 | 3.43–4.11毫秒 | | Python + `coincurve` | 代理密钥 | 通过 `coincurve` 调用 libsecp256k1 | 97 µs | 110 µs | \~10,000 | 96–116 µs | CLI 通过 Rust crate 签名，因此沿用 Rust 各行的数据，没有自己的数字。 **在 `Pro` 等级，任何 SDK、任何方案都不会受签名器限制。** 每秒20个请求意味着每次签名有50毫秒。最慢的一行，即默认 Python 安装下的代理密钥签名，只用去其中的3.5毫秒，因此它在单核上的签名速度约为 Pro 速率的十四倍。即使调用方同时用满全部三个 Pro 桶（请求、交易操作和撤单，每秒60个签名请求），签名也只占用约五分之一个核心。TypeScript 的代理密钥签名器拥有一百倍以上的余量，而 HMAC 在每个 SDK 中实际上都没有成本。 **在 `MarketMaker` 等级，签名方案和库开始变得重要。** 其每秒2,000次交易操作，加上另外独立的2,000次撤单，在单线程上每次签名只有0.25–0.5毫秒。 * **Python 搭配代理密钥**：默认安装每秒约签名280次，大约是交易上限的七分之一。在同一环境中安装 `coincurve`（`pip install coincurve`），`AgentSigner` 就会改为运行在 libsecp256k1 上，每秒约10,000次，且无需修改您的代码。SDK 本身不选择曲线后端；只要能导入 `coincurve`，`eth-keys` 就会使用它，除非 `ECC_BACKEND_CLASS` 环境变量指定了其他后端。Python 基准测试会打印它所测量的后端，这是确认切换是否生效的最快方法。或者使用 HMAC 签名，它从来不是瓶颈。 * **TypeScript 搭配代理密钥**：每秒约2,900次，在单核上足以满足交易上限，但无法同时满足交易和撤单。以全速同时运行二者的客户端应使用 HMAC 签名，或将签名分散到多个 worker 线程中。 * **Rust 和 CLI**：两种方案都绰绰有余。 就单个请求而言，签名在 TypeScript 中增加0.3毫秒，在默认 Python 代理密钥安装下增加3.5毫秒。相对于以数十毫秒计的客户端往返时间，这只是一小部分，但在 Python 路径上能感觉得到。如果您使用 Python 搭配代理密钥进行交易，这是安装 `coincurve` 的又一个理由。 #### 与 Paradex 公布数据的比较 Paradex 公布了一张类似的表格：Rust 约每秒5,000次签名，Go 1,430次，TypeScript 50次，Python 或 Java 8次。按字面理解，TypeScript 每次签名20毫秒，单线程上限为每秒50次签名。这足以覆盖单个20/s 的预算，但仅签名就会占用40% 的核心，并且达不到 Pro 调用方在请求、交易操作和撤单上合计可用的60/s。这些数字并不适用于此处。Paradex 使用 StarkNet 密钥为订单签名，其曲线和哈希都与这里的两种方案不同，而且其数字并非在下述硬件上测得，因此两张表之间的比例最多只能说明方向。但规律是相通的。纯解释执行代码中的椭圆曲线签名器是慢的情况，原生绑定能弥补大部分差距。不同之处在于，这里慢的情况（Python 使用其纯 Python 后备实现，每秒约280次）仍比 Pro 等级所需快十倍以上。 #### 测试方法 * **硬件**。Apple M2，8核（4个性能核心，4个能效核心），8 GB，macOS 26.5（build 25F84），接通交流电源且关闭低电量模式。macOS 无法将进程绑定到某个核心，并且机器在测试期间并非空闲（运行期间负载平均值为4–14），因此请将 p95 列和波动范围视为上限。 * **运行时**。Rust 1.97（release 配置），Node.js 22.23，HMAC 行和默认代理密钥行使用 Python 3.14。`coincurve` 行运行在 Python 3.13 上，因为 `coincurve` 尚未发布 Python 3.14 的 wheel。默认代理密钥行在3.13上的测量结果相同（3.5毫秒），因此差异并非由解释器造成。 * **测试夹具**。三个 SDK 完全相同：`POST`，路径 `/api/v1/orders`，空查询，一个155字节的限价单请求体，固定时间戳。代理签名器在每次迭代时都生成新的 nonce，与真实写入时一样。对于此夹具，两种方案在各 SDK 之间生成的签名逐字节相同。 * **过程**。先预热两秒，然后对每次签名单独计时（Rust 20,000次，TypeScript 5,000次，Python 3,000或5,000次），并从样本中取 p50 和 p95。每秒签名次数是样本数除以计时循环的实际耗时。每个基准测试运行五次，与其他测试交错进行。表中显示中位数那次运行，以及全部五次运行的 p50 范围。Rust 基准测试还运行了 criterion，其均值估计与计时循环一致（代理密钥为76–85 µs）。 * **重新运行**。每个 SDK 都带有其基准测试：`nexus-exchange-rs` 中的 `cargo bench --bench signing`，`nexus-exchange-ts` 中的 `pnpm bench`，以及 `nexus-exchange-py` 中的 `python bench/signing_bench.py`。Python 基准测试会打印它所测量的 `eth-keys` 后端。 ### 针对限制进行设计 * **使用批量而非循环**。`POST /orders/batch` 收费 `1 + floor(n / 40)`，因此一个请求中的40笔订单，成本是40次单独提交的四十分之一。 * **使用流式推送而非轮询**。通过 WebSocket 获取订单簿和成交数据不消耗您的请求预算，而且到达得更快：订阅帧只是一个入站帧，之后的数据流是免费的。 * **按真实成本为重型读取规划预算**。`/fills`、`/orders/history`、`/account/summary` 和 `/account/portfolio-history` 的成本各为5。每秒轮询全部四个会花费20/s，这就是 Pro 调用方的全部预算。 * **优先使用一次一致的读取**。`GET /account/state` 同时返回摘要和所有未平仓仓位。它比两次调用更便宜，也不存在两次调用之间的竞态（参见[资产组合与账户状态](/api-reference/zh-cn/guides/portfolio.md)）。 * **缓存不变的数据**。来自 `GET /markets` 的市场元数据无需在每个周期重新获取。 * **依据响应头和 `/account/rate-limit` 限速。** 轮询该端点是免费的。在收到 `429` 后盲目重试则不是。 ### 相关内容 * [OpenAPI 规范](https://github.com/nexus-xyz/nexus-exchange-api)：规范性的各操作权重、类别和响应头语义 * [网络](/api-reference/zh-cn/guides/networks.md)：如何选择网络，以及密钥如何绑定到某个网络 * [资产组合与账户状态](/api-reference/zh-cn/guides/portfolio.md)：重型读取端点，以及如何通过一次调用读取它们 * [速率与连接限制](https://docs.nexus.xyz/exchange/apis-and-rates/rate-limits)：HMAC 时间窗口、令牌有效期、水龙头额度 * [做市商指南](https://docs.nexus.xyz/exchange/apis-and-rates/market-maker-guide)：申请 MarketMaker 等级 * [接口概览](/api-reference/zh-cn/readme.md) > **状态**：测试网上的开发预览版。主网尚未上线。本页的每个上限都是当前配置，而非固定的契约。在生产环境中请读取 `/account/rate-limit`，而不是硬编码某个数字，并固定到某个已发布的规范版本，使您所依据的各操作权重保持不变。限流器状态在网关重启后尚不持久。测试网凭证和余额没有任何现实价值。 --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.nexus.xyz/api-reference/zh-cn/guides/rate-limits.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.