Logo
新用户订阅 RPC,首月享 6.5 折优惠查看优惠
RPC Assistant

Polygon RPC:如何选择能承受生产流量的端点

摘要

Polygon RPC 是你的应用用来在 Polygon PoS 上读取链状态、提交交易和订阅事件的 HTTP 和 WebSocket 端点。早期选择的端点往往会成为你凌晨两点调试的端点,因此值得根据真实工作负载来选择,而不是从教程中快速复制粘贴。

本页介绍了端点形态、链设置、请求模式以及流量增长后出现的故障模式。它还解释了何时共享公共端点就足够,以及何时 OnFinality 的托管 RPC API 或专用节点更合适。

Polygon RPC 是你的应用调用来在 Polygon PoS 网络上读取状态、发送交易和订阅事件的 JSON-RPC 端点。如果你搜索了“polygon rpcs”,你可能需要以下三件事之一:一个立即可用的端点、一种在提交前比较端点的方法,或者修复一个在负载下开始出现异常的端点。本页涵盖所有这三个方面,从最重要的决策开始。

快速推荐:哪种 Polygon RPC 适合你的工作负载

将端点与你的应用实际做的事情匹配,而不是与教程使用的内容匹配。

工作负载合理的起点需要注意什么
本地脚本、一次性读取、钱包测试公共端点速率限制、共享容量、无 SLA
具有稳定读取流量的 dApp 前端托管 RPC API吞吐量上限、归档访问、WebSocket 支持
索引器、机器人、高频写入托管 RPC API 或专用节点持续 RPS、连接限制、trace/debug 方法
具有严格延迟需求的交易所或桥接专用节点区域、冗余、故障转移路径
对旧区块的分析支持归档的端点归档深度、eth_getLogs 范围限制

如果你还在原型设计阶段,公共端点就足够了。一旦真实用户或真实资金触及应用,就转向托管 RPC API,例如 OnFinality 的 RPC 服务,并在你的流量可预测且繁重时考虑使用专用节点。

Polygon RPC 端点究竟是什么

Polygon PoS 是一条 EVM 兼容链,因此其 RPC 表面是标准的以太坊 JSON-RPC 接口。你的客户端通过 HTTP POST 发送 JSON 正文(或打开 WebSocket)并返回结果。Polygon 主网的链 ID 是 137,原生货币是 POL,规范浏览器是 polygonscan.com。

Polygon 主网的公共 OnFinality 端点如下所示:

https://polygon.api.onfinality.io/public

该 URL 接受 HTTP 和 WebSocket 流量。对于轻量测试之外的任何用途,你通常会使用 API 密钥,以便你的流量归属于你的账户,而不是共享容量。

链设置一览

在将 Polygon 添加到钱包或客户端配置时使用这些值。

设置值
网络名称Polygon Mainnet
链 ID137
原生货币POL(18 位小数)
区块浏览器https://polygonscan.com
RPC 传输HTTP 和 WebSocket
测试网对应Polygon Amoy,链 ID 80002

对于测试网工作,Amoy 端点是 https://polygon-amoy.api.onfinality.io/public,链 ID 为 80002,浏览器为 https://amoy.polygonscan.com。将主网和测试网配置放在单独的环境文件中,这样错误的链 ID 永远不会到达生产环境。

JavaScript 中的最小钱包或客户端配置:

const polygon = {
  chainId: "0x89", // 137
  chainName: "Polygon Mainnet",
  nativeCurrency: { name: "POL", symbol: "POL", decimals: 18 },
  rpcUrls: ["https://polygon.api.onfinality.io/public"],
  blockExplorerUrls: ["https://polygonscan.com"],
};

读取和写入:主导流量的调用

大多数 Polygon RPC 流量是一小组方法。知道哪些调用最频繁可以告诉你需要优化什么。

  • eth_chainId 和 net_version 用于连接检查。
  • eth_blockNumber 和 eth_getBlockByNumber 用于链头跟踪。
  • eth_getBalance、eth_call 和 eth_getCode 用于读取。
  • eth_getLogs 用于事件索引,通常是最重的调用。
  • eth_sendRawTransaction 用于写入。
  • 通过 WebSocket 的 eth_subscribe 用于新块头和日志。

