Proxy Rotation Types: Per Request, By Interval, and On Demand

You can leave the same proxy address in your browser or script and still appear to a website from different IPs. That is what a rotating proxy service makes possible. The useful question is when the address changes: with a new request, after a set time, or when you decide the current task is finished.

These choices affect whether requests can use different exits independently or stay together on the same address. The broader choice between keeping an IP and changing it is covered in Static vs Rotating Proxies. Here, we look at how IP rotation actually happens and how to choose its timing.

What changes when a proxy rotates?

The address that matters is the exit IP: the public IP from which your traffic reaches the destination website. With a rotating gateway, the hostname and port you connect to can stay unchanged while the service sends your traffic through different exits behind it.

For example, a script can request a product page through one exit and another page through a different exit. You have not changed your home internet connection or edited the proxy settings. The service has changed the route used to reach the site.

Rotation has 2 separate parts: the rule that triggers a change and the mechanism that supplies the next exit. A timer can select another IP from a pool or trigger a mobile connection to reconnect. Both are timed rotation, but the change does not happen in the same way.

Per-request rotation: select an exit for each new request

With per-request rotation, the service selects an exit again for each request it can route independently. This suits work where individual requests do not need to share an IP, such as collecting separate public product pages or checking independent search results.

The selection does not necessarily produce an address you have never used before. An IP pool is finite, and random selection can return an earlier address. A rotating service distributes work across available exits; the word “rotating” alone does not promise a unique IP for every request.

There is also a practical distinction between a request and a connection. A browser can send several requests through an already open connection. With ordinary HTTPS tunneling, the proxy selects the exit when it opens the tunnel and does not read the encrypted requests inside it. In that setup, rotation happens between tunnels, even if the product calls the mode “per request.”

That is why refreshing a browser tab is not a reliable test of whether an IP should change. The browser may reuse its connection, and a page itself can load through several connections. Per-request rotation is not the same as changing IP once per page.

Time-based rotation: keep an exit for a defined window

With time-based rotation, also called interval rotation, the service attempts to keep an exit assigned for a period, then selects an exit again. The time window applies to a particular session or connection setting, rather than necessarily to every request on the account.

Suppose you choose a 5-minute window for a session. Related requests can use its assigned exit during that window. When the assignment expires, a later connection can receive a different IP. This is useful when several steps belong together and frequent IP changes would make the results inconsistent.

The starting point of the timer matters. A service might count from the first request in a session, run a recurring schedule for a proxy port, or have a separate timeout for inactivity. “5 minutes” can therefore describe different behavior. It also does not guarantee that an exit will remain available for the full period.

Temporarily keeping requests on the same IP is usually called a sticky session. It can work alongside rotation: preserve the exit during a task, then allow a new selection afterward. Session identifiers, expiry, and what happens when an exit disappears are covered in Sticky Sessions.

On-demand rotation: change the exit when the task is ready

With on-demand rotation, you control the moment of the change. A service may provide a dashboard button, a rotation URL, or an API command that your software can call. Some pool services also let you request a new assignment by starting a different proxy session.

This is useful when task length varies. For example, an automated test may open a site, complete a form, and wait for confirmation. A fixed timer cannot know whether that sequence is finished. Your application can finish the sequence first and request a new exit before starting the next independent test.

“On demand” does not mean you must click a button yourself every time. Software can trigger it automatically at a chosen point. The distinction is that the task decides when to rotate, rather than a timer expiring or a new request arriving.

Does rotation change an IP halfway through a response?

For an ordinary TCP connection through a proxy, the destination sees a fixed pair of network endpoints for that connection. A request does not leave through one exit IP and have its response return through a newly selected exit. The response belongs to the connection that carried the request.

When rotation becomes due, a service can keep an existing connection alive on the old exit and use the next assignment for new connections. Alternatively, it can close the old connection, leaving the application to reconnect. A modem reconnect can also interrupt active traffic. Rotation itself does not move an unfinished download seamlessly to another IP.

This explains why an IP may remain visible after a timer expires, or why a transfer may stop at the rotation boundary. The result depends on how the service handles existing connections. For a long download or another continuous connection, that behavior matters more than how frequently new IPs can be selected.

Selecting from a pool and reconnecting a modem are different operations

A pool-based rotator chooses among exits already available to the service. It can route a new connection through another server, home connection, or mobile device without reconnecting the device used by the previous request.

Your filters restrict that choice. If you ask for a particular country, city, or network, rotation should select within those settings where supported. Changing the IP does not require changing the country. But a narrow selection leaves fewer eligible exits, so addresses may repeat more often.

With a mobile modem reconnect, the service disconnects and reconnects the cellular data connection to try to obtain a different public exit IP. There can be a pause while it reconnects, and the carrier ultimately controls public addressing. Reconnecting the same modem does not guarantee an address different from the previous one.

A mobile proxy service can also rotate by selecting another device from a pool. The label “mobile” therefore does not tell you which operation its rotation button performs. The difference matters when you need to know whether a change can interrupt an active task.

Who rotates the proxies: the service or your application?

A rotating gateway handles selection for you. Your application keeps using its access point, while the service applies the rotation settings. With a proxy list, your application can instead switch entries between tasks, after a chosen number of requests, or on a schedule. It can select randomly or move through the list in order.

This means a list of fixed datacenter or ISP addresses can still be used in a rotating workflow. Each proxy keeps its own address; your software changes which proxy it uses. Rotation describes the switching behavior, not a separate source of IP addresses.

Replacing addresses in a subscription is another operation again. A provider may refresh your purchased proxy list on a schedule, changing which addresses you have access to. That does not automatically mean your application switches between those addresses on each request. Inventory replacement and traffic rotation need separate settings.

Choose the point where an IP change makes sense

Start with what must stay together. If every request is independent and using a spread of exits serves the task, per-request selection is a natural fit. If several actions need a consistent exit, keep their assignment together. A known duration can suit a timed window; a variable duration often suits a change triggered after completion.

Avoid choosing the shortest interval simply because the control allows it. Repeated reconnections can add delays or interrupt work. Equally, holding an exit for longer does not make an unavailable device stay online. If an exit disappears, some services select a replacement, while others can return an error to avoid silently changing the IP.

An IP change also leaves your browser cookies and account unchanged. It may change how a site treats the connection, but it does not reset every restriction or guarantee access. If requests fail, their responses and connection errors are more useful evidence than assuming that faster rotation will solve the problem.

The most useful rotation setting follows the boundaries of your work: keep an exit while continuity matters, and select again when the next task can stand on its own.