Pools and failover

Why pools exist

A single upstream proxy can go down: it gets rate limited, the underlying IP gets banned by a destination, or the box it runs on just falls over. If a relay link pointed at exactly one upstream proxy, that outage would be the renter’s outage too. Pools exist to break that dependency.

How a pool works

You group several registered upstream proxies (http or https only - see What Proxy Bastion does not do) into a failover pool, then point a relay link at the pool instead of at a single proxy. When a request comes in, the data plane picks a live member of the pool and forwards through it. If a member stops responding, the data plane can route subsequent requests to another member of the same pool, so the link as a whole keeps working even though one upstream did not.

What pooling does not fix

Pooling spreads risk across members, it does not eliminate it. If every member of a pool is down, the link is down. And pooling upstreams in different countries can create its own problem: the browser fingerprint a renter presents (timezone, language) does not automatically follow a failover switch to a different country’s exit IP, which can produce a visible mismatch. The control plane will warn about a cross-country pool at configuration time, but it does not block you from building one - that trade-off is yours to make.

Relationship to the rest of the model

A pool is a property of the upstream side, not of the relay link’s credential. The renter’s relay://<linkId>:<secret>@<relay host> link (see Relay links) does not change when the pool fails over; only which upstream is actually handling the traffic changes underneath it.