如何解决 RPC 429 Too Many Requests 错误

RPC 429 错误代表什么

HTTP 429 Too Many Requests 是一种限流响应。区块链 RPC 提供商可能根据 API Key、账户、IP 地址、方法、网络、请求单元或时间窗口实施限制。因此，即使每天的请求总量看起来不高，短时间的流量突增仍然可能触发 429。

应当把该响应视为容量信号，而不是普通的临时网络故障。立即重试每一个失败请求会进一步放大导致限流的流量峰值，并可能延长故障时间。

首先确定限流范围

修改应用代码前，先检查提供商控制台和响应头。记录发生错误的网络、JSON-RPC 方法、端点、区域和 API Key，并将错误时间与部署事件、索引器历史回填、流量峰值和定时任务进行对照。

• 确认额度按照请求数、响应单元、计算单元还是并发连接数计算。
• 区分持续性流量和短时间突发流量；两者需要不同的控制方式。
• 找出高成本方法，例如超大范围的 eth_getLogs、trace 调用或历史状态查询。
• 检查多个服务是否共用了同一个 API Key 或公共端点。
• 如果响应中提供了 Retry-After 或服务商特定的限流头，请一并检查。

使用指数退避和随机抖动安全重试

只对幂等的读取请求进行自动重试。每次失败后逐步增加等待时间，并加入随机抖动，避免多个工作进程在同一时刻再次发起请求。同时设置最大尝试次数，并在重试预算耗尽后返回可控错误。

async function rpcRequest(url: string, body: unknown) {
  const maxAttempts = 5;

  for (let attempt = 0; attempt < maxAttempts; attempt += 1) {
    const response = await fetch(url, {
      method: "POST",
      headers: { "content-type": "application/json" },
      body: JSON.stringify(body),
    });

    if (response.ok) return response.json();
    if (response.status !== 429) throw new Error(`RPC failed: ${response.status}`);

    const retryAfter = Number(response.headers.get("retry-after"));
    const exponentialDelay = Math.min(500 * 2 ** attempt, 10_000);
    const jitter = Math.floor(Math.random() * 250);
    const delay = Number.isFinite(retryAfter)
      ? retryAfter * 1000
      : exponentialDelay + jitter;

    await new Promise((resolve) => setTimeout(resolve, delay));
  }

  throw new Error("RPC rate limit retry budget exhausted");
}

减少可以避免的 RPC 流量

重试能够缓解短暂的流量峰值，但无法解决持续性的超额使用。在提高容量之前，应先减少请求数量和请求成本。

• 缓存稳定结果，例如 Chain ID、代币元数据、已最终确认的区块和合约配置。
• 对相同的进行中请求去重，让并发用户共享一次上游调用。
• 当端点支持批处理时，将兼容的 JSON-RPC 读取请求合并发送。
• 使用 WebSocket 订阅接收实时事件，避免每个客户端持续轮询新区块。
• 将大范围 eth_getLogs 查询拆分成有边界的窗口，并为已完成区间保存检查点。
• 通过队列或令牌桶限制工作进程并发，而不是同时启动全部任务。

按生产环境容量设计 RPC 客户端

生产级 RPC 客户端应结合超时、有限重试、并发限制、缓存和可观测性。持续跟踪 429 比例、延迟、错误率、请求单元、方法分布和队列深度，并在应用达到硬性容量上限前发出告警。

为开发、预发布、历史回填和生产工作负载使用不同的 API Key 或端点，避免历史数据任务耗尽面向用户业务所需的容量。对于关键应用，应使用额度可测量、并且具备明确专用基础设施升级路径的托管端点。

什么时候应该提高 RPC 容量

当优化后的流量仍持续接近套餐上限、面向用户的请求因排队而出现延迟，或关键方法消耗的单元超过共享方案承载能力时，就应提高容量。对于需要资源隔离的工作负载，OnFinality 提供带请求分析功能的托管 RPC 端点和专用节点方案。

前往 /pricing/rpc 比较当前 RPC 套餐，在 /networks 查看支持的网络，或者通过 OnFinality API 服务创建端点。