Summary
An RPC tester is any tool or script that sends JSON-RPC requests to a blockchain endpoint and reports whether the endpoint responds correctly, how consistently it responds, and whether it returns the data your application expects. Developers search for one when they have an endpoint URL in hand and need to know if it is safe to ship, or when an app is failing and they need to separate endpoint problems from application bugs.
The search results for this query mix two very different things: generic TCP/Windows RPC test clients and Web3 JSON-RPC endpoint checkers. For blockchain work, only the second category matters. A useful Web3 RPC tester checks chain identity, method support, response shape, error behavior, and stability under repeated calls — not just whether a port is open.
This page explains what to test, how to run the checks yourself with curl and JavaScript, and when a quick test is enough versus when you need a managed RPC API or a dedicated node from a provider such as OnFinality.
Key Takeaways
- A blockchain RPC tester must verify chain identity, method support, response shape, and error behavior — not just TCP connectivity.
- Start with eth_chainId and a known block lookup to confirm you are talking to the right network.
- Test the exact methods your app uses, including archive and trace calls if your workload depends on them.
- Measure behavior under repeated and concurrent requests, not a single warm call.
- Check error responses: a good endpoint returns structured JSON-RPC errors, not HTML or empty bodies.
- If an endpoint passes basic tests but fails in production, the gap is usually rate limits, archive depth, or WebSocket support.
- Managed RPC APIs and dedicated nodes from OnFinality are options when self-testing shows a public endpoint is not enough.
Quick answer: what an RPC tester should tell you
A blockchain RPC tester answers four questions: Is this endpoint alive, is it on the chain I expect, does it support the methods I call, and does it behave consistently when I call it repeatedly? If a tool only answers the first question, it is a connectivity checker, not an RPC tester.
The fastest manual test is a JSON-RPC POST with curl. If that returns a valid result for eth_chainId and eth_blockNumber, the endpoint is reachable and speaking JSON-RPC. That is the starting line, not the finish line.
- Chain identity: eth_chainId must match the network you intend to use.
- Method support: the methods your app calls must return results, not method-not-found errors.
- Response shape: results must match the JSON-RPC spec for that method.
- Error behavior: invalid requests should return structured errors, not HTML or timeouts.
- Stability: repeated and concurrent calls should not degrade unexpectedly.
Decision guide: quick check, managed RPC, or dedicated node?
Use the results of your tests to decide what kind of endpoint you need. A public endpoint that passes basic checks may be fine for a prototype, a script, or a wallet you are testing locally. It is rarely enough for an application with real users, because shared endpoints apply rate limits and may not expose archive or trace methods.
If your tests pass but production traffic causes failures, the endpoint is not the problem you should solve by testing harder — you need a different service level. A managed RPC API gives you a keyed endpoint with documented limits. A dedicated node gives you isolated resources when your workload needs archive depth, high request volume, or predictable behavior.
| Criterion | What to check | Why it matters |
|---|---|---|
| Prototype or local script | Basic chain ID and block number checks pass | A public endpoint is usually enough while you are validating logic. |
| App with real users | Rate limits, method coverage, and error handling under load | Shared endpoints can throttle or reject bursts that a production app generates. |
| Archive or trace dependency | Historical state calls and trace/debug methods return results | Many public endpoints prune old state or disable trace methods entirely. |
| High or bursty throughput | Behavior under concurrent requests and sustained load | A single warm call tells you little about how the endpoint handles traffic. |
| WebSocket subscriptions | Subscription methods connect and deliver events | HTTP-only endpoints will fail apps that rely on real-time event streams. |
Run the first checks with curl
Start with two calls: eth_chainId to confirm the network, and eth_blockNumber to confirm the endpoint is following the chain head. Both are cheap and work on every EVM-compatible endpoint.
Replace the placeholder URL with the endpoint you are testing. If you do not have one yet, browse the supported networks to find the endpoint for your chain.
curl -s -X POST <YOUR_RPC_URL> -H 'Content-Type: application/json' -d '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}'curl -s -X POST <YOUR_RPC_URL> -H 'Content-Type: application/json' -d '{"jsonrpc":"2.0","id":2,"method":"eth_blockNumber","params":[]}'curl -s -X POST <YOUR_RPC_URL> -H 'Content-Type: application/json' -d '{"jsonrpc":"2.0","id":3,"method":"eth_getBalance","params":["0x0000000000000000000000000000000000000000","latest"]}'
Test the methods your app actually calls
A generic RPC tester checks common methods. Your application has a specific method profile, and that profile is what matters. If your app reads logs, test eth_getLogs with a realistic block range. If it reads contract state at historical blocks, test eth_call with a past block number. If it relies on tracing, test debug_traceTransaction or trace_block and expect that many endpoints will reject them.
The table below maps common workload types to the methods worth testing and the failure you are trying to catch.
| Criterion | What to check | Why it matters |
|---|---|---|
| Wallet or balance display | eth_getBalance, eth_getTransactionCount, eth_call | These are the calls users hit most; failures here are immediately visible. |
| Event indexing | eth_getLogs with realistic block ranges and topic filters | Log queries are often rate-limited or capped by block range on shared endpoints. |
| Historical analytics | eth_call and eth_getStorageAt at old block numbers | Pruned endpoints return errors for state that is no longer available. |
| Transaction debugging | debug_traceTransaction, trace_block | Trace methods are frequently disabled on public and shared endpoints. |
| Real-time UI | eth_subscribe over WebSocket | HTTP-only endpoints cannot deliver subscriptions at all. |
Probe stability with a small script
A single successful call proves the endpoint works once. A short script that sends repeated and concurrent requests shows whether it holds up. The example below uses fetch and measures latency and error rate across a batch of calls. Run it from the same region and network conditions as your application, because results from a laptop on a different continent are not representative.
Treat the numbers as relative signals, not absolute benchmarks. Compare endpoints against each other under the same conditions rather than against a fixed target.
- Send at least 50 sequential calls and record success rate and latency distribution.
- Send a small concurrent burst and check whether errors are structured JSON-RPC errors or timeouts.
- Repeat the run at different times of day to see whether behavior changes.
- Log the raw response body for failures so you can distinguish rate limiting from method errors.
Read the error responses, not just the successes
Many endpoint problems hide in error handling. A well-behaved endpoint returns a JSON-RPC error object with a code and message when a request is invalid or a method is unsupported. A misconfigured endpoint or a proxy in front of it may return HTML, an empty body, or a generic HTTP error, which breaks client libraries in confusing ways.
Test deliberately bad requests: an unknown method, a malformed parameter, and a request for a block that does not exist. The shape of those responses tells you how much you can trust the endpoint when something goes wrong in production.
| Criterion | What to check | Why it matters |
|---|---|---|
| Unknown method | Structured JSON-RPC error with a method-not-found code | Confirms the endpoint speaks JSON-RPC rather than returning a proxy error page. |
| Malformed params | Invalid-params error, not a crash or timeout | Shows the endpoint validates input and fails predictably. |
| Missing block | Null result or a clear error for a block beyond the chain head | Helps you handle race conditions around the chain head correctly. |
| Rate limit response | HTTP 429 or a documented rate-limit error | Lets your client back off instead of retrying blindly. |
When a passing test is not enough
An endpoint can pass every check on this page and still fail in production, because the tests ran at low volume from one location. The usual gaps are rate limits that only appear under real traffic, archive depth that only matters when a user requests old data, and WebSocket support that only matters when a UI subscribes to events.
If your tests reveal those gaps, the next step is a service level rather than another test. OnFinality provides RPC API access across supported networks and dedicated node infrastructure when you need isolated resources. Review RPC pricing to compare plans, and check the supported networks list to confirm your chain is available.
- Rate limits: check documented limits and test a burst that resembles your peak traffic.
- Archive depth: confirm historical state is available if your app queries old blocks.
- WebSocket: confirm subscriptions work if your app needs real-time events.
- Failover: decide what your client does when the primary endpoint returns errors.
Frequently Asked Questions
What is an RPC tester?
An RPC tester is a tool or script that sends JSON-RPC requests to a blockchain endpoint and reports whether it responds correctly, which methods it supports, and how it behaves under repeated calls. For Web3 work, it should check chain identity, method support, response shape, and error behavior — not just TCP connectivity.
Can I test an RPC endpoint with curl?
Yes. A JSON-RPC POST with curl is enough to check eth_chainId, eth_blockNumber, and basic method support. Use it as a first pass, then run a small script for repeated and concurrent calls if you need to judge stability.
Why does my endpoint pass a basic test but fail in my app?
The most common reasons are rate limits under real traffic, missing archive or trace methods, and lack of WebSocket support. A basic test runs at low volume and may not call the methods your app depends on.
How do I know if an endpoint supports archive data?
Call eth_getBalance or eth_call with a block number well behind the chain head. If the endpoint returns a result, it has that state available. If it returns an error about missing state, the endpoint is pruned or limits historical queries.
Should I use a public endpoint for production?
Public endpoints are useful for testing and prototypes, but they are shared and typically rate-limited. For applications with real users, a managed RPC API or a dedicated node gives you documented limits and more predictable behavior.
Ethereum
Solana
Polygon
Base
Arbitrum
BNB Chain
Polkadot
Optimism
