Proxy rotation

Rotation exists to solve a rate problem. If a thousand requests come from one address, that address gets throttled or blocked. Spread across a thousand addresses, each looks like ordinary traffic. The mechanism is not subtle and the benefit is real — for the workloads it was designed for.

The sizing is arithmetic, not judgement. If a destination tolerates roughly sixty requests per minute from one address and you need six thousand a minute, you need at least a hundred concurrent exits, plus headroom for the ones that are cooling down or already burned. Working out that number first tells you whether the pool you are looking at is adequate; buying first and discovering the ceiling in production tells you the same thing more expensively.

The three implementations

• Per request — every new connection takes a new exit. Maximum spread, zero session continuity.
• Timed — the exit holds for a fixed interval, which is the same machinery as a sticky session with a short window.
• On demand — the provider exposes a rotation URL or API call and the address changes when you ask, which is the model most dedicated mobile proxies use.

Almost all of them sit behind a gateway. You point traffic at a single entry host and port, and the pool rotates behind it, so the device only ever sees one address while destinations see many. That design has a practical consequence: your device cannot tell you which exit was used for a given request. If you want that in your logs, you have to ask an external echo and record the answer yourself.

Where it helps and where it hurts

For anonymous, high-volume collection, rotation is the entire point. For logged-in work it is a liability: an account is supposed to have a stable home, and changing address mid-session produces exactly the pattern that stands out. This is the distinction most setups get wrong — they buy a rotating pool because it is what is advertised, then use it for accounts that need sticky sessions or a static address.

Rotation in the middle of a transaction

Rotation applies to new connections, not to established ones. An HTTP keep-alive connection or a resumed TLS session continues on the old exit while everything opened afterwards uses the new one, so a single page load can legitimately arrive from two countries. A multipart upload that spans a rotation boundary fails partway with an error that names neither the proxy nor the cause. An OAuth flow started on one address and completed on another returns a redirect from a country the flow did not begin in.

Measuring a pool honestly

Send fifty requests through the endpoint to an address echo and collect the answers — a shell loop over curl piped through sort and uniq is enough. Then count three numbers: distinct addresses, distinct /24 blocks, and distinct autonomous systems. A pool advertising millions of IPs that returns fifty addresses across three /24s is three subnets with a marketing page. Repeat the test pinned to your target country, since depth in the United States tells you nothing about depth in Vietnam, and country depth is the number that actually constrains a fleet.

The practical rule

• Scraping, monitoring, public data — rotate freely, per request.
• Logged-in sessions — sticky for the duration of the task, minimum.
• Long-lived accounts — no rotation at all; use a static ISP or mobile address.

Two misconceptions

The first is that rotating a device is like rotating a scraper. It is not: at device level everything moves, including background sync, push reconnections and update checks, so an app that reconnects at four in the morning does so from a new country while its user is asleep. The second is that rotation defends against fingerprinting. It does not. A rotating address behind a single unchanged device fingerprint is one device using many addresses, and the device is the part being recognised.