Solana RPC 端点常见问题

有关计费、Free 方案、付款以及 401 或 429 错误的问题，请参阅如何开始。

有关距离、速度和区域的问题，请参阅延迟与区域。

问：什么是 Solana RPC 端点，如何用 ERPC 获取一个？

Solana RPC 端点是您的应用、交易机器人、钱包或分析系统用来向 Solana 发送 JSON-RPC 请求并接收链上数据的 URL。使用 ERPC，您可以获得一个托管的 Solana 端点，它通过同一个全球代理网络支持 HTTP 和 WebSocket 访问。

首先，在 ERPC Web Dashboard 中创建或打开您的 ERPC 账户，复制您的 API key，并将其添加到端点 URL 的 api-key 参数中：

endpoint

https://edge.erpc.global?api-key=<YOUR_API_KEY>

https://edge.erpc.global?api-key=<YOUR_API_KEY>

WebSocket 订阅也使用相同的 API key 格式：

endpoint

wss://edge.erpc.global?api-key=<YOUR_API_KEY>

wss://edge.erpc.global?api-key=<YOUR_API_KEY>

问：我可以使用 WebSocket 吗？

是的，支持 WebSocket。它通过同一端点运行，允许您高效接收实时数据更新。

问：你们的节点位于哪些区域？

我们目前在以下区域运营节点：

法兰克福（FRA）
阿姆斯特丹（AMS）
伦敦（LON）
纽约（NY）
东京（TY）
新加坡（SGP）

ERPC 的 RPC 端点由 Cloudflare 提供支持，利用全球超过 300 个边缘服务器的网络。请求自动通过最近的 Cloudflare 边缘位置路由，然后转发到最优的 ERPC 节点，确保最短的网络路径，并从世界任何地方提供一致的低延迟。

这种架构消除了地理距离或复杂路由的影响，提供始终优化的 Solana 节点连接，具有最大的稳定性和性能。

ERPC Web Dashboard：ERPC Web Dashboard

问：为什么看不到较早的 Solana 区块或交易，或者为什么会看到 -32011？

除 getTransactionsForAddress 外，不带 history=true 的请求由每个节点保存的近期范围响应，因此较早的区块或交易可能会返回错误 This request needs history access. Add history=true to the endpoint URL.（错误码 -32011）、null 或空结果，具体取决于方法。要请求它们，请在 HTTP 请求的 https://edge.erpc.global URL 中加入 history=true。

在 URL 中发送 API key：

endpoint

https://edge.erpc.global?api-key=<YOUR_API_KEY>&history=true

https://edge.erpc.global?api-key=<YOUR_API_KEY>&history=true

或者在 header Authorization: Bearer <YOUR_API_KEY> 中发送，并在 URL 中保留 history=true：

endpoint

https://edge.erpc.global?history=true

https://edge.erpc.global?history=true

查找较早的区块或交易可能比普通请求耗时长得多，某些情况下会达到数秒。History Access 是一个独立的选项，它把这类查找与普通请求分开，从而让普通请求保持快速。除 getTransactionsForAddress 的 "full" 模式外，每个由 History Access 响应的调用比该方法的常规价格多消耗 640 个代币。

免费额度（包括 Free 方案的额度）对 History Access 设有上限。Free 方案限制为每 10 秒一个 History Access 请求。

不带 history=true 时，transactionDetails 设为 "full" 的 getTransactionsForAddress 会返回同样的 -32011 错误，无论数据新旧；价格见 ERPC 文档。

ERPC 文档：RPC

问：我的 Shreds / getBlock 输出突然乱了，或者返回 -32015，发生了什么变化？

Solana Transaction v1（SIMD-0385）已于 2026 年 9 月 15 日在 Solana 主网上线，对应 epoch 1035。v1 交易的 wire 布局以版本前缀字节 0x81 开头，签名位于消息之后，并且不再有 legacy 的长度前缀。

如果您自行解码 ShredStream 或 UDP Forwarding 的 entry，低于 4.2 版本的 bincode 或 solana-entry 解码器会把这个 0x81 字节误读为签名数量，表现为 EOF 错误、compact-length 溢出，或 "invalid message version" 错误。使用 4.2 之前的 crate 反序列化原始交易的 Geyser gRPC 用户也会遇到同样的问题。以 maxSupportedTransactionVersion: 0 调用 getBlock 和 getTransaction 时，RPC 会返回 -32015 Transaction version (1) is not supported by the requesting client；getTransactionsForAddress 在 full 模式下会对每一条受影响的记录报告同样的错误。如果您已经在读取 ERPC 解析后的 JSON 响应并设置了 version 1，则不受影响。

在 options 对象中把 maxSupportedTransactionVersion 设为 1，也就是 getBlock 和 getTransaction 的第二个参数，以及 getTransactionsForAddress 的 options：

json

{
  "maxSupportedTransactionVersion": 1
}

{
  "maxSupportedTransactionVersion": 1
}

将 Solana Stream SDK 升级到 2.0.0：crates.io 上的 Rust solana-stream-sdk，或 npm 上的 @validators-dao/solana-stream-sdk 和 @validators-dao/solana-shreds-client。@validators-dao/solana-entry-decoder 需单独升级到 2.5.0。1.4.0 和 entry-decoder 2.4.0 不支持 v1。自行编写的 Rust 解码器应迁移到 solana-entry 4.2.x。

问：Unlimited Endpoint 支持哪些方法？

Unlimited Endpoints 专为低延迟标准 Solana RPC 调用设计。支持的方法为：

getSlot
getBlockHeight
getLatestBlockhash
getBalance
getAccountInfo
getMultipleAccounts
getTransaction
sendTransaction
simulateTransaction
getSignatureStatuses
getRecentPrioritizationFees
getHealth
getVersion
getEpochInfo
getBlock

其他方法请使用 https://edge.erpc.global?api-key=<YOUR_API_KEY>。

问：我的专用节点交易成功率低

交易成功率和速度受到 QoS（服务质量）机制的显著影响。我们为专用节点提供 QoS。详情请参阅以下页面或通过 ERPC Web Dashboard 联系我们。

问：如何实现尽可能低的延迟？

最佳的低延迟设置是将专用 RPC 节点与我们的裸金属服务器结合使用。两者共享同一网络，可实现约 0.1ms ping 的私有零距离通信。

如需了解更多详情，请通过 ERPC Web Dashboard 联系我们。

ERPC Web Dashboard