Proxy Rotation: When the IP Changes
Proxy rotation changes the exit IP that a website sees when it receives your traffic. The change can happen with a new request, after a set interval, or when your application asks for another address. The right timing lets you spread independent requests across different IPs while keeping related actions together.
The broader choice between a fixed address and changing addresses is covered in Static vs Rotating Proxies. Here, the question is what triggers a change and how it affects requests already in progress.
What changes during rotation?
With a rotating gateway, the address entered in your software can stay the same while the website sees different exit IPs. You connect to the same hostname and port; the service selects the exit used for the connection to the website.
For example, a price monitor can fetch one public product page through 192.0.2.14 and another through 198.51.100.27. These are example addresses. The computer running the monitor has not changed its internet connection; the requests reach the site through different exits.
Two separate decisions determine the result: when to select an exit again and where to get the next exit. A timer might select another available proxy or reconnect a mobile modem. The trigger is the same, but the operation and any interruption can differ.
Rotation with each request
With per-request rotation, the service makes a new exit selection for each request it can route independently. This suits separate product pages, public listings or search queries that do not need a shared IP. The word “request” needs care here: for HTTPS and SOCKS5 TCP traffic, rotation commonly applies when a new connection to the destination is opened.
Imagine collecting the price from 500 product pages. Each page provides a separate result. The service can distribute those requests among available exits instead of sending the whole job through one address. Several requests running at the same time can also use different exits.
A new selection can return an address used earlier. The available pool is finite, and selection may be random. Per-request rotation does not by itself promise 500 different IPs for 500 requests.
A request and a connection are different
An application can send several HTTP requests over one connection. For an ordinary HTTPS connection through a proxy, it first opens a tunnel to the destination. The encrypted requests then travel inside that tunnel, and the proxy forwards their data without reading the individual requests.
The exit therefore stays the same for that tunnel. A service described as per request may select another exit when the application opens a new tunnel or destination connection. Reusing the existing tunnel can keep the previous IP.
A browser page can load many resources over several connections, and refreshing it can reuse connections that are already open. Rotation is consequently not tied to one click, one tab, or one complete page load.
Rotation at a set interval
With time-based rotation, an IP assignment lasts for a defined window. After that window, the service selects an exit again. Related requests can share the assigned address during the window, provided the exit remains available.
Suppose a session starts at 10:00 with a five-minute duration. A test opens a catalog, applies a filter, and checks the next results page using the same exit. At 10:05 the assignment expires; a new connection after expiry can receive a different address. Five minutes is an example here, not a standard interval for every service.
Check when the timer starts. It may count from the first request in a session or follow a schedule for a proxy port. If the next scheduled change is in one minute, starting a task now does not give you a full five-minute window. A separate inactivity timeout can also end an assignment earlier.
The interval usually applies to a particular session, port, or proxy connection setting. It does not necessarily rotate every connection on an account at once. If several tasks need separate IP assignments, they need the corresponding separation supported by the service.
Retaining an assigned exit across several requests is commonly called a sticky session. A rotating service can use this mode to keep an address for a while and then select again.
Rotation on demand
With on-demand rotation, you or your application choose the moment to request another exit. Depending on the service, the control may be a dashboard button, a rotation URL, or an API command. Some services also make a new assignment when you start a different proxy session.
This is useful when a task has several connected steps but an unpredictable duration. A test might open a form, submit it, and wait for the confirmation page. It can retain the current exit through the whole sequence and request another assignment before starting the next independent test.
On-demand rotation can be automated: the application sends the change command after a completed task or a chosen number of requests. “On demand” describes who decides when to switch. It does not require a person to press a button each time.
The control's scope also matters. A command may affect only one session, an entire proxy port, or a physical modem shared by several connections. If it changes the assignment for all those connections, other work using that resource can be affected too.
What happens to a request already in progress?
For an ordinary TCP connection to a website, the exit IP remains part of that connection. A request and its response use the same established connection. Rotation cannot simply move the unfinished exchange onto another exit IP.
A service can handle the rotation boundary in different ways. It may let an existing connection finish on its current exit and apply the new assignment to later connections. It may instead close the connection, requiring the application to reconnect. Reconnecting a modem can also interrupt the traffic passing through it.
Consider a download that starts just before a timed rotation. If the connection is kept open, the download can continue through the old exit after the timer expires. If the connection is closed, the application must restart or resume the download where supported. The rotation interval alone does not tell you how an active transfer will behave.
Where does the next IP come from?
Selecting another exit from a pool
A pool-based service selects an available exit. The next connection might use a different IP on the same datacenter server, another server, a household connection or a mobile device. Selecting an exit from a pool does not require reconnecting the device that carried the previous request.
Where location or network filters are supported, they restrict the eligible exits. Selecting another IP within a country does not require changing country. A narrow selection can also mean a smaller set of available addresses and more repeats.
Reconnecting a mobile modem
Some mobile proxy services rotate by disconnecting and re-establishing the modem's cellular data connection. Traffic through that connection can pause during the process. The carrier determines the public addressing, so reconnecting can return the same public IP.
Other mobile services select a different available device from a pool. Both are forms of mobile proxy rotation, but they can have different effects on ongoing work. The term mobile rotation alone does not specify which mechanism is used.
Who controls the switching?
With a rotating gateway, the provider selects the exit according to the requested mode. Your application can keep the same gateway in its settings while the service manages the exit addresses.
Your application can also rotate a list of fixed proxies itself. For example, it can use the first address for one task, the second for the next, and continue through the list. It can select in order or randomly, switch after each independent request, or retain a proxy until a task finishes.
A list of static datacenter or ISP proxies can therefore support a rotating workflow. Each proxy's own IP stays fixed; your software changes which proxy carries the next connection. This is useful when you want to control the assignment of addresses to jobs yourself.
Replacing purchased addresses in a subscription is a separate operation. A scheduled refresh changes the set of IPs you can access. It does not automatically make your application switch among them during its work.
Choose the timing around the task
Start by identifying which actions need to keep the same exit. Then place the change at a point where the next request or task can use another IP.
| Task | Suitable timing | Reason |
|---|---|---|
| Collect separate public product pages | Per request or new destination connection | Each result can be fetched through a separately selected exit. |
| Run several related checks within a known period | A timed assignment covering those checks | The requests can share an exit while the assignment remains active. |
| Complete a sequence whose duration varies | On demand, after completion | Your application knows when the steps that belong together have finished. |
For a long transfer, the handling of existing connections matters more than a short rotation interval. For multiple simultaneous tasks, check whether the rotation control applies to each task separately or to a resource they share.
Changing the IP does not clear browser cookies or account data. A website can still associate requests with the same session or account. Rotation distributes traffic among exits; it does not reset every restriction or guarantee that a request will succeed.
Check the chosen mode with a small test before a full run. Record the exit IP and time for new connections, then repeat the check across the expected timer boundary or after a change command. Also check whether an open connection survives. These observations show whether the actual switching fits the task; repeated IPs alone do not prove that rotation is broken.