If you're a Web3 developer, you've definitely run into these situations:
- Transaction stuck pending for ages, only to find the RPC node is down
-
eth_calltiming out repeatedly, but switching to a different node returns instantly - Infura free tier exhausted, and finding a replacement feels like searching for a needle in a haystack
- Chainlist says a node is "online," but every request you send throws errors
RPC node quality directly impacts your DApp's user experience and development velocity. So how do you actually find a fast and reliable RPC? This guide walks you through it — from first principles to practical tooling.
Disclosure: I use RPC Hub in my daily workflow and contribute to the project. The first half of this post is framework-agnostic — the principles apply regardless of which tool you use to evaluate RPC nodes.
1. Why Are Good RPCs So Hard to Find?
Let's start with a fundamental insight: RPC node quality is not static.
A node that's fast today may not be fast tomorrow. A node that works well for users in the US might be slow for users in Asia. And a node that returns eth_blockNumber just fine might time out on eth_getLogs.
Worse still, most RPC directories — including Chainlist — have a fundamental flaw in how they detect node health:
Browser-side detection → CORS restrictions → massive false "offline" reports
When you fetch an RPC URL from the browser, if the provider hasn't configured CORS headers, the request gets blocked by the browser — even though the node itself is running perfectly. This is why Chainlist often shows nodes as "offline" when they're actually fine.
Reliable detection must happen server-side.
2. Three Core Metrics for Evaluating RPC Nodes
In order of importance:
1. Latency
This is the most intuitive metric. Lower latency means faster transaction confirmations and quicker eth_call responses. Here's a rough guide:
| Latency | Experience |
|---|---|
| < 50ms | Excellent — suitable for HFT / MEV |
| 50–150ms | Good — perfectly fine for daily development |
| 150–500ms | Usable, but your DApp frontend will feel sluggish |
| > 500ms | Avoid — poor user experience |
But latency isn't everything. Some nodes have low latency but miss blocks (see below).
2. Block Height
A node could have 10ms latency, but if it's 10 blocks behind, the on-chain data you're reading is stale. This is fatal in DeFi scenarios — you might think the price hasn't changed when someone already front-ran you.
So when probing a node, you must verify all three:
- Is the node online?
- What's the latency in milliseconds?
- Is the block height caught up with the network?
3. Privacy Policy
Many free RPC nodes log your request data. That might not matter for a solo developer, but if you're:
- Running MEV or trading strategies
- Handling sensitive user data
- Operating under strict compliance requirements
Then you need to know: does this RPC provider log, analyze, or resell your request data?
3. How to Find the Best RPC — The Practical Way
Theory is great, but how do you actually do this? The old-school approach — curl each endpoint one by one — is painfully slow. You need a more efficient workflow.
Here's how to do it in one place, using RPC Hub as an example.
500+ EVM Chains Covered
Whether you're working with Ethereum, BSC, Polygon, Arbitrum, Optimism, or niche L2s/L3s, you'll find the corresponding RPC list. The data is sourced from chainlist.org's ethereum-lists/chains repository (EIP-3770 standard), with significant enhancements on top.
Server-Side Real-Time Probing
This is the key differentiator. RPC Hub probes endpoints from the server side, completely bypassing browser CORS restrictions. Each node returns three data points:
- Online status — real online/offline, no false positives
- Latency — millisecond-level precision
- Block height — verifies sync is healthy
RPC Score Comparison
A single chain often has a dozen RPC providers. RPC Hub ranks them all, giving a composite score based on latency and availability. You can see at a glance which one is fastest and which one is most stable — no manual trial and error.
Privacy Transparency
Every RPC provider is tagged with its privacy policy (tracking info), so you know exactly what data collection behavior to expect.
One-Click Add to Wallet
Found a good one? One click adds it to MetaMask — no more manually filling in Chain ID, RPC URL, Currency Symbol, and Block Explorer URL.
4. More Than Just RPC Discovery: Built-in Dev Tools
RPC Hub isn't just an RPC directory. It also packs several practical development tools:
JSON-RPC Playground
Send raw JSON-RPC requests directly in the browser, with method presets for common calls:
| Category | Methods |
|---|---|
| Network |
net_version, eth_chainId, eth_blockNumber, eth_syncing
|
| Account |
eth_getBalance, eth_getTransactionCount, eth_getCode
|
| Block |
eth_getBlockByNumber, eth_getBlockByHash
|
| Transaction |
eth_getTransactionByHash, eth_getTransactionReceipt
|
| Gas |
eth_gasPrice, eth_maxPriorityFeePerGas, eth_feeHistory, eth_estimateGas
|
Requests are proxied through the server, so there are no CORS issues. You can also export any request as a cURL command for local reproduction.
Cast Terminal
Foundry's cast is the Swiss Army knife of on-chain development, but switching to a terminal every time is a friction point. RPC Hub's Cast Terminal lets you run cast commands right in the browser — cast block-number, cast balance, cast call — with instant results.
Safety guardrails:
cast sendandcast walletare blocked to prevent accidents.
ABI Codec
Encode and decode EVM calldata, supporting all Solidity types including tuples and arrays. Invaluable for debugging contract call parameters.
Faucet Directory
A curated list of testnet faucets organized by network, so you don't have to hunt around during development.
5. RPC Hub vs. Chainlist
| Dimension | Chainlist | RPC Hub |
|---|---|---|
| Detection Method | Browser-side fetch | Server-side multi-node probing |
| CORS Limitations | Yes — many false reports | None |
| Latency Data | None | Multi-region real-time latency |
| Historical Data | None | Full time-series data |
| Provider Verification | None | Badge system |
| Alerting | None | Multi-channel notifications |
6. Summary
Back to the original question: How do Web3 developers find the fastest, most reliable RPC nodes?
- Don't just check online status — latency and block height matter just as much
- Don't trust browser-side detection alone — CORS will give you false results
- Use a tool that does it all in one place — the time you save is better spent shipping code
RPC Hub is completely free and collects zero user data — which is how I believe infrastructure tooling should be built. If you have a workflow for RPC selection that works for you, I'd love to hear about it. And if you try RPC Hub, feedback and contributions are always welcome 👉 rpchub.top
Originally published on Dev.to. Feel free to repost with attribution.
Top comments (0)