在信任一个端点之前，区块链 RPC 测试器实际应该检查什么？

快速回答：RPC 测试器应该告诉你什么

区块链 RPC 测试器回答四个问题：这个端点是否存活？它是否在我期望的链上？它是否支持我调用的方法？当我重复调用时，它的行为是否一致？如果工具只回答第一个问题，那它是连通性检查器，而不是 RPC 测试器。

最快的手动测试是使用 curl 发送 JSON-RPC POST 请求。如果 eth_chainId 和 eth_blockNumber 返回有效结果，则端点可达且使用 JSON-RPC 通信。这是起跑线，不是终点线。

• 链身份：eth_chainId 必须与你打算使用的网络匹配。
• 方法支持：你的应用调用的方法必须返回结果，而不是方法未找到错误。
• 响应结构：结果必须符合该方法的 JSON-RPC 规范。
• 错误行为：无效请求应返回结构化错误，而不是 HTML 或超时。
• 稳定性：重复和并发调用不应意外降级。

决策指南：快速检查、托管 RPC 还是专用节点？

使用测试结果来决定你需要哪种端点。通过基本检查的公共端点可能适用于原型、脚本或本地测试的钱包。但对于有真实用户的应用来说，这很少足够，因为共享端点会施加速率限制，并且可能不暴露归档或 trace 方法。

如果你的测试通过但生产流量导致失败，那么端点不是你通过更努力测试就能解决的问题——你需要不同的服务级别。托管 RPC API 为你提供带有文档化限制的密钥端点。当你的工作负载需要归档深度、高请求量或可预测行为时，专用节点为你提供隔离资源。

使用 curl 运行首次检查

从两个调用开始：eth_chainId 确认网络，eth_blockNumber 确认端点跟随链头。两者都很廉价，并且适用于所有 EVM 兼容端点。

将占位符 URL 替换为你正在测试的端点。如果你还没有，请浏览支持的网络以找到你的链的端点。

• curl -s -X POST <YOUR_RPC_URL> -H 'Content-Type: application/json' -d '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}'
• curl -s -X POST <YOUR_RPC_URL> -H 'Content-Type: application/json' -d '{"jsonrpc":"2.0","id":2,"method":"eth_blockNumber","params":[]}'
• curl -s -X POST <YOUR_RPC_URL> -H 'Content-Type: application/json' -d '{"jsonrpc":"2.0","id":3,"method":"eth_getBalance","params":["0x0000000000000000000000000000000000000000","latest"]}'

测试你的应用实际调用的方法

通用 RPC 测试器检查常见方法。你的应用有特定的方法配置文件，而这个配置文件才是关键。如果你的应用读取日志，请使用真实的区块范围测试 eth_getLogs。如果它在历史区块读取合约状态，请使用过去的区块号测试 eth_call。如果它依赖跟踪，请测试 debug_traceTransaction 或 trace_block，并预期许多端点会拒绝它们。

下表将常见工作负载类型映射到值得测试的方法以及你试图捕获的故障。

用小脚本探测稳定性

单次成功调用证明端点工作一次。一个发送重复和并发请求的短脚本可以显示它是否经得起考验。下面的示例使用 fetch 并测量一批调用的延迟和错误率。从与你的应用程序相同的区域和网络条件运行它，因为来自不同大陆的笔记本电脑的结果不具有代表性。

将数字视为相对信号，而非绝对基准。在相同条件下比较端点之间的差异，而不是与固定目标比较。

• 发送至少 50 次顺序调用，并记录成功率和延迟分布。
• 发送小的并发突发，检查错误是结构化的 JSON-RPC 错误还是超时。
• 在不同时间段重复运行，观察行为是否变化。
• 记录失败的原始响应体，以便区分速率限制和方法错误。

阅读错误响应，而不仅仅是成功响应

许多端点问题隐藏在错误处理中。行为良好的端点在请求无效或方法不支持时返回带有代码和消息的 JSON-RPC 错误对象。配置错误的端点或其前面的代理可能返回 HTML、空响应体或通用 HTTP 错误，这会以令人困惑的方式破坏客户端库。

故意测试错误请求：未知方法、格式错误的参数以及请求不存在的区块。这些响应的结构告诉你当生产环境出现问题时，你可以多大程度信任该端点。

当通过的测试还不够时

端点可以通过本页的每一项检查，但在生产环境中仍然失败，因为测试是在低容量从一个位置运行的。常见的差距是仅在实际流量下出现的速率限制、仅在用户请求旧数据时才重要的归档深度，以及仅在 UI 订阅事件时才重要的 WebSocket 支持。

如果你的测试揭示了这些差距，下一步是服务级别而不是另一个测试。OnFinality 在支持的网络提供 RPC API 访问，并在你需要隔离资源时提供专用节点基础设施。查看 RPC 定价以比较计划，并检查支持的网络列表以确认你的链可用。

• 速率限制：检查文档化的限制，并测试类似峰值流量的突发。
• 归档深度：如果你的应用查询旧区块，确认历史状态可用。
• WebSocket：如果你的应用需要实时事件，确认订阅工作。
• 故障转移：决定当主端点返回错误时客户端做什么。

常见问题