Alchemy BNB Smart Chain RPC：如何评估和配置 BSC 端点

如果你正在搜索 Alchemy BNB Smart Chain RPC 端点，你很可能同时需要两样东西：让钱包或应用能够连接的准确 BSC 网络参数，以及判断托管 RPC API 还是专用节点才是你流量的长期归宿的方法。本页涵盖这两方面。它为你提供 BNB Smart Chain 主网和测试网设置、一个可用的请求示例，以及从快速测试迈向生产环境时重要的评估标准。

BNB Smart Chain（BSC）是一条 EVM 兼容链，因此任何通过 HTTP 或 WebSocket 提供标准 JSON-RPC 的端点都能与你已在使用的工具配合：ethers、viem、web3.js、Hardhat、Foundry 以及大多数钱包的网络对话框。提供商名称的重要性不如端点在你真实工作负载下的表现，这正是本页其余部分帮助你评估的内容。

链设置一览

当你将 BNB Smart Chain 添加到钱包、Hardhat 配置或后端客户端时，请使用这些值。链 ID 是最常导致连接失败的字段，因此请先确认它。

OnFinality 为两个网络都提供公共端点，你可以在 BNB Smart Chain RPC 页面 和 BNB Chain 测试网 RPC 页面 查看完整的网络详情。公共端点适用于原型开发和低流量读取。对于持续流量、归档查询或 WebSocket 订阅，托管方案或专用节点通常是更好的选择。

何时共享端点足够，何时不够

在确定提供商之前，请将端点类型与工作负载相匹配。同一个 BSC 端点，对于黑客松演示来说完美无缺，但对于扫描多年日志的索引器来说可能成为瓶颈。

• 原型开发和钱包测试： 公共或共享端点即可。你需要的是快速设置和正确的链设置，而不是容量保证。
• 生产 dApp 的读写： 具有明确请求预算和故障转移的托管 RPC API 是实用的默认选择。你无需运营节点即可获得可预测的访问。
• 繁重的 eth_getLogs、归档读取或 trace 调用： 这些是会给共享基础设施带来压力的工作负载。请规划归档支持并提高限制，或迁移到专用节点。
• 对延迟敏感的交易或机器人： 共享端点会引入可变延迟。专用节点为你提供隔离的资源和稳定的连接。

如果你不确定自己属于哪一类，请从托管端点开始并对其进行监测。在决定是否升级之前，在真实负载下测量错误率和延迟。提供商选择指南 更深入地探讨了这一决策。

连接到 BNB Smart Chain

确认端点和链 ID 的一个快速方法是单次 JSON-RPC 调用。下面的示例使用 OnFinality 公共 BSC 端点。

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

正确的响应会以十六进制返回链 ID：

{"jsonrpc":"2.0","id":1,"result":"0x38"}

0x38 十进制为 56，确认你位于 BNB Smart Chain 主网。如果你得到不同的值，说明你指向了错误的网络。

在 JavaScript 中，使用 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 chainId = await client.getChainId()
const block = await client.getBlockNumber()
console.log({ chainId, block })

对于钱包，请添加自定义网络，链 ID 为 56，符号为 BNB，并使用上面的 RPC URL。对于测试网工作，请使用链 ID 97、符号 tBNB 和测试网端点。测试网 BNB 可从公共水龙头获取；测试网端点不提供资金。

BSC RPC 提供商之间应比较什么

提供商选择是在控制力、成本和运维投入之间的权衡。下表按工作负载而非营销宣传来构建比较。OnFinality 排在首位，因为它是本网站详细记录的选项，但这些列适用于你评估的任何提供商。

有两个问题可以区分严肃的提供商和单薄的提供商。第一，提供商是否支持你实际调用的方法——宽区块范围的 eth_getLogs、debug_traceTransaction，或历史区块的归档状态？第二，当节点故障时会发生什么：是否有自动故障转移，还是你的应用会一直看到错误直到你介入？在迁移之前请先问这两个问题。

迁移检查点

如果你要从另一个 BSC 端点迁移到新提供商，请将其视为受控变更，而不是简单替换 URL。