使用 curl 进行快速连接检查:

curl -s https://polygon.api.onfinality.io/public \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}'

如果返回十六进制区块号,则你的端点可达。如果挂起,问题通常是网络路径或端点可用性,而不是你的负载。

Polygon RPC 在真实流量下会在哪里出问题

端点问题很少在 hello-world 测试中出现。当并发、日志范围或订阅增长时,它们就会出现。

症状可能原因初步修复
429 响应共享容量的速率限制迁移到带密钥的托管端点
eth_getLogs 超时区块范围太宽分块范围,添加分页
订阅丢失WebSocket 连接频繁断开重连逻辑、心跳 ping
区块头陈旧负载均衡节点滞后路由前进行健康检查
缺少旧状态非归档节点使用支持归档的端点
高峰时写入缓慢共享节点上的争用专用节点或更高层级

一个简单的监控探针可以在用户之前捕获大多数这些问题:

async function probe(url) {
  const start = Date.now();
  const res = await fetch(url, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ jsonrpc: "2.0", id: 1, method: "eth_blockNumber", params: [] }),
  });
  const body = await res.json();
  return { ok: res.ok, ms: Date.now() - start, block: body.result };
}

对你依赖的每个端点运行此操作,记录延迟和区块高度,并在某个提供商落后于其他提供商时发出警报。

WebSocket 订阅以及何时使用它们

轮询 eth_blockNumber 可行,但会浪费请求。如果你的应用需要实时更新,请打开 WebSocket 并订阅:

const ws = new WebSocket("wss://polygon.api.onfinality.io/public");
ws.onopen = () => {
  ws.send(JSON.stringify({
    jsonrpc: "2.0", id: 1,
    method: "eth_subscribe",
    params: ["newHeads"],
  }));
};
ws.onmessage = (event) => console.log(JSON.parse(event.data));

WebSocket 连接是有状态的,因此要规划重连、退避和重复事件处理。如果你的提供商不支持 WebSocket,你就只能轮询,这会增加请求量和成本。

评估 Polygon RPC 提供商

当你比较提供商时,要根据你的工作负载进行比较,而不是通用功能列表。OnFinality 在这里首先出现,因为它是本页围绕的选项,但这些标准适用于任何提供商。

提供商传输归档 / trace专用选项备注
OnFinalityHTTP、WebSocket按需提供是托管 RPC API 加专用节点
提供商 BHTTP因层级而异有时检查每个计划的归档深度
提供商 CHTTP、WebSocket有限很少确认 WebSocket 限制

向每个提供商提出相同的问题:每个计划的持续请求速率是多少,是否包含归档数据,是否暴露 debug 和 trace 方法,WebSocket 连接如何计数,以及在链升级或重组期间会发生什么。你可以在如何选择 RPC 提供商中阅读更完整的框架。

故障转移和冗余,避免过度设计

单个端点就是单点故障。你不需要复杂的网状结构,但你需要一个备用方案。

  1. 保留一个主端点和一个来自不同提供商或区域的辅助端点。
  2. 定期对两者进行健康检查,并路由到健康的那个。
  3. 对于写入,使用相同的已签名交易重试,而不是重新签名。
  4. 记录每个请求由哪个端点服务,以便事件可追溯。
  5. 每次提供商或计划变更后重新测试故障转移。

对于大多数生产 dApp 来说,这已经足够了。有严格正常运行时间需求的团队通常会转向专用节点,这样容量就不会共享。

成本和容量规划

RPC 成本跟踪请求量、方法权重和连接数。读取很便宜;大范围的 eth_getLogs 和归档查询很昂贵。在扩展之前,估算你的峰值每秒请求数、平均日志范围以及保持打开的 WebSocket 客户端数量。然后选择一个留有空间的计划,并根据该估算查看 RPC 定价,而不是猜测。如果你的使用量是突发的,托管 API 比固定大小的节点更能吸收峰值。

