The symptom
connection refused from rpc.testnet.empooriochain.org. It looks exactly like an outage. Scripts report the network is down; developers report the network is down; an automated agent retries faster and makes it worse.
The cause
The public RPC nodes run fail2ban with an rpc-rate rule: roughly 10 requests per second per IP, with a one-hour ban on exceeding it. A polling loop, a burst of parallel queries, or a tool that fetches metadata on every call trips it within seconds. Automated coding agents hit it constantly — the same IP, tight loops, no back-off — and then conclude the chain is unreachable.
How to tell
A banned IP gets connection refused; an unbanned one gets a JSON-RPC response. Check from a different network or wait an hour. The node's own health is visible from the second endpoint (rpc2.testnet) if the first has banned you.
What to do
- Batch JSON-RPC calls — one request, many operations.
- Subscribe over WebSocket (
wss://…) for new heads, finalized heads and storage changes instead of polling. - Cache metadata; refresh it after runtime upgrades, not on every connection.
- Back off on error instead of retrying immediately.
- Run your own node for anything heavier — indexing, load testing, CI. The operator guide gets a full node syncing in minutes, and a full node needs no node key and no bond.
Why the limit exists
Two public nodes serve the whole testnet, and they are also the validators' RPC. A single misbehaving client can degrade the network for everyone. The limit is blunt because the network is small; it will loosen as the RPC tier separates from the validators.
The rule
Before reporting the network down, check whether you were banned. It is written in the operator guide, in the getting-started guide and now here, because it is the single most common false alarm the project sees.
From the September 2026 network operations notes.