How to Fix an Invalid JSON RPC Response from a Node

18 October 2026

The "invalid JSON RPC response" error means your client received data from an nodes/rpc-endpoint-basics/">RPC endpoint that it could not parse as a properly formed JSON-RPC message. The fix is usually on the endpoint side: the node is misconfigured, overloaded, or returning something that is not a valid RPC response. You cannot fix this by changing your request alone.

What causes this error

An RPC endpoint is supposed to return a JSON object with either a result or an error field. When the response is not valid JSON - for example, an HTML error page, a raw text string, or a malformed JSON payload - your client throws this error.

Common causes include:

• The endpoint is behind a proxy or load balancer that returns its own error page (e.g., a 502 Bad Gateway rendered as HTML).
• The node software is crashing or restarting and sends incomplete data.
• The endpoint returns a redirect without following it, sending a non-JSON response.
• The node is using a response format incompatible with your client’s expectations, such as a raw TCP stream instead of HTTP with JSON.
• The endpoint URL is wrong - for instance, pointing to a WebSocket port (ws://) when you need HTTP, or to a missing path.

Step-by-Step Diagnosis

1. Check the Raw Response

Use a tool like curl to see exactly what the server sends. Run this from your terminal:

curl -X POST <YOUR_RPC_URL> \
 -H "Content-Type: application/json" \
 -d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'

If the response starts with anything other than {"jsonrpc":"2.0", you have found the problem. Common non-JSON responses include:

• <html> tags (proxy error page)
• 502 Bad Gateway (upstream node down)
• 301 Moved Permanently (redirect, no body)
• An empty response or connection reset

2. Verify the Endpoint URL

Double-check the URL format. Ethereum RPC endpoints typically end in a path like /v3/your-api-key, /rpc, or just /. Confirm:

• You are using HTTP or HTTPS, not WebSocket (ws:// or wss://).
• The port is correct (8545 for local Geth, 8544 for Erigon by default, or a custom port for a hosted provider).
• No trailing slashes or extra characters are in the URL.

3. Test a Different Client or Library

If you are using a library like ethers.js or web3.js, it may add headers or transform requests in ways that the node does not expect. Try a raw curl command as shown above. If curl works but your application does not, the issue is in your client code - likely a malformed request payload or incorrect content type.

4. Check Node Status (If You Run Your Own Node)

If you operate your own node, inspect it directly:

• Is the node fully synced? A node still syncing may return error responses.
• Does the node’s HTTP server log show the request? Look for 500-level responses or connection drops.
• Is the node overloaded? High CPU or memory usage can cause it to drop requests or send truncated responses.
• Is the node configured to listen on the correct interface and port? Check the --http and --http.addr flags.

5. Try an Alternative Endpoint

Switch to a different RPC provider or your own node’s other endpoint. If the error disappears, the original endpoint is the problem. This is the fastest test.

Common Fixes

Fix: use a different endpoint

If you are using a public or free RPC endpoint, switch to a more reliable provider or to your own node. Public endpoints often have rate limits, load balancers that return HTML errors, or inconsistent uptime.

Fix: configure your node correctly

If you run your own node, ensure these settings in your execution client:

• Enable the HTTP server: --http flag.
• Set the allowed origins: --http.corsdomain "*" for testing, or specific domains.
• Set the allowed APIs: --http.api eth,net,web3 (add others as needed).
• Confirm the port is open and not blocked by a firewall.

For Geth, the HTTP server listens on localhost:8545 by default. For Erigon, the default is localhost:8544.

Fix: handle redirects in your client

Some RPC providers redirect traffic. Ensure your HTTP client follows redirects (the default in most libraries) and does not treat a 301/302 as a final response.

Fix: Use a Proxy or Failover

If you must rely on a specific endpoint, set up a proxy that sanitizes responses or use a multi-provider failover system (already covered on this site). The proxy can catch non-JSON responses and return a proper error instead of crashing your application.

When the error persists

If you have verified the endpoint URL, tested with a raw HTTP request, and checked your node’s configuration, but the error continues, the issue is likely upstream. Consider:

• The node software has a bug that causes it to emit malformed responses under certain conditions. Check the node’s issue tracker.
• The network connection between you and the endpoint is intercepting or modifying traffic (e.g., a corporate proxy injecting headers).
• The endpoint is intentionally returning non-JSON data for maintenance or rate-limiting purposes (some providers return plain text errors for abuse detection).

In all cases, the most reliable fix is to stop using the failing endpoint and switch to one that returns valid JSON-RPC responses. There is no way to force a misconfigured or broken node to produce correct output.

Back to rpc & nodes