关键要点

  • Polygon RPC 是标准的 EVM JSON-RPC 端点;链 ID 137,原生货币 POL。
  • 公共端点适合测试;生产应用应使用带密钥的托管端点。
  • eth_getLogs、归档读取和 WebSocket 订阅是最有可能在负载下中断的调用。
  • 在吞吐量、归档深度、trace 支持、WebSocket 限制和故障转移方面比较提供商。
  • 保留一个辅助端点,并在需要之前对其进行健康检查。
  • OnFinality 为 Polygon 提供托管 RPC API 和专用节点;请参阅支持的 RPC 网络获取当前列表。

常见问题

Polygon 主网 RPC 端点是什么?

OnFinality 的公共 Polygon 主网端点是 https://polygon.api.onfinality.io/public,支持 HTTP 和 WebSocket。对于生产环境,请使用 Polygon 网络页面中的带密钥端点。

Polygon 使用什么链 ID?

Polygon 主网使用链 ID 137(0x89)。Amoy 测试网使用 80002。

我需要为 Polygon 使用归档节点吗?

仅当你查询历史状态或宽日志范围时需要。标准读取和最近区块在非归档节点上可以工作。

我可以将 WebSocket 与 Polygon RPC 一起使用吗?

可以。OnFinality 的 Polygon 端点支持 WebSocket,这对于在新块头和日志上使用 eth_subscribe 很有用。

如何修复来自 Polygon RPC 的 429 错误?

429 响应意味着你触发了速率限制。迁移到带密钥的托管端点,减少请求量,或在可能的情况下批量调用。

何时应使用专用 Polygon 节点而不是共享端点?

当你的流量繁重且可预测时,当你需要隔离容量时,或者当共享速率限制干扰生产时。请参阅专用节点。

RPC 知识库

相关 RPC 内容

区块链基础设施Bittensor

Bittensor 矿工设置:从钱包到注册 UID

设置 Bittensor 矿工意味着准备一个 coldkey/hotkey 钱包,为其充值 TAO,在子网上注册 UID,然后针对可靠的 Finney RPC 端点运行子网的矿工进程。RPC 层至关重要,因为注册、质押检查和元图同步都依赖于一致的链访问。 本指南将引导您完成实际设置路径、容易让人困惑...

测试网 RPCSolana

Solana Devnet:开发者测试与构建完整指南

# Solana Devnet:开发者测试与构建完整指南 Solana Devnet 是一个公共测试网络,专为开发者构建、部署和调试 Solana 程序而设计,无需使用真实的 SOL。它紧密模拟主网行为,但使用无货币价值的测试代币。本指南涵盖您入门所需的一切:连接 Devnet、获取测试 SOL、选...

RPC 提供商选择

Dwellir 与其他 RPC 提供商:应比较什么?

Dwellir 是一个多链 RPC 基础设施提供商,宣称可访问超过 150 个区块链网络。开发者在比较 API 提供商或为 Ethereum、Polkadot、Base 等链寻找可靠的 HTTPS 和 WebSocket 端点时,通常会搜索到它。本页面可帮助你根据真实生产需求评估 Dwellir 的...

RPC 提供商选择

Dedicated vs Shared Node Access: A Practical Comparison for Web3 Developers

Dedicated node access gives you an exclusive blockchain node with guaranteed resources and clear rate limits. Shared node access pools multiple users ...

RPC 提供商选择Solana

哪些 Solana RPC 提供商还提供高级功能?

Solana RPC 提供商之间的差异,更多体现在基础 JSON-RPC 端点之上叠加的高级能力,而非端点本身:归档历史、WebSocket 订阅、优先费用与交易落地支持、专用节点容量以及可观测性。本文列出了你会遇到的提供商类别,并解释了哪些高级功能对交易机器人、索引器、钱包和分析管道至关重要。它还...

Ethereum RPCEthereum

对于Web3应用,最佳的以太坊RPC API是什么?

最佳的以太坊RPC API为Web3应用提供可靠的主网和测试网访问、可预测的延迟、明确的请求限制、必要时支持归档或追踪,以及面向生产流量的专用基础设施升级路径。 以太坊应用通常需要的不仅仅是免费的公共端点。钱包、DeFi工具、NFT产品、分析平台和索引器在上线前应比较RPC提供商的正常运行时间、方法...

永远不用担心基础设施

OnFinality 消除了 DevOps 的繁重工作,让您能够更聪明、更快地构建。

开始