Summary
If you searched for "rpc test" and landed on chlorine strips or Windows RPC port 135, you are in the wrong place. In Web3, an RPC test is the process of checking whether a blockchain node endpoint actually works for your application: it responds to the JSON-RPC methods you need, returns correct data, handles your request volume, and fails in predictable ways. A quick eth_blockNumber call is a smoke test, not a production test.
This page gives you a practical testing workflow you can run against any EVM endpoint, including OnFinality's RPC API and dedicated nodes. It covers what to test, how to interpret failures, and when a shared endpoint is enough versus when you need dedicated infrastructure.
Use it as a checklist before you ship: test connectivity, method support, archive depth, WebSocket behavior, and error handling. Then decide whether to keep the endpoint, add a fallback, or move to a dedicated node.
Key Takeaways
- An RPC test checks more than connectivity: method support, data correctness, archive depth, WebSocket behavior, and error handling all matter.
- Start with a minimal JSON-RPC call such as eth_blockNumber, then expand to the methods your app actually uses.
- Test archive and trace methods separately; many public endpoints answer basic calls but reject historical state or debug calls.
- WebSocket subscriptions need their own test because HTTP success does not guarantee push delivery.
- Record failure modes (timeouts, rate-limit responses, malformed JSON) so you can design retries and fallbacks.
- If your tests show repeated limits or missing methods, evaluate a dedicated node or a managed RPC provider like OnFinality.
What an RPC test actually needs to prove
A blockchain RPC test answers one question: can this endpoint serve my application's real traffic without surprising me? That is broader than a ping. A node can accept TCP connections and still return errors for the methods you depend on, or return stale data because it is behind the chain head.
The practical test set has five layers: transport reachability, JSON-RPC correctness, method coverage, capacity behavior, and failure behavior. Each layer catches a different class of problem, and skipping a layer is how endpoints pass staging and fail in production.
- Transport: can you reach the endpoint over HTTPS or WSS from your deployment environment?
- Correctness: does a known method return a plausible, current result?
- Coverage: do the specific methods your app calls succeed, including archive and trace calls?
- Capacity: what happens under your expected request rate and burst pattern?
- Failure behavior: what does the endpoint return when it is rate-limited, overloaded, or missing data?
Quick recommendation: smoke test first, then targeted tests
If you only have a minute, run a single JSON-RPC call and confirm you get a valid response with a recent block number. That tells you the endpoint is alive and speaking JSON-RPC. It does not tell you it is production-ready.
If you are choosing an endpoint for an app, run the smoke test, then test the exact methods your app calls, then test under load. If any layer fails, stop and fix that layer before moving on. Testing everything at once makes failures hard to attribute.
| Criterion | What to check | Why it matters |
|---|---|---|
| Smoke test | eth_blockNumber returns a hex block number that advances over time | Confirms the endpoint is reachable and syncing, not just accepting connections |
| Method coverage | Every method your app calls returns a valid result or a clear error | Shared endpoints often restrict archive, trace, or debug methods |
| Data correctness | Compare a known block or transaction against a second source | Catches stale or inconsistent nodes before they corrupt app state |
| Capacity behavior | Response times and error rates at your expected request rate | Shows whether the endpoint can absorb your normal and burst traffic |
| Failure behavior | Status codes and error bodies when limits are hit | Determines how your retry and fallback logic must be written |
Run a minimal JSON-RPC test
Start with curl so you can see the raw response. A valid response has a JSON-RPC version, an id that matches your request, and either a result or an error object. If you get HTML, a redirect, or a non-JSON body, the endpoint is not speaking JSON-RPC at that URL.
Replace the placeholder URL with the endpoint from your provider or your own node. Do not assume a URL works because it looks correct; always confirm with a real call.
curl -s -X POST <YOUR_RPC_URL> -H 'Content-Type: application/json' -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}'- Run it twice a few seconds apart and confirm the block number increases.
- Check the HTTP status code as well as the JSON body; some failures return 200 with an error object.
Test the methods your app actually calls
Every application has a method profile. A wallet reads balances and nonces. An indexer reads logs and blocks. A trading bot may need pending transactions and WebSocket subscriptions. Test that profile directly rather than testing a generic list.
Archive and trace methods deserve separate attention. Many endpoints answer current-state calls but reject historical state or debug calls. If your app needs historical balances or transaction traces, test those explicitly and record the exact error you get when they are unavailable.
| Criterion | What to check | Why it matters |
|---|---|---|
| eth_getBalance | Current balance for a known address | Basic wallet and dashboard read path |
| eth_getLogs | Logs for a bounded block range | Indexers and event-driven apps depend on range limits and result size |
| eth_getBlockByNumber | A historical block by number | Confirms archive depth if you request old blocks |
| debug_traceTransaction | Trace for a known transaction | Often disabled on shared endpoints; needed for debugging and analytics |
| eth_subscribe | WebSocket subscription delivers new heads | HTTP success does not prove push delivery works |
Test WebSocket behavior separately
WebSocket endpoints fail differently from HTTP endpoints. A connection can open and then deliver nothing, or drop after a period of inactivity. Test that you receive subscription messages, that reconnects work, and that your client handles dropped connections without losing state.
Use a small script or a WebSocket client to subscribe to new heads and log timestamps. If messages stop arriving while the chain is still producing blocks, you have a delivery problem, not a chain problem.
- Open a WSS connection and send an eth_subscribe request for newHeads.
- Log each message with a timestamp and confirm messages arrive at a steady rate.
- Kill the connection and confirm your client reconnects and resubscribes.
- Leave the connection idle for a while and check whether the server closes it.
Read failure responses before you need them
The most useful part of an RPC test is the failure response. When an endpoint is rate-limited or overloaded, it may return HTTP 429, a JSON-RPC error object, or a timeout. Each requires different client behavior. Capture the exact response so you can write retry logic that does not make the problem worse.
Also test what happens when you send a malformed request or an unsupported method. A well-behaved endpoint returns a structured JSON-RPC error; a misconfigured proxy may return HTML or an empty body.
| Criterion | What to check | Why it matters |
|---|---|---|
| HTTP 429 or rate-limit error | Retry-After header or error message | Tells you whether to back off and for how long |
| JSON-RPC error object | Error code and message for unsupported methods | Distinguishes method restrictions from transport failures |
| Timeout or connection reset | Whether the endpoint recovers on retry | Indicates capacity or network instability rather than a code bug |
| Non-JSON response | HTML, redirect, or empty body | Usually a wrong URL, proxy issue, or auth problem |
Decide whether to keep, fall back, or move to dedicated infrastructure
After testing, you have three options: keep the endpoint as-is, keep it with a fallback, or move to dedicated infrastructure. The right choice depends on which layers failed and how often.
If the endpoint passes smoke and method tests but shows rate-limit responses under your expected load, a fallback or a higher-tier plan may be enough. If it rejects archive or trace methods you need, or if you cannot get predictable capacity, a dedicated node is the cleaner path. OnFinality offers both managed RPC API endpoints and dedicated nodes, so you can test the same workflow against either.
- Keep as-is when all layers pass at your expected load and method profile.
- Add a fallback when the primary endpoint is healthy but you want resilience against regional or provider incidents.
- Move to dedicated when method restrictions, capacity limits, or isolation requirements block your app.
- Re-run the test after any plan or provider change; endpoint behavior can differ by tier.
Frequently Asked Questions
What is an RPC test in Web3?
An RPC test checks whether a blockchain node endpoint can serve your application's JSON-RPC requests correctly. It covers connectivity, method support, data correctness, capacity behavior, and failure responses, not just whether the URL responds.
Is eth_blockNumber enough to test an endpoint?
No. eth_blockNumber is a useful smoke test, but it does not prove that archive calls, trace methods, log queries, or WebSocket subscriptions work. Test the methods your app actually uses.
Why does my endpoint work in curl but fail in my app?
Common causes include missing headers, wrong HTTP method, client-side timeouts, WebSocket versus HTTP mismatch, or the app calling methods the endpoint restricts. Compare the raw request your app sends with the curl request that worked.
How do I test an archive RPC endpoint?
Request a historical block or balance by block number that is older than the node's pruning window. If the endpoint returns an error or missing data, it is not serving archive state for that range.
When should I use a dedicated node instead of a shared RPC endpoint?
Consider a dedicated node when you need methods that shared plans restrict, predictable capacity for sustained or bursty traffic, or isolation from other users. Test your workload against both options before deciding.
Ethereum
Solana
Polygon
Base
Arbitrum
BNB Chain
Polkadot
Optimism
