---
title: "Rotating proxy"
url: https://proxy.wiki/glossary/rotating-proxy/
type: Glossary Term
author: "proxy.wiki editorial"
published: 2026-08-19
updated: 2026-08-29
site: proxy.wiki
topics: ["Proxy fundamentals"]
license: CC BY 4.0 — quote freely with attribution to https://proxy.wiki/
---

# Rotating proxy

> A proxy endpoint that changes the exit address automatically, either on every request or on a timer.

**A rotating proxy assigns a different [exit address](/glossary/exit-node/) over time from a [pool](/glossary/proxy-pool/), without you managing individual addresses.** You connect to one endpoint and the provider handles selection.

## Two rotation models

- **Per request.** Every request may leave from a different address. Best for large numbers of independent fetches.

- **[Sticky](/glossary/sticky-session/).** The same address is held for a set period, so a multi-step flow stays coherent.

## The mistake people make

Rotating on every request is not automatically safer. If a workflow spans several requests — a search, then a result page, then a detail page — changing address mid-flow can look more suspicious than keeping one, because a real user’s address does not change between clicks. Match the rotation to the shape of the task.

## Where it is configured

Usually by port, by a flag in the username, or by an API call. There is no standard; the syntax is provider-specific and worth checking before you build against it.

## Choosing a rotation interval

Rotation is not free. Each new address costs a fresh TLS handshake, discards any warmed connection, and abandons whatever the site associated with the previous address. Match the interval to what the target tracks.

| Work | Sensible rotation | Reason |
| --- | --- | --- |
| Independent page fetches | Every request | Nothing links the requests, so nothing is lost |
| Paginated listings | Per listing, not per page | Page 2 from a new address looks unrelated to page 1 |
| Anything after a login | Never during the session | An address change mid-session is a strong signal |
| Checkout or multi-step forms | Never during the flow | State is bound to the session, not the address |

[The full guide](/guides/rotating-vs-sticky-sessions/) works through the trade-off in more depth.

## The failure this causes most often

A crawler rotates per request, then cannot understand why a paginated list returns page 1 repeatedly. The site bound the cursor to a session, the session to an address, and the address changed. The symptom looks like a parsing bug and is a rotation bug.

## Frequently asked questions

### Should I rotate on every request?

Only when the requests are genuinely independent. If any two requests are related, through pagination, a session cookie or a login, rotating between them breaks the link the site expects and often looks more suspicious than reusing one address.

### Does rotating faster reduce blocks?

Not by itself. Rotation spreads volume across addresses, which helps against per-address rate limits. It does nothing against fingerprinting, and an address that changes every request while a session cookie stays constant is itself an anomaly.

### Where is rotation configured?

At the provider, not in your client. It is usually selected through the username format or the port you connect to. Your code keeps pointing at the same gateway.

## Sources

1. [RFC 6585: status code 429, the limit rotation is often used against](https://www.rfc-editor.org/rfc/rfc6585.html)