Proxying

We do not recommend proxying your endpoints via a third party or self hosted proxy. This does not improve performance and in the typical case will result in increased latency and reduced performance.

Before implementing proxying please contact us over our support channels to discuss the design goals you have with the proxying solution and if there may be ways we can help you achieve them without introducing third party proxying. We recognise there can be valid reasons for wanting to add a proxy layer, and we can work together with you to find the best approach that fulfils your needs.

However, if you have decided to place a frontend proxy (such as Cloudflare) in front of your RPC pool endpoint there are a few considerations to take into account:

1. In case your proxy is not geographically distributed or if it does not provide accurate EDNS information you will loose the latency advantage of our GeoDNS setup.

2. In general, our systems are fairly well protected from DDOS already, meaning that commercial DDoS providers like Cloudflare provides a layer of protection that your endpoint does not need.

3. If your proxy caches IPs of the domain names it looks up, this can results in reduced redundancy of your setup, meaning longer potential downtimes should we need to reroute your traffic due to node, routing or datacenter issues.

4. When placing a proxy in front of your RPC pool endpoint, you take over primary responsibility for rate limiting and abuse prevention. Our regular abuse prevention systems will need to be partially disabled.

5. You should ensure that your proxy can handle SSL termination for whatever domain you configure your proxy for. It will in turn need to validate the downstream SSL certificate as being valid for your rpcpool.com configured endpoint. In Cloudflare one way to achieve this is disabling SSL validation by setting the SSL settings for your domain to "Flexible" or "Full" (however see next point about security considerations).

6. We do not recommend disabling SSL validation downstream from your proxy, as this can result in breakage of end-to-end security. All proxying of SSL will result in a Man-in-the-Middle and you take full responsibility for any security incidents, traffic leakages or other impacts that insufficient SSL validation from the proxy may cause.

7. Make sure your proxy sends the correct Origin and Host headers to our downstream nodes. Without these headers being correctly set, our loadbalancers will not be able to route your traffic correctly and you may see additional 403 errors or CORS failures.

8. You should ensure that your proxy sends X-Forwarded-For/X-Real-IP header with details about the original requester.

9. You will need to contact us to use a specialised token from your proxy. This ensures that your proxy will not get blocked from our services for abuse. You need to take care that your proxy will not leak this token in error messages or otherwise. Special consideration needs to be taken if your proxy operates on the DNS layer (e.g. standard Cloudflare "Proxy" DNS records) rather than as a full HTTP layer proxy. Typically we cannot support DNS layer proxies for our shared endpoints, but there may be possibilities to support it for dedicated nodes.

10. Make sure your proxy accurately reports and monitors RPC call usage, HTTP status codes and other important parameters to prevent abuse. If you are using an external proxy and it causes abusive traffic on our shared pool especially we will be required to several limit or block your endpoint.