BNB RPC 列表：你的应用应该连接哪些端点？

BNB RPC 列表只是一个起点，而不是决策。你选择的端点决定了你的速率限制、是否可以查询历史状态、WebSocket 订阅是否保持打开，以及有多少工程时间花在重试上而不是产品工作上。

本页为你提供 BNB Smart Chain 主网和测试网的具体连接详情，然后介绍如何在公共端点、托管 RPC API 和专用节点之间进行选择。如果你已经知道自己想要托管或专用的 BNB 端点，请从 BNB Chain RPC 开始。

在复制 URL 之前选择你的端点类型

大多数搜索 BNB RPC 列表的开发者都在试图解决以下四种情况之一。将你的情况与下表匹配，然后直接转到该部分。

如果你属于第一行，下面的公共端点就足够了。如果你属于第二到第四行，本页的其余部分将解释在你做出承诺之前需要验证什么。

BNB Smart Chain 连接设置

这些是你的钱包、SDK 或基础设施配置所需的值。链 ID 不匹配是“交易失败”报告中最常见的原因，这些报告最终被证明是网络配置问题而非合约问题。

主网通过 OnFinality 支持 HTTP 和 WebSocket 传输。测试网仅支持 HTTP，如果你正在构建基于订阅的功能并首先针对测试网进行测试，这一点很重要。

钱包网络配置条目如下所示：

{
  "chainId": "0x38",
  "chainName": "BNB Smart Chain Mainnet",
  "nativeCurrency": { "name": "BNB", "symbol": "BNB", "decimals": 18 },
  "rpcUrls": ["https://bnb.api.onfinality.io/public"],
  "blockExplorerUrls": ["https://bscscan.com"]
}

注意 0x38 是十六进制的 56。如果十六进制和十进制值与您指向的端点不一致，钱包将拒绝连接。

公共端点、托管 RPC 和专用节点

BNB RPC 列表通常将三种截然不同的产品混在一个标题下。它们不可互换，权衡是运营层面的，而非纯粹技术层面的。

公共端点是共享的、未经身份验证的且方便的。它们适用于开发、钱包设置和低容量读取。它们不适合作为生产应用背后的唯一端点，因为你无法控制在任何时刻获得多少共享容量。

托管 RPC API 为你提供一个经过身份验证的端点，具有定义的方法支持、归档访问选项和支持路径。这是 dApp、机器人和后端服务的常见生产选择，这些服务需要可预测的行为而无需运行基础设施。OnFinality 的 RPC API 服务 属于这一类，BNB Chain 与其他 支持的 RPC 网络 一起可用。

专用节点为你提供不与其他客户共享的容量。当你的工作负载突发性强以至于共享限制无法吸收时，当你需要一致的 WebSocket 行为时，或者当你想要一条用于交易提交的私有路径时，这一点很重要。有关如何配置，请参阅 专用节点。

在承诺使用端点之前需要验证什么

复制 URL 只需几秒钟。验证它需要几分钟，但可以节省数天。针对你正在考虑的任何 BNB 端点（包括我们的）运行此列表。

• 方法覆盖。 确认端点支持你实际调用的方法。eth_call、eth_getLogs、eth_getTransactionReceipt 和 eth_blockNumber 是基本要求。Trace 和 debug 方法并非普遍可用。
• 归档深度。 如果你查询旧区块的状态，则需要归档访问权限。非归档节点对历史查询返回错误或空结果。
• eth_getLogs 范围限制。 大区块范围上的日志查询是 BNB Chain 上最常见的超时来源。询问每次请求支持的范围。
• WebSocket 行为。 如果你订阅 newHeads 或 logs，请确认端点保持连接打开以及如何处理空闲超时。
• 故障转移方案。 单个端点就是单点故障。了解它降级时会发生什么。
• 速率限制和突发行为。 了解持续限制以及是否吸收短时突发。

你现在可以运行的请求示例

从基本的健康检查开始。这确认端点可达并返回当前区块高度。

curl -s https://bnb.api.onfinality.io/public \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}'

成功的响应返回一个十六进制区块号。如果你得到的是 JSON-RPC 错误对象，则端点可达但拒绝了请求，这通常指向方法或参数问题而非连接问题。

对于应用程序代码，viem 是一个常见选择：

import { createPublicClient, http } from 'viem';
import { bsc } from 'viem/chains';

const client = createPublicClient({
  chain: bsc,
  transport: http('https://bnb.api.onfinality.io/public')
});

const block = await client.getBlockNumber();
console.log('BNB Chain head:', block);

对于主网上通过 WebSocket 的日志订阅：

import WebSocket from 'ws';

const ws = new WebSocket('wss://bnb.api.onfinality.io/public/ws');

ws.on('open', () => {
  ws.send(JSON.stringify({
    jsonrpc: '2.0',
    id: 1,
    method: 'eth_subscribe',
    params: ['newHeads']
  }));
});

ws.on('message', (data) => console.log(JSON.parse(data.toString())));

如果你的 WebSocket 连接反复断开，这是一个信号，表明应该考虑专用容量而不是重试逻辑。

故障模式及其通常含义

大多数 BNB RPC 问题都属于少数几类。症状告诉你该往哪里看。

与 nonce 相关的错误在 BNB Chain 上非常常见，值得单独处理。如果你反复看到 nonce too low 或 nonce is already consumed 错误，问题通常是交易管理而非端点本身。

在生产环境中运行 BNB Chain

一旦你超越单个端点，运营问题就会改变。你不再问“哪个 URL 有效”，而是问“当这个 URL 无效时会发生什么”。

一个实用的设置使用主托管端点，辅以用于故障转移的辅助端点，以及监控错误率而不仅仅是可用性的监控。一个检查区块高度进展的简单探针比 ping 检查能捕获更多真实事件：

#!/usr/bin/env bash
HEAD=$(curl -s https://bnb.api.onfinality.io/public \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}' \
  | grep -o '"result":"[^"]*"')
echo "BNB head: $HEAD"

如果头部停止前进，即使端点仍然返回 HTTP 200，它也已经降级。跟踪这一点，你就能在用户之前发现问题。

对于不想自己拥有这些的团队，OnFinality 为 BNB Chain 提供托管 RPC 和专用节点选项。容量和计划详情在 RPC 定价 页面上，网络特定详情在 BNB Chain RPC 上。

关键要点

• BNB Smart Chain 主网使用链 ID 56，测试网使用链 ID 97。搞错这一点会在任何合约调用运行之前破坏钱包连接。
• BNB RPC 列表混合了公共、托管和专用端点。它们解决不同的问题，不可互换。
• 公共端点适用于开发和钱包设置。生产应用需要定义的方法支持、相关的归档访问以及故障转移计划。
• eth_getLogs 范围限制和 WebSocket 空闲超时是 BNB Chain 上最常见的两个运营意外。
• 监控区块高度进展，而不仅仅是 HTTP 状态。一个可达但已停止同步的端点仍然是故障。
• 如果你的工作负载是突发性的或延迟敏感的，请评估 专用节点，而不是试图通过重试来吸收限制。

常见问题

什么是 BNB Smart Chain RPC 端点？ OnFinality 的公共主网端点是 https://bnb.api.onfinality.io/public，主网支持 WebSocket。测试网使用 https://bnb-testnet.api.onfinality.io/public。对于生产工作负载，托管或专用端点通常是更好的选择。

BNB Chain 的链 ID 是什么？ 主网是 56（0x38），测试网是 97（0x61）。钱包和 SDK 需要为你连接的网络使用正确的值。

我可以在生产环境中使用公共 BNB RPC 端点吗？ 可以，但共享容量意味着你的吞吐量取决于任何给定时刻的其他用户。一旦流量变得可预测，大多数生产团队会转向托管 RPC API 或专用节点。

为什么 eth_getLogs 在 BNB Chain 上超时？ BNB Chain 出块速度快，因此一个宽泛的区块范围可能包含大量日志。将查询拆分为更小的范围，并使用具有适当限制的端点，可以解决大多数此类超时。

我需要为 BNB Chain 使用归档节点吗？ 仅当你查询旧区块的历史状态或日志时才需要。标准节点提供最近状态；归档访问是一项单独的能力，在依赖它之前应确认。

如何在 BNB RPC 端点之间进行故障转移？ 在客户端配置主端点和辅助端点，并在重复错误或区块高度停滞时触发故障转移，而不是在单个请求失败时。监控区块进展比仅检查 HTTP 状态更可靠。