Feature gaps in etherproxy (failover, caching TTL, status endpoints) — proposing rpcproxy #48
Description
Hey everyone. I built rpcproxy, a high-performance JSON-RPC reverse proxy in Rust, intended as a drop-in replacement for etherproxy for people who are hitting missing features / unresolved issues.
Why it’s better (in practice):
- Priority-based failover: give it multiple upstream RPC URLs in order; it automatically skips backends that are down or unhealthy.
Active health checking: it continuously probes upstreams (via eth_blockNumber) and marks nodes unhealthy/stale, so you don’t keep routing to dead RPCs. - Smart caching (method-aware TTLs): immutable calls cache for ~1 hour, chain-tip calls use a configurable TTL — significantly reduces upstream load without breaking correctness.
- Request coalescing: identical in-flight requests get deduped so spikes don’t stampede your upstream.
- Full batch JSON-RPC support.
- Auth that works for “URL-only” clients: optional URL path token auth, which helps for clients that can’t set custom headers (example: Bee).
- Operational endpoints: /health plus authenticated /readiness and /status so you can actually see backend state + cache stats.
- Docker-ready with a real healthcheck.
If you’re running etherproxy today mainly to stabilize RPC access but need stronger caching/failover/health visibility, rpcproxy should be a better fit.
Quick start:
docker run -p 9000:9000 ghcr.io/metaprovide/rpcproxy:latest \
--targets https://rpc1.example,https://rpc2.exampleRepo: https://github.com/MetaProvide/rpcproxy
I’d love issues/PRs, especially from folks migrating off etherproxy or needing specific RPC-method caching rules.