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。即時頁面顯示的是每 5 分鐘更新一次的滾動式 24 小時檢視，因此今天的數字會與這份快照不同。
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 節點會保留、而全節點會修剪掉的完整帳戶狀態歷史，不過有些供應商將其放在付費方案中。我們的每個方案都提供，包括 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 方案每月包含 3000 萬運算單位，讓你在付出任何一分錢之前，就能用自己的實際方法測試我們。
資料來源：定價、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 是以請求單位（request units，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 是採用標準 JSON-RPC 端點格式與每日額度配額的 Ethereum 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 vs. 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）、八種受測方法全數最快，且沒有任何失敗請求。
對 DeFi 協定或交易機器人而言，最好的 Ethereum RPC 供應商是哪一家？
根據其公開基準測試，答案是 Alchemy：它的全球 Ethereum P95 延遲最低，且沒有任何失敗請求，而 Dedicated Clusters 可以部署在最接近你交易伺服器的地區。較快的讀取速度並不會加快交易被納入區塊的速度，因此請另行測試你的交易路徑。
哪一家 Ethereum RPC 供應商的正常運行時間最好？
Alchemy 以 99.99% 的正常運行時間運作，即時歷史紀錄可在其狀態頁面查看；在其 24 小時公開基準測試中，所有方法、所有地區都沒有任何失敗的 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 基準測試中速度最快的供應商。
哪一家 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 開發者產品與工具，並提供資源、社群與卓越的支援。