Solana RPC 端點常見問題

關於計費、免費方案、付款以及 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

或者在標頭 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