ZeroTrace Proxy
Rotation Engine
Rotate automatically through a pool of proxies behind one local endpoint, choosing the next proxy on a policy you set and retiring the ones that fail.
Rotation Engine
Where the Chain Engine sends your traffic through several proxies in order, the Rotation Engine spreads your traffic across many proxies over time — each request (or each session) can go out through a different proxy from a pool. You point your tool at one steady local address, and behind it the engine keeps swapping which proxy actually carries the traffic.
This is what you want when you need to spread requests across many addresses rather than hide behind a stack of them.
Setting up a rotator
A saved rotator is a pool of proxies plus the policy that decides how to move through them.
- Give it a pool of proxies
Point the rotator at a saved pool, or paste proxies in directly. These are the addresses it will rotate through.
- Choose a rotation strategy
Decide how the engine picks the next proxy (below).
- Start its local server
Start the rotator. It opens a proxy endpoint on your own machine and gives you the address to use.
- Point your tool at it
Set your application to use that one local address. The engine handles picking a fresh proxy behind it.
Rotation strategies
The selection strategy decides which proxy is chosen next:
| Strategy | How it picks |
|---|---|
| Round-robin | Steps through the pool in order, one after another. |
| Random | Picks a proxy at random each time. |
| Least-recently-used | Reaches for the proxy that has gone the longest without being used, spreading load evenly across the whole pool. |
Independently of the strategy, turning on sticky by host keeps the same proxy for the same destination host — so a given site always sees you from one address while different sites see different ones — instead of rotating on every request regardless of destination.
Saved rotator fields
A saved rotator carries: a name, optional notes, and tags; its sources (one or more saved pools and/or an inline pasted list of proxies); the selection strategy; sticky by host; the local port it listens on (or 0 to let the engine pick one); and the policy it runs under.
Rotation policies
A rotator's policy governs how it behaves as proxies succeed and fail. It covers:
- Session limits — max requests per session and/or max session duration and max bytes before the engine rotates to another proxy.
- Rotate on status — automatically move to a fresh proxy when a destination responds with a blocking status (by default 403, 429, 502, 503, or 504), with a retry budget that caps how many alternates it will try for one request.
- Cooldown and quarantine — sideline a proxy that has been failing: a short cooldown after one failure, a longer quarantine once it has failed past the failure threshold.
- Concurrency limit — how many in-flight requests a single proxy may carry at once.
The complete field-by-field reference — every setting, what it does, and its default — is on Policies & live traffic.
Like the Chain Engine, a running rotator keeps a live traffic log and running totals so you can see which proxies are carrying requests and which are being rotated out. See Policies & live traffic.
Use a chain to layer several proxies for one connection so no single hop sees the whole picture. Use a rotator to spread many requests across many proxies over time. They solve different problems, and both run as a local endpoint you point your tools at.