2026 年最佳 Ethereum RPC 服务商
作者 Alchemy
每个 Ethereum 应用的速度，都取决于它最慢的那次 RPC 调用。余额迟迟加载不出来。报价晚了一个区块才到。回填始终追不上链。用户感受不到平均值。他们感受到的是你最慢的那百分之几的请求。
我们正是在这段慢尾部上拉开了差距。在截至 2026 年 10 月 28 日 18:15 UTC 的 24 小时基准测试中，Alchemy 是最快的 Ethereum RPC 服务商：
- 全球平均延迟最低：7.77 ms。
- 全球 P95 最低（即 95% 的请求快于该时间）：16.47 ms，而 QuickNode 为 122.67 ms。
- 在我们测试的全部八种 Ethereum 方法上均最快，从余额读取到跨 1,000 个区块的
eth_getLogs（用于获取事件日志的调用）。 - 失败请求为零，覆盖所有方法和所有地区。
- 在我们测试的全部四个地区，P95 均低于 20 ms。
Ethereum RPC 服务商替你运行 Ethereum 节点，并提供一个支持 JSON-RPC 的端点。JSON-RPC 是钱包、应用以及 ethers.js 和 viem 等库用来读取链上数据和发送交易的接口。
本指南由我们发布，而 Alchemy 是其中比较的五家服务商之一。服务商按字母顺序排列，所有限制、功能和 SLA 细节均来自各服务商截至 2026 年 10 月 28 日的官方页面。
哪家 Ethereum RPC 服务商的延迟最低？
在我们最近 24 小时的基准测试中，Alchemy 的 Ethereum 平均延迟和 P95 延迟最低，且 100% 的请求均成功返回。
全球，Ethereum，2026-10-27 18:15 UTC 至 2026-10-28 18:15 UTC：
来源：alchemy.com/benchmarks，机器可读数据见 alchemy.com/benchmarks/data.md。实时页面显示滚动 24 小时视图，每 5 分钟更新一次，因此今天的数字会与此快照不同。
Alchemy 的尾部延迟保持紧凑。其 P95 约为 P50（响应时间中位数）的 2.9 倍，因此即使是最慢的请求也与典型响应相差不远。QuickNode 的 P95 约为其 P50 的 14.7 倍，比 Alchemy 高 106.20 ms。
可以把 P95 想象成结账排队。平均等待时间看起来可能还不错，但每 20 位顾客中就有一位要等得久得多，而转身离开的正是这位顾客。一个在每个区块都读取状态的交易机器人每小时会发起数千次调用，因此即使只有一小部分响应偏慢，也会变成错失的报价。
哪家 Ethereum RPC 服务商在各方法上最快？
在我们测试的全部八种方法上，Alchemy 的全球平均延迟均最低。每种调用类型在服务商基础设施中经过的路径不同，而真实应用很少只由一种调用构成，因此我们的基准测试分别为每种方法计时：
日志查询最能说明问题。从 1 个区块的范围到 1,000 个区块的范围，我们的 eth_getLogs 延迟几乎没有变化，始终在 7.50 到 8.33 ms 之间。这就是回填能跟上链与落后于链之间的差别。这一差距在各地区同样存在：在 AP Southeast，Alchemy 响应 1,000 个区块日志查询的平均耗时为 7.05 ms，而 QuickNode 为 74.32 ms，dRPC 为 733.48 ms。
Alchemy 在 Ethereum 上的可靠性如何？
在该时间窗口内，Alchemy 的 Ethereum 失败请求为零，覆盖所有方法和所有地区。快速的响应只有在真正返回时才有用。Goldsky 和 dRPC 都出现了失败，dRPC 的失败主要集中在 eth_getLogs 上。
对于钱包或支付流程而言，读取失败比读取缓慢更糟，因为用户会看到加载图标或错误。错误、限流以及超过八秒的请求都计为失败，且不进行重试，因此服务商无法通过丢弃最慢的请求来获得好看的平均值。
Alchemy 在各地区的表现如何？
Alchemy 在 US East 和 AP Southeast 的平均延迟最低，并且在我们测试的全部四个地区 P95 均低于 20 ms。
关键在于一致性。在全部四个地区，我们的平均延迟保持在 6.47 到 10.84 ms 之间，而在我们测量的其他服务商中，没有一家能在所有地区都将 P95 控制在 20 ms 以下。如果你的流量集中在某一个地区，请在实时基准测试中查看该地区的数据。
Alchemy 如何实现最低延迟？
通过 Cortex，即支撑每一次 Alchemy 请求的智能基础设施引擎。它在四个方面的作用体现在基准测试中：
- 路由：“全局编排和 AI 子系统持续评估实时网络状况，将每个请求路由到最快的健康节点。”在我们测试的每个地区，我们的平均延迟都低于 11 ms。
- 硬件：专门构建的裸金属硬件、暗光纤连接和弹性扩展，让吞吐量始终领先于需求。
- 可用性：多地区基础设施和自主故障切换。从外部看，零失败请求就是这样实现的。
- 日志与一致性：不限范围的
getLogs可在单个请求中扫描整条链以查找你的事件，并且从 1 个区块到 1,000 个区块，我们的日志延迟始终保持平稳。区块级完美一致性意味着在你的用户面前，各节点对链的状态永远不会出现分歧。
同一套基础设施服务于一些规模最大的链上应用：Polymarket 和 Robinhood 使用我们的 RPC 和 Data APIs，World App 使用我们的 RPC APIs 和 Rollups。
什么时候应该选择 Alchemy？
当你的应用需要在最关键的调用上，在任何地方、任何时候都保持快速时，请选择 Alchemy。它最适合以下工作负载：
- DeFi 与交易：尾部延迟决定报价能否按时到达，而在我们测量的所有服务商中，我们的全球 P95 最低。
- 索引器与回填：我们在测试的每个
eth_getLogs范围上都最快，付费套餐没有区块范围上限，并且所有套餐都提供完整的 archive 数据（链的每一个历史状态）。 - 钱包与消费级应用：最快的余额和交易回执读取，加上用于实时更新的 WebSockets 和 Webhooks。
- 产品发布与快速增长：具备弹性扩展能力的裸金属硬件，与 Polymarket 所用的基础设施相同。
- 企业团队：SOC 2 Type II、99.99% 正常运行时间、签署的 SLA（合同约定的正常运行时间承诺），以及部署在你所在地区的单租户 Dedicated Clusters。
同一个 API 覆盖 100+ 条链，因此你为 Ethereum 选择的端点，也能覆盖你接下来要部署的 L2。
Ethereum RPC 服务商一览
以下是最常决定候选名单的细节。在做出决定之前，还应对照你的峰值流量检查各服务商的速率限制、eth_getLogs 上限，以及 WebSocket 订阅是否按事件计费。大多数服务商只在企业合同中提供 SLA（服务等级协议）。来源列在下文各服务商的小节中。
这里的每家服务商都提供 Ethereum archive 数据，即 archive 节点保留、而全节点会裁剪掉的完整账户状态历史，不过有些服务商将其放在付费套餐中。我们的所有套餐都提供 archive 数据，包括 Free。
各 Ethereum RPC 服务商对比
Alchemy
Alchemy Node RPC 是 Alchemy 的 Ethereum RPC 服务，在我们的基准测试中是最快的服务商：全球平均延迟和 P95 延迟最低，失败请求为零。付费套餐允许不限区块范围的 eth_getLogs，响应上限为 150 MB；所有套餐都提供 archive 数据；可逐步重放交易的 Debug and Trace APIs 在 Pay as You Go 和 Enterprise 套餐中提供。我们支持 100+ 条链，正常运行时间为 99.99%，实时历史记录见我们的状态页面。Free 套餐每月包含 30M 算力单位，因此你可以在付一分钱之前，先用自己的真实方法对我们进行测试。
来源：定价、eth_getLogs 限制、Cortex、Dedicated Clusters、信任中心。
Ankr
Ankr 是一家采用统一定价的多链 RPC 服务商：每个 EVM 方法都消耗相同的 200 API 额度，从预付的 Premium 余额中扣除。它不提供自动充值，余额一旦低于 -$5，Ankr 就会暂停账户。所有套餐都提供 archive 数据，Premium 允许 10,000 个区块的 eth_getLogs 范围，每次响应最多 200,000 条日志。WebSockets、trace 和 debug 需要 Premium，并且只有 Enterprise 提供 SLA（99.9%，按月）。Ankr 未纳入我们的延迟基准测试。
Chainstack
Chainstack 是一家按请求单位（RU）计费的多链节点服务商，所有套餐都提供 WebSockets，Pro 套餐起提供 Dedicated Nodes。大多数调用消耗 1 RU，trace 和 archive 深度的调用消耗 2 RU，其中包括任何起始区块落后链头 127 个或更多区块的 eth_getLogs 查询。Archive 数据、debug 和 trace 从 Growth 套餐起提供。付费套餐将 eth_getLogs 上限设为 10,000 个区块，免费套餐为 100 个。Chainstack 未纳入我们的延迟基准测试。
Infura
Infura 是一家 Ethereum RPC 服务商，采用标准的 JSON-RPC 端点格式和每日额度配额，因此切换到 Infura 或从 Infura 切换出去，主要只需更改 URL。Ethereum 主网上自动启用 archive 数据，并支持 trace、debug 和 WebSockets。由于配额每日重置，一次流量突增可能提前耗尽当天的额度，而 WebSocket 连接会在达到限额时关闭。eth_getLogs 最多返回 10,000 条结果，且必须在 10 秒内完成。Infura 未纳入我们的延迟基准测试。
来源：定价、额度消耗、eth_getLogs、archive 数据、状态。
QuickNode
QuickNode 是一家按 API 额度计费的多链 RPC 服务商，标准 Ethereum 调用每次 20 额度，trace 和 debug 为 40，所有套餐都提供 archive 数据和 WebSockets。其 Enterprise 层级增加了 99.99% 正常运行时间 SLA 和 Dedicated Clusters。在我们的基准测试中，差距在于其尾部延迟：全球 P95 为 122.67 ms，而 Alchemy 为 16.47 ms，主要由其 US West 和 AP Southeast 的结果导致；其 eth_getLogs 约为 48 ms。付费套餐将 eth_getLogs 上限设为 10,000 个区块。如需一对一比较，请参见 Alchemy 与 QuickNode 对比。
来源：定价、API 额度、eth_getLogs、企业版、安全、状态。
如何用自己的流量测试服务商？
从用户能感知到的调用开始：钱包的余额读取和交易回执、索引器的真实 eth_getLogs 范围，以及交易应用的报价和状态读取。从你的服务器和用户所在的地区运行每项测试。
该脚本对两个端点各计时 30 次 eth_blockNumber 调用，并分别输出 P50、P95 和错误数。将 PRIMARY_RPC_URL 和 SECONDARY_RPC_URL 设置为你要比较的端点：
# Time 30 eth_blockNumber calls against each endpoint, then print P50 and P95.
# Each URL includes that provider's API key, read from the environment.
# Requires curl and jq. Only HTTP 2xx responses with a valid JSON-RPC result count as successes.
n=0
for url in "$PRIMARY_RPC_URL" "$SECONDARY_RPC_URL"; do
n=$((n + 1))
for i in $(seq 30); do
response=$(curl -s -w "\n%{http_code} %{time_total}" -X POST "$url" \
-H "Content-Type: application/json" \
--data '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}')
status=$(printf '%s\n' "$response" | tail -n 1)
code=${status%% *}
if [ "$code" -ge 200 ] && [ "$code" -lt 300 ] &&
printf '%s\n' "$response" | sed '$d' | jq -e 'has("result") and (has("error") | not)' >/dev/null 2>&1; then
echo "ok ${status#* }"
else
echo "error"
fi
done | sort -k2 -n | awk -v n="$n" '
$1 == "ok" { t[++ok] = $2 * 1000 }
$1 == "error" { err++ }
END {
if (!ok) { printf "Endpoint %d: no successful responses, %d errors\n", n, err; exit }
printf "Endpoint %d: P50 %.0f ms, P95 %.0f ms, %d errors\n", n, t[int(ok * 0.5 + 0.5)], t[int(ok * 0.95 + 0.5)], err
}'
done
换成你的产品所依赖的方法，并在你的应用运行的每个地区执行。错误意味着调用失败，而不是返回得慢。
如何在不停机的情况下切换服务商？
同时运行两个端点，分阶段迁移流量，并将旧端点保留为回退选项，直到新端点证明其可靠。本指南中的每家服务商都支持标准 Ethereum JSON-RPC，因此大多数应用只需更改 URL 和 API key。我们的零停机迁移指南介绍了如何梳理方法清单、影子测试和切换。
这个 viem 客户端使用 fallback transport。它将请求发送给第一个服务商，如果第一个失败，则转到第二个：
import { createPublicClient, fallback, http } from 'viem'
import { mainnet } from 'viem/chains'
// Each URL includes that provider's API key, read from the environment.
const client = createPublicClient({
chain: mainnet,
transport: fallback([
http(process.env.PRIMARY_RPC_URL),
http(process.env.SECONDARY_RPC_URL),
]),
})
const blockNumber = await client.getBlockNumber()
console.log(`Latest block: ${blockNumber}`)
我们的测量方法
延迟、P50、P95 和成功率来自我们的公开基准测试：
- 数据覆盖 2026-10-27 18:15 UTC 至 2026-10-28 18:15 UTC。我们引用一个固定的时间窗口，以便每个数字都能对照同一份数据核实，而实时页面会显示当前的结果。
- 每 10 秒，每家服务商会从每个 AWS 地区（US East、US West、EU Central 和 AP Southeast）收到每种方法各一个请求，所有服务商的请求在同一时刻发出，使用标准付费账户和预热的连接，不进行重试。
- 如果请求在八秒内返回 HTTP 2xx 状态、有效 JSON 且没有 JSON-RPC 错误，则视为成功。延迟仅基于成功响应计算。
- Ethereum 覆盖 Alchemy、Goldsky、QuickNode 和 dRPC。Ankr、Chainstack 和 Infura 未纳入基准测试。
该基准测试不测量完整的应用流程、写入操作、WebSocket 推送，也不测量你自己的流量构成。完整的测试方法见我们如何对 RPC 性能进行基准测试。服务商的限制、功能、合规和 SLA 均来自各服务商的官方页面，读取时间为 2026 年 10 月 28 日。我们没有在服务商小节中纳入 dRPC 和 Dwellir，因为我们无法核实与它们相关的每一个数字。如需了解更多链，请参见我们的区块链节点服务商指南。
想看看你自己的 Ethereum 调用表现如何吗？免费开始在 Alchemy 上构建，在实时基准测试上比较各服务商，或就企业需求联系我们的团队。
常见问题
最好的 Ethereum RPC 服务商是哪家？
在截至 2026 年 10 月 28 日的 24 小时公开基准测试中，Alchemy 是表现最好的 Ethereum RPC 服务商：全球平均延迟最低（7.77 ms），全球 P95 最低（16.47 ms），在所测的全部八种方法上均最快，且失败请求为零。
哪家 Ethereum RPC 服务商最适合 DeFi 协议或交易机器人？
根据其公开基准测试，是 Alchemy：它的全球 Ethereum P95 延迟最低，失败请求为零，并且 Dedicated Clusters 可以部署在离你的交易服务器最近的地区。更快的读取并不会加快交易被打包进区块的速度，因此请单独测试你的交易路径。
哪家 Ethereum RPC 服务商的正常运行时间最好？
Alchemy 的正常运行时间为 99.99%，其状态页面提供实时历史记录；在其 24 小时公开基准测试中，Alchemy 的 Ethereum 失败请求为零，覆盖所有方法和所有地区。Enterprise 套餐另提供签署的 SLA。
哪些 Ethereum RPC 服务商的安全性足以满足企业使用？
Alchemy 持有 SOC 2 Type II，并提供单租户 Dedicated Clusters。QuickNode 声明持有 SOC 1 Type 2、SOC 2 Type 2 和 ISO/IEC 27001，Chainstack 声明持有 SOC 2 Type II 和 ISO/IEC 27001，Ankr 的基础设施运营方持有 SOC 2 Type II。签约前请索取最新报告。
企业级 RPC 服务商应提供什么样的 SLA？
应有附带服务补偿额度的书面正常运行时间承诺，通常仅在企业合同中提供。Alchemy 在 Enterprise 套餐中提供签署的 SLA，正常运行时间为 99.99%。QuickNode 承诺 99.99% 的正常运行时间，Ankr 承诺 99.9%（按月），Chainstack 承诺 99.9%（按季度），均在 Enterprise 套餐中提供。
达到免费套餐的速率限制后，应该切换到哪家服务商？
切换到一个能以充足余量满足你峰值请求速率的付费套餐。Alchemy Pay as You Go 提供约每秒 300 次请求，无需承诺用量，而 Free 套餐约为每秒 15 次；更多容量可按档购买。
Infura 的最佳替代方案是什么？
Alchemy 可直接替代 Infura。两者都使用标准 JSON-RPC，因此通常只需更改 URL 和 API key，而且在 Alchemy 的 Ethereum 基准测试中，Alchemy 是最快的服务商。
哪家 Ethereum RPC 服务商的 eth_getLogs 限制最宽松？
在 Alchemy、Ankr、Chainstack、Infura 和 QuickNode 中，Alchemy 公开记录的 eth_getLogs 区块范围最宽：在 Ethereum 付费套餐上不设限制，响应上限为 150 MB。其他服务商将查询上限设为 10,000 个区块或 10,000 条结果。在所测的每个范围上，Alchemy 的全球 eth_getLogs 延迟也最低。
哪家 Ethereum RPC 服务商最适合钱包？
根据其公开基准测试，Alchemy 最适合钱包。它在 Ethereum 上的全球余额读取（6.88 ms）和交易回执查询（7.89 ms）最快。WebSockets 会在新区块产生时立即推送，Webhooks 以至少一次（at-least-once）投递的方式推送链上事件。
我需要专属节点，还是共享服务商就够了？
对大多数生产应用来说，共享服务商就够了。如果你需要单租户隔离、自定义 tracer、特定地区，或在高请求速率下的保证容量，就需要专属基础设施。Alchemy Dedicated Clusters 在同一个 API 上覆盖这些场景。
选择 RPC 服务商之前，我该如何进行基准测试？
从你的用户和服务器所在的地区，向每家服务商发送相同的请求，并使用相同的超时和连接设置。在你的应用所依赖的方法上（例如 eth_getLogs 和交易回执查询）比较平均延迟、P95 和成功率。
哪家 Ethereum RPC 服务商与 ethers.js 或 viem 配合最好？
Alchemy、Ankr、Chainstack、Infura 和 QuickNode 都可以与 ethers.js 和 viem 配合使用，因为这两个库都使用标准 Ethereum JSON-RPC。在 ethers.js 中将服务商的 URL 传给 JsonRpcProvider，在 viem 中则传给 http transport。
相关概览
构建区块链应用
Alchemy 将最强大的 Web3 开发者产品和工具与资源、社区及专业支持结合在一起。