Solana RPC 端点参考:URL、方法、认证、生产模式

刚做 Solana RPC 的时候,端点 URL 看上去就是个魔法字符串。其实它有结构——认证方案、查询参数、服务商之间挑选的模式——这些都影响你代码在生产里的可靠性。把这些零件搞懂了,换服务商、debug 连接问题、加冗余都更容易。

这是 Solana RPC 端点的参考:URL 结构、认证选项、最常用的方法、把"能跑"和"脆弱"的配置区分开的生产模式。

RPC 端点是什么

Solana RPC 端点就是个接受 JSON-RPC 请求的 HTTPS URL。常见格式:

https://your-provider.example/?api-key=YOUR_KEY

或者:

https://your-name.your-provider.example

形状看服务商,但协议都一样:HTTP POST 带 JSON-RPC body。

WebSocket 订阅,服务商通常会暴露一个并行的 wss:// 端点:

wss://your-provider.example/?api-key=YOUR_KEY

通常两个端点来自同一家服务商;HTTP 给读写用,WebSocket 给订阅用。

认证模式

三种常见方案:

查询参数 API key。

https://provider.example/?api-key=YOUR_KEY

设起来简单,浏览器里就能测。所有标准 SDK 都行,因为 URL 直接传给 HTTP 请求。

路径嵌入 API key。

https://provider.example/YOUR_KEY

一样的思路,URL 形状不同。大多数 SDK 两种都能处理。

Header 认证。

const connection = new Connection("https://provider.example", {
  httpHeaders: {
    "Authorization": "Bearer YOUR_TOKEN",
  },
});

更安全(key 不在 URL 里、不会那么容易记到 HTTP 服务器日志)。一些服务商提供;不是所有 SDK 都开箱处理得干净。

大多数用例,查询参数或路径嵌入就够。审计/合规要求高的话,header 这种更重要。

公共端点 vs 服务商端点

Solana 自己暴露的公共端点:

• https://api.mainnet-beta.solana.com——公共 mainnet
• https://api.devnet.solana.com——公共 devnet
• https://api.testnet.solana.com——公共 testnet

这些有限流、无 SLA、拥堵期间落后于真实网络状态。只在开发和教程里用。生产里任何东西都得通过服务商。

Mainnet 生产环境,你需要的是服务商提供的 URL。服务商跑自己的 RPC 集群,有容量、有监控、有 SWQoS 支持。代价是花钱(或者撞免费档上限),但换来的可靠性和性能差距很大。

常见 RPC 方法

最实际用得到的方法参考:

读:

// 账户状态
connection.getAccountInfo(pubkey, "confirmed");
connection.getMultipleAccountsInfo([key1, key2, key3], "confirmed");

// 余额
connection.getBalance(pubkey, "confirmed");
connection.getTokenAccountBalance(tokenAccountKey, "confirmed");

// 代币持仓
connection.getTokenAccountsByOwner(ownerKey, { programId: TOKEN_PROGRAM_ID });

// 交易历史
connection.getSignaturesForAddress(pubkey, { limit: 10 });
connection.getTransaction(signature, "confirmed");

// 网络状态
connection.getLatestBlockhash("confirmed");
connection.getSlot("confirmed");
connection.getEpochInfo("confirmed");

// 程序交互
connection.getProgramAccounts(programId, { filters: [...] });

写:

connection.sendTransaction(tx, signers, options);
connection.sendRawTransaction(serialised, options);

订阅(WebSocket):

connection.onAccountChange(pubkey, callback, "confirmed");
connection.onLogs(programId, callback, "confirmed");
connection.onSignature(signature, callback, "confirmed");

模拟:

connection.simulateTransaction(tx, signers);

完整列表看 Solana JSON-RPC 参考。上面这些覆盖了大多数应用 95% 的用法。

生产模式

生产里行得通的模式:

读写端点分开。 前面讲过,读 RPC 和写 RPC 优化目标不一样。每边用不同服务商。

const readConnection = new Connection(READ_RPC_URL, "confirmed");
const writeConnection = new Connection(WRITE_RPC_URL, "processed");

用环境变量。 别硬编码 URL:

const RPC_URL = process.env.SOLANA_RPC_URL;
if (!RPC_URL) throw new Error("SOLANA_RPC_URL 没设");

显式配超时:

const connection = new Connection(RPC_URL, {
  commitment: "confirmed",
  confirmTransactionInitialTimeout: 30_000,
  fetchMiddleware: yourFetchMiddleware,
});

处理限流: 所有生产 RPC 都限流。客户端要带指数退避重试 429 错误,别一限流就崩。

读量大的场景用连接池: 每秒数千次读,多个 Connection 实例能帮忙。

别跨用户复用签名连接: Connection 包了 HTTP 客户端。多租户应用要按用户/请求隔离连接状态,避免泄漏 token。

故障转移和冗余

高可用部署:

主备故障转移。 主 RPC 挂了备 RPC 顶上。包一层 Connection 检测错误并切换就行。

读扇出。 同一个读查询发给多个 RPC,谁先响应用谁的。简单实现;读流量翻倍。

写冗余更难。 同一笔交易发到多个 RPC,两边都成功就重复执行了。发送通常不值得搞。挑一个好的就行。

健康检查。 周期性 ping 每个 RPC 的 /health 或 getHealth。主挂了就切到健康的。

大多数团队主备加单主就够。完全多区域 active-active 在到大规模之前都过度。

常见 URL 问题

会出错的地方:

末尾斜杠。 一些 SDK 挑剔。https://provider.example 跟 https://provider.example/ 行为可能不一样。

路径组件 vs 查询参数。 确保服务商文档跟你 URL 结构对得上。

HTTP vs HTTPS。 生产永远 HTTPS。别相信只给 HTTP 端点的服务商。

WebSocket URL 派生。 一些库从 HTTP URL 自动派生 WebSocket URL。服务商 WebSocket 端点在不同路径上的话,要显式设。

API key 编码。 含特殊字符的 API key 要 URL 编码。大多数服务商发的 key 没特殊字符,但要留意。

浏览器客户端 CORS。 一些服务商不允许浏览器源请求。从浏览器调 RPC 时,验证一下 CORS 配置。

检查 RPC 健康

简单的健康检查模式:

async function isHealthy(connection) {
  try {
    const slot = await Promise.race([
      connection.getSlot("processed"),
      new Promise((_, reject) => setTimeout(() => reject(new Error("timeout")), 3000)),
    ]);
    return slot > 0;
  } catch (e) {
    return false;
  }
}

RPC 快速返回 slot 大概就在工作。更复杂的检查包括对比返回的 slot 跟参考值(检测落后)。

生产环境还可以查:

• 最近 blockhash 的新鲜度(对比 getLatestBlockhash 跟预期时间)
• 交易模拟成功(抓住坏状态)
• 订阅连接干净建立(抓住 WebSocket 问题)

这周可以做什么

给项目配 Solana RPC 的话:

1. 挑读写两边的服务商(可以同一家也可以不同)
2. URL 用环境变量,别硬编码
3. 显式配连接超时,别靠默认
4. 限流处理用指数退避
5. 监控里加 RPC 健康检查
6. 至少规划主备故障转移
7. 测 WebSocket 端点(用订阅的话)——经常是不同 URL

在生产端点上试一下 BoltTx

BoltTx 提供生产级写 RPC:

https://bolttx.io/?api-key=YOUR_API_KEY

集成:

import { Connection } from "@solana/web3.js";

const writeConnection = new Connection(
  "https://bolttx.io/?api-key=YOUR_API_KEY",
  "processed"
);

单一全球端点配内部智能路由——不用选区域、零 DevOps 负担。原生 Anti-MEV 三明治被夹保护。亚秒级确认作为设计底线。每笔签名级别的投递遥测。所有套餐都包含专属 SWQoS + 优先级连接。

免费档注册。配你自己挑的读服务商。

常见问题

生产能用公共 Solana RPC 吗? 不能。有限流、没 SLA、拥堵期落后。用服务商。

mainnet-beta 跟 mainnet 有什么区别? 同一个网络,叫法不同。"mainnet-beta"是正式名字;"mainnet"是非正式叫法。指同一条链。

用一个还是多个 RPC? 开发用一个。生产经常用两个——读一个、写一个。各自为角色优化。

怎么轮换 API key? 开新 key、更新环境、部署。周期性轮换 key 是个安全实践。

Solana RPC 端点标准化吗? JSON-RPC 方法名是标准的。URL 结构和认证方案看服务商。用标准 SDK 方法的代码跟任何合规服务商都能配合。

延伸阅读

• Solana RPC 开发者指南
• Solana sendTransaction 最佳实践
• Solana RPC 是什么
• 2026 年最佳 Solana RPC 服务商
• BoltTx 文档
• Solana JSON-RPC API 参考