摘要
RPC 节点是运行区块链客户端软件的服务器，负责应答来自你应用的远程过程调用（RPC）请求。你的钱包、dApp、后端索引器或交易机器人向 RPC 端点发送 JSON-RPC 请求，节点则读取链上状态、模拟调用或代表你广播已签名交易。
大多数团队不需要自己运行 RPC 节点。真正的决策在于如何获取节点：免费公共端点、托管 RPC API，还是你控制的专用节点。每种选项在成本、运维投入、隐私、方法支持以及可承受的负载方面各有取舍。
本页解释 RPC 节点的工作原理、健康节点与脆弱节点的区别，以及如何为你的工作负载选择合适的方案。当你需要托管端点或专用节点时，OnFinality 在支持的网络中提供 RPC API 访问和专用节点基础设施。
关键要点
- RPC 节点是应答 JSON-RPC 请求的区块链客户端，使应用能够读取状态并提交交易。
- 公共端点适合原型开发，但通常缺乏生产应用所需的方法覆盖、隐私和容量。
- 托管 RPC API 免去节点运维；当共享端点不够用时，专用节点提供隔离容量和控制权。
- 方法支持至关重要：归档数据、trace/debug 调用、eth_getLogs 范围以及 WebSocket 订阅是常见的缺口。
- 故障转移、监控和按方法限制应在发布前规划，而不是在事故发生后。
- OnFinality 在支持的网络中提供 RPC API 访问和专用节点基础设施。
RPC 节点的实际作用
区块链节点是运行客户端软件并与网络保持同步的计算机。当该节点暴露 RPC 接口时，其他程序可以向它提问：这个账户余额是多少、这个区块发生了什么、这笔交易会成功吗，以及请广播这笔已签名交易。
客户端-服务器模型很简单。你的应用是客户端，通过 HTTP 或 WebSocket 向端点发送 JSON-RPC 请求。节点针对其本地链状态副本执行方法，并返回结果或错误。节点不需要是验证者，只需同步且可达。
在选择基础设施时，这一区别很重要。你购买的不是共识参与权，而是可靠的读取访问、交易传播以及应用所依赖的特定 RPC 方法。
- 读取：余额、区块、收据、日志、合约状态
- 写入：广播已签名交易
- 模拟：估算 gas 和试运行调用
- 订阅：用于新区块、日志和待处理交易的 WebSocket 流
快速建议：哪种 RPC 节点方案适合你的工作负载
将此作为初步参考。正确答案取决于你发送的流量、调用的方法以及产品能承受的停机时间。
- 如果你仍在原型开发，公共或免费层级端点通常足够。
- 如果你要面向真实用户发布，请从托管 RPC API 开始并添加故障转移。
- 如果你的工作负载繁重或依赖特定方法，请在达到生产限制之前评估专用节点。
| 标准 | 检查内容 | 为什么重要 |
|---|---|---|
| 公共端点 | 原型或低流量脚本，无敏感数据，无严格延迟要求 | 启动成本低且快速，但共享容量和有限的方法覆盖使其在生产环境中存在风险 |
| 托管 RPC API | 需要可预测访问而无需运维节点的生产 dApp、钱包、索引器和后端 | 提供商处理同步、升级和扩展；你专注于应用并围绕文档化限制进行规划 |
| 专用节点 | 高请求量、大量 eth_getLogs 或 trace 使用、严格隔离或自定义客户端配置 | 隔离容量和控制权，但你需要承担更多容量规划和运维责任 |
| 自托管节点 | 拥有基础设施专业知识且有合规或主权要求的团队 | 最大控制权，但同步时间、磁盘增长、监控和升级成为你的工作 |
RPC 节点在生产环境中的故障点
大多数 RPC 事故并不神秘。它们属于少数几种模式，当流量增长或工作负载依赖共享端点视为昂贵的方法时就会出现。
最常见的是方法覆盖。一个能快速应答 eth_call 的节点可能仍然拒绝 debug_traceTransaction、将 eth_getLogs 限制在狭窄的区块范围，或拒绝旧状态的归档查询。如果你的索引器或分析任务依赖这些方法，廉价端点可能看起来健康，直到第一次回填。
其次是容量。共享端点是池化的，因此你应用的突发流量会与其他所有人竞争。速率限制、并发上限和负载大小限制是正常的。解决方法通常是了解你的请求组合、尽可能缓存，并将繁重或延迟敏感的流量转移到专用方案。
| 标准 | 检查内容 | 为什么重要 |
|---|---|---|
| 症状 | 可能原因 | 下一步 |
| 429 或速率限制错误 | 请求突发超过计划限制 | 添加退避、缓存读取或升级容量 |
| eth_getLogs 范围错误 | 提供商限制每次查询的区块范围 | 分块查询或使用支持更宽日志范围的节点 |
| 缺少归档数据 | 已修剪节点无历史状态 | 使用支持归档的端点进行回填 |
| Trace/debug 方法被拒绝 | 共享层级未启用该方法 | 迁移到暴露该方法的提供商或专用节点 |
| 响应陈旧或滞后 | 节点落后于链头 | 添加健康检查并故障转移到第二个端点 |
最小 JSON-RPC 请求流程
与 RPC 节点的每次交互都遵循相同的形式：方法名、参数和 id。下面的示例使用占位端点；请将其替换为提供商的端点或你所针对链的网络页面中的端点。
对于应用代码，ethers 或 viem 等库会封装这些调用，但了解原始请求有助于调试故障。返回 200 但带有错误对象的响应仍然是失败，错误代码会告诉你问题出在你的请求还是节点。
- HTTP 适用于请求-响应式读取和交易提交。
- WebSocket 更适合订阅和高频更新。
- 始终记录 JSON-RPC 错误代码和消息，而不仅仅是 HTTP 状态。
公共、托管和专用节点比较
获取 RPC 访问的三种常见方式主要区别在于谁运行节点以及容量如何共享。OnFinality 属于托管和专用类别：为希望无需节点运维即可获得端点的团队提供 RPC API 访问，为需要隔离的工作负载提供专用节点基础设施。
在比较提供商时，向每个提供商提出相同的问题：启用了哪些方法、请求和负载限制是什么、是否有归档数据、是否支持 WebSocket 订阅，以及故障转移如何工作。
| 标准 | 检查内容 | 为什么重要 |
|---|---|---|
| OnFinality | 跨支持网络的托管 RPC API 和专用节点 | 选择托管以快速上市，需要隔离容量和方法控制时选择专用 |
| 公共端点 | 免费、共享、通常有速率限制 | 适合测试和简单读取，不适合生产流量 |
| 通用 RPC 提供商 | 因层级和网络而异 | 按计划检查方法支持、限制和归档访问，而不是假设对等 |
| 自托管 | 你运行和监控客户端 | 完全控制但需要持续运维成本和专业知识 |
生产就绪检查清单
在将真实流量指向任何 RPC 节点之前，确认基本事项。此列表故意简短；每一项都对应一种在发布后才发现代价高昂的故障模式。
- 来自不同提供商或区域的两个端点，并配置自动故障转移。
- 健康检查，将节点的最新区块与网络头部进行比较。
- 为你的工作负载记录方法列表，包括归档、trace 和日志查询。
- 对重复读取（如代币元数据和静态合约状态）进行缓存。
- 对瞬时错误进行带退避的重试，并对持续错误率发出警报。
- 为延迟敏感的用户流量和繁重批处理任务使用单独的端点。
- 制定 WebSocket 重连和丢失订阅事件的计划。
后续步骤
如果你仍在评估，请从托管 RPC API 开始并测量你的真实请求组合。这些数据会告诉你是否需要归档访问、更大的日志范围或专用节点。
如果你已经知道工作负载繁重或依赖特定方法，请比较专用节点选项，并在迁移前确认所需的方法和容量。你可以查看 RPC 定价 和 支持的 RPC 网络 以了解适合你技术栈的方案。
常见问题
RPC 节点和验证者节点一样吗？
不一样。验证者参与共识。RPC 节点为应用提供请求服务。有些运营者同时运行两种角色，但你可以在不验证的情况下运行 RPC 节点。
我需要专用 RPC 节点吗？
只有当共享端点无法满足你的方法、容量或隔离需求时才需要。许多生产应用在带有故障转移和缓存的托管 RPC API 上运行良好。
为什么某些 RPC 方法在共享端点上失败？
trace、debug 和宽范围 eth_getLogs 查询等方法开销较大。提供商通常会在共享层级上限制它们以保护容量。在围绕它们构建之前，请检查方法支持。
RPC 节点和 RPC 端点有什么区别？
节点是运行客户端软件的服务器。端点是你的应用用来访问该节点的 URL，通常通过 HTTP 或 WebSocket。
如何测试 RPC 节点是否健康？
将其最新区块与网络头部进行比较，发送已知的读取请求，并在真实负载下检查错误率。在生产依赖它之前，添加自动化健康检查。
Ethereum
Solana
Polygon
Base
Arbitrum
BNB链
Polkadot
Optimism
