How to Fix a Connection Refused Error on an RPC Endpoint

01 October 2026

A "connection refused" error on an nodes/rpc-endpoint-basics/">RPC endpoint means your wallet, dApp, or script tried to reach the RPC server, but the server actively rejected the connection attempt. This is different from a timeout (no response) or a 403/429 (permission or rate-limit block). The fix depends on whether you are using a public RPC endpoint or your own node.

What "connection refused" actually means

When your client sends a TCP handshake to the RPC endpoint's IP address and port, the server's operating system or firewall explicitly sends back a reset packet. Common causes:

• The RPC server is not running.
• The server is running but not listening on the port you specified (e.g., port 8545 instead of 8546).
• A firewall or security group blocks inbound traffic to that port.
• The endpoint URL points to a hostname that resolves to the wrong IP address.
• The server process crashed or exhausted system resources (file descriptors, memory).

Step-by-Step fixes for public RPC endpoints

If you are using a free or public RPC provider (like those found on Chainlist), the problem is almost always on their side. Your options are limited.

1. Verify the URL

Check the endpoint URL character by character. A typo in the hostname or port number will produce connection refused if the DNS resolves to a server that does not run an RPC on that port. Common mistakes:

• Using http when the server expects https (or vice versa) - though this usually gives a different error.
• Appending /v3/, /ext/bc/, or other path fragments that the server does not serve.
• Including a trailing slash that the server rejects.

Remove any custom path and try the base URL alone.

2. Confirm the Chain ID and Network

If the endpoint is correct but the server is configured for a different network (e.g., Ethereum mainnet endpoint used for Sepolia), the connection will not work. Switch to an endpoint that matches your target chain.

3. Switch to a Different Public Endpoint

Since you cannot control a public server, the fastest fix is to rotate. Most wallets and tools support multiple RPC URLs. Add a backup from a different provider. The article on multi-provider failover covers how to automate this.

4. Check for IP or Regional Blocks

Some public RPC endpoints block traffic from certain IP ranges, VPNs, or geographic regions. Try disabling your VPN or connecting from a different network. If the error persists, the provider may have banned your IP. Wait a few minutes or use a different provider.

5. Test with a Direct Tool

Use curl or a browser to test the endpoint directly. For example:

curl -X POST https://your-rpc-url.com -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'

If curl also returns "connection refused", the server is down for everyone. If curl works but your wallet does not, the issue is in how your wallet sends the request (e.g., wrong headers, payload format).

Step-by-Step fixes for your own node

If you run your own Geth, Erigon, or other client, the connection refused error means your node is not accepting connections. This is your problem to solve.

1. Is the Node Actually Running?

SSH into your server and check the process:

ps aux | grep geth

If the process is missing, start it. Check logs for crash reasons:

journalctl -u geth -n 50

Common crash causes: disk full, out of memory, corrupted database (requires resync), or invalid flags.

2. Check Which Port the Node Listens On

Your client may be configured to listen on a different port than you expect. The default for Ethereum JSON-RPC is 8545, but many users change it. Look at your node's configuration or startup flags for --http.port or --port. Also verify --http.addr - if it is set to 127.0.0.1 (localhost), the node will refuse connections from other machines.

3. Firewall and Security Groups

If the node runs on a cloud server (AWS, DigitalOcean, Linode), check the inbound firewall rules. You need to allow TCP traffic on the RPC port from your client's IP address. On the server itself, check ufw or iptables:

sudo ufw status

If the port is not open, add a rule. For a local test, you can temporarily disable the firewall, but do not leave it off.

4. Verify the RPC Module Is Enabled

By default, some clients disable the HTTP RPC interface. In Geth, you must include --http or --http.api flags. If you omitted them, the node runs but does not listen for RPC at all. Check your startup command:

geth --http --http.port 8545 --http.addr 0.0.0.0 --http.api eth,net,web3

5. Check for TLS/SSL Configuration

If you set up HTTPS for your RPC endpoint (using Nginx or Caddy as a reverse proxy), "connection refused" may indicate the proxy is not running or is misconfigured. Test the proxy's port directly and check its logs.

When connection refused is actually a good sign

A "connection refused" error is explicit. It means the server is reachable and responding. That is easier to debug than a silent timeout or a dropped connection. Once you identify the cause, the fix is usually straightforward.

If you have tried all the steps above and still get the error, the most likely cause is a transient server outage or a misconfiguration you overlooked. For public endpoints, the solution is always to use a different provider. For your own node, recheck every flag and firewall rule, and review the client's startup logs.

Back to rpc & nodes