1. 清点你的方法。 列出你的应用调用的每个 JSON-RPC 方法，包括任何 debug 或 trace 方法。确认目标方案支持每一个。
2. 检查归档需求。 如果你查询历史状态或宽日志范围，请在切换前确认归档可用性。
3. 在预发布环境测试。 将预发布环境指向新端点并运行集成测试，包括错误路径。
4. 添加故障转移。 配置一个辅助端点，这样单个提供商中断不会导致你的应用宕机。
5. 切换后监控。 至少跟踪一个完整流量周期的错误率、延迟百分位数和速率限制响应。

在新端点在你的真实负载下证明稳定之前，请保留旧端点的配置。回滚应该是一次配置更改，而不是重新部署。

常见故障模式及如何调试

大多数 BSC RPC 问题都归入少数几类。下表将症状映射到可能的原因。

一个简单的监控探针可以帮助你尽早发现这些问题。按计划轮询 eth_blockNumber，如果它停止推进或错误率飙升就发出警报。

# 最小健康探针：确认节点正在推进
curl -s -X POST https://bnb.api.onfinality.io/public \
  -H "Content-Type: application/json" \
  --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'

请从与你的应用相同的区域运行此命令，这样你测量的延迟才能反映用户体验到的延迟。

BSC 的自建与购买

运行你自己的 BNB Smart Chain 节点让你拥有完全控制权，但这也意味着要配置能够跟上 BSC 吞吐量的硬件、管理磁盘增长、应用客户端升级，以及处理同步和重组事件。对许多团队来说，这种运维负担并不是他们想要构建的产品。

托管 RPC API 消除了大部分负担：你获得一个端点，提供商负责节点运营、升级和可用性。专用节点介于两者之间——你获得隔离的资源和可预测的性能，而无需自己管理底层基础设施。OnFinality 两者都提供，你可以在 RPC 定价页面 比较方案，或阅读关于 专用节点 的内容。

如果你的工作负载是突发性的或处于早期阶段，请从托管开始并逐步扩展。如果你有稳定的高吞吐量或严格的隔离要求，专用节点通常是更经济且可预测的选择。

关键要点

• BNB Smart Chain 主网使用链 ID 56；测试网使用链 ID 97。连接失败时请先确认链 ID。
• 公共端点适合原型开发；生产流量受益于具有故障转移的托管 RPC API。
• 归档支持、eth_getLogs 限制和 WebSocket 行为是最常决定提供商是否合适的字段。
• 将提供商迁移视为受控变更：清点方法、在预发布环境测试、添加故障转移，并在切换后监控。
• OnFinality 提供托管的 BSC 端点和专用节点；查看 支持的 RPC 网络 和 RPC 定价，将方案与你的工作负载相匹配。

常见问题

Alchemy 的 BNB Smart Chain RPC 与其他 BSC 端点相同吗？ 任何为链 ID 56 提供标准 JSON-RPC 的端点都能与 EVM 工具配合使用。提供商之间的差异体现在方法支持、归档访问、速率限制和故障转移行为上，而不是基本请求格式。

BNB Smart Chain 使用什么链 ID？ 主网是 56（0x38）。测试网是 97（0x61）。使用错误的链 ID 是钱包连接失败最常见的原因。

BSC 需要归档节点吗？ 仅当你查询历史状态或宽日志范围时才需要。标准的近期区块读写可在常规全节点上运行。在依赖归档之前请确认其可用性。

我可以在 BNB Smart Chain 上使用 WebSocket 吗？ 可以。BSC 支持针对事件和新区块的 WebSocket 订阅。如果你在生产中使用它们，请添加带退避的重连逻辑，因为空闲连接可能会被断开。

如何将我的应用从一个 BSC RPC 提供商迁移到另一个？ 在配置中更改端点 URL，保留一个辅助端点用于故障转移，并先在预发布环境运行集成测试。由于链 ID 保持不变，无需更改合约或钱包。

在哪里可以查看 OnFinality 支持哪些网络？ 支持的 RPC 网络 页面列出了当前网络，BNB Smart Chain RPC 页面 有具体的端点和链详情。