---
title: "O que é rotação de IP e como ela funciona?"
description: "Rotação de IP é a troca do IP de saída das suas requisições dentro de um pool. Veja os três modos, o fluxo do gateway e por que às vezes o IP não muda."
url: https://proxynet.io/pt-br/blog/ip-rotation-explained
date: 2026-09-19
author: "Acar Diveroli"
category: "Proxy 101, Web scraping"
lang: pt-BR
---

# O que é rotação de IP e como ela funciona?

Você comprou um proxy rotativo, conectou seu script e enviou três requisições seguidas a um serviço de eco de IP. As três voltaram com o mesmo endereço. Ou aconteceu o contrário: um script que faz login no seu próprio painel caiu de novo na tela de login na segunda página, porque o IP de saída mudou no meio da sessão. Em nenhum dos dois casos o proxy está com defeito. O que existe é uma configuração montada sem saber qual evento dispara a rotação.

Neste artigo definimos rapidamente a rotação de IP e passamos ao assunto principal, como o processo funciona: o caminho que uma requisição percorre atrás de um gateway, os três modos de rotação (por requisição, por tempo, sessão fixa), os termos que se confundem, a reutilização de conexões como o motivo mais comum de o IP não mudar como você espera e as coisas que a rotação quebra. No fim há um exemplo curto e testado em Python que verifica a rotação e um guia de decisão.

> **Nota: Resposta rápida**
>
> Rotação de IP é a troca do endereço IP de saída das suas requisições dentro de um pool. Você se conecta a um único endereço (o gateway) e é o gateway que decide qual IP de saída será usado. A troca é disparada de três formas: a cada nova conexão, quando um prazo termina ou quando muda o identificador de sessão que você define. A rotação não é um método para ignorar um bloqueio; ela serve para distribuir a carga entre endereços, ver conteúdo conforme a localização e separar sessões umas das outras.

## O que é rotação de IP?

Rotação de IP (também chamada de rotação de proxies) significa que o IP de saída das requisições de rede não fica em um único endereço, mas vai mudando entre os endereços de um pool de IPs. O serviço que faz isso por você se chama proxy rotativo ou, em inglês, [rotating proxy](/pt-br/rotating-proxy); a definição do produto, o pool e as opções de segmentação estão naquela página. Aqui tratamos do processo, não do produto: quando o IP muda, quando não muda e quem decide isso.

O conceito não é tão estranho. O IP dinâmico da sua internet de casa também é um tipo de rotação: o provedor troca seu endereço de tempos em tempos, mas não é você quem decide quando ele muda nem qual endereço vem. Esse lado está explicado em [IP estático e IP dinâmico: qual a diferença e qual usar?](/pt-br/blog/static-ip-vs-dynamic-ip) e em [Como mudar o endereço IP](/pt-br/blog/how-to-change-ip-address). A diferença da rotação com proxy é que o controle é seu: você escolhe a frequência da troca, o país e quais requisições saem pelo mesmo endereço.

## Para que a rotação serve e para que não serve?

A rotação tem três finalidades legítimas:

- **Distribuir a carga.** Um trabalho que coleta as páginas públicas de centenas de sites e manda todo o tráfego por um único endereço joga sobre ele mais requisições do que um visitante real conseguiria gerar. A rotação mantém a carga por endereço em um nível razoável.
- **Ver o conteúdo conforme a localização.** Preço, estoque e resultados de busca mudam de acordo com o país do visitante. Fixar o pool em um país ou em uma cidade e rotacionar dentro dessa localização mostra a visão real daquele mercado.
- **Separar sessões.** Cada trabalho independente (contas de clientes diferentes, cenários de teste diferentes) sai pelo próprio endereço; um não carrega o rastro do outro.

Onde ela não serve também é claro. Se o site pediu para você desacelerar com um `429`, fechou um caminho no robots.txt ou proíbe acesso automatizado nos termos de uso, trocar de IP e continuar na mesma velocidade não resolve o problema; é desconsiderar uma preferência que o dono do site declarou abertamente. O quadro completo está em [Como fazer web scraping sem ser bloqueado](/pt-br/blog/web-scraping-without-getting-blocked), e a resposta correta a um `429` está em [O que é o erro 429 Too Many Requests e o rate limit](/pt-br/blog/http-429-too-many-requests).

## Como a rotação funciona por meio de um gateway (backconnect)?

Na rotação à moda antiga você tem uma lista de proxies e seu código escolhe o próximo endereço. No modelo de gateway a lista não fica com você. Você se conecta a um único endereço `host:port` e o provedor gerencia o pool que está atrás. Essa arquitetura se chama backconnect. O caminho de uma requisição HTTPS é este:

1. **O cliente se conecta ao gateway.** Seu script abre uma conexão TCP com um endpoint fixo como `pr.proxynet.io:8000`.
2. **As credenciais e os parâmetros são lidos.** O gateway valida o par `user:pass` do cabeçalho `Proxy-Authorization`. Preferências como país, cidade e identificador de sessão também são lidas nesta etapa, a partir de parâmetros acrescentados ao nome de usuário. Os dois métodos de autenticação estão em [Autenticação de proxy: user:pass ou whitelist de IP](/pt-br/blog/proxy-authentication-methods).
3. **O pool é filtrado.** Se você informou uma localização, o gateway só considera candidatas as saídas que atendem a esse critério. A rotação acontece dentro desse subconjunto.
4. **O nó de saída é escolhido.** Conforme o modo de rotação, uma nova saída é atribuída ou a saída já vinculada à sua sessão é reutilizada. Esta é a etapa que distingue os três modos de rotação.
5. **O túnel é estabelecido.** O gateway se conecta ao destino pela saída escolhida e devolve ao cliente `200 Connection Established`. O handshake TLS acontece depois disso, entre o cliente e o site de destino.
6. **O tráfego é encaminhado.** O site de destino enxerga a requisição como vinda do IP do nó de saída. Nem o endereço do gateway nem o seu chegam ao destino.

As primeiras linhas que o cliente envia ao gateway são parecidas com isto:

```text
CONNECT example.com:443 HTTP/1.1
Host: example.com:443
Proxy-Authorization: Basic dXNlcjpwYXNz
```

O método `CONNECT` é definido na [seção 9.3.6 da RFC 9110](https://www.rfc-editor.org/rfc/rfc9110#name-connect), e aqui se esconde um detalhe importante: depois que o túnel é estabelecido, o proxy só transporta bytes. Ele não consegue ver uma a uma as requisições HTTPS que passam por dentro. O IP de saída é escolhido no momento em que o túnel é estabelecido e não muda enquanto o túnel continuar aberto. Por isso "IP novo a cada requisição" significa, na prática, "IP novo a cada nova conexão". No HTTP sem criptografia o proxy vê cada requisição separadamente, então ali a troca por requisição é de fato possível; mas como hoje a maioria dos sites funciona com HTTPS, considere a conexão como unidade.

## Três modos de rotação: por requisição, por tempo e sessão fixa

Os modos se distinguem pelo evento que dispara a decisão "saída nova ou saída anterior" da quarta etapa.

### Rotação por requisição

Cada nova conexão aberta com o gateway recebe uma saída diferente do pool. O cliente não guarda estado e o gateway também não lembra de nada por você. É o modo dos trabalhos que coletam muitas páginas independentes entre si: cada página de produto é uma única requisição e a próxima não precisa vir do mesmo endereço. O custo é um novo handshake TCP e TLS a cada requisição; a latência sobe em relação a uma configuração que reutiliza a conexão.

### Rotação por tempo

O IP de saída muda em um intervalo determinado. Até o intervalo terminar, todas as conexões que você abre saem pelo mesmo endereço; quando termina, todas passam juntas para o novo. O gatilho é o relógio, não as suas requisições. É comum nas portas de proxy móvel que funcionam sobre um único modem ou aparelho: o IP é renovado quando o aparelho se reconecta à rede da operadora. A configuração é simples, mas você não consegue escolher em que ponto do seu trabalho a troca vai cair.

### Sessão fixa (sticky)

Você acrescenta um identificador de sessão (session ID) ao nome de usuário. As conexões que chegam com o mesmo identificador são vinculadas à mesma saída, e identificadores diferentes a saídas diferentes. Por quanto tempo a sessão fica no mesmo IP é algo que se escolhe no painel, entre 1 e 60 minutos; quando o prazo termina ou quando você muda o identificador, o gateway atribui uma nova saída. A diferença em relação à rotação por tempo é que o agrupamento é feito por você: se cada um de vinte trabalhos paralelos receber um identificador próprio, cada um roda ao lado dos outros com seu próprio endereço fixo. É o modo dos trabalhos em que o servidor guarda estado, como painéis com login, fluxos de carrinho e paginação. A parte de produto está na página [Proxies de sessão fixa](https://proxynet.io/pt-br/sticky-proxy).

Existe um limite: nos pools residenciais e móveis o nó de saída é um aparelho real e pode sair da rede. Nesse caso o gateway transfere a sessão para outra saída antes de o prazo terminar. Sessão fixa quer dizer "tente manter o mesmo IP durante esse tempo", não é garantia. Para um trabalho que exige continuidade rigorosa usa-se [Proxies estáticos](https://proxynet.io/pt-br/static-proxy), em que o endereço é alocado para você.

| | Por requisição | Por tempo | Sessão fixa | Estático (para comparação) |
|---|---|---|---|---|
| Evento que muda o IP | Cada nova conexão | O fim do intervalo | A mudança do identificador de sessão ou o fim do prazo | Não muda |
| Quem tem o controle | O gateway | O relógio | Você | Ninguém |
| Fluxos com estado | Quebram | Quebram no momento da troca | São preservados | São preservados |
| Em trabalhos paralelos | Um IP diferente por conexão | Todos no mesmo IP | Um IP diferente por identificador | Tantos quantos IPs você tiver |
| Trabalho típico | Leitura em massa de páginas independentes | Porta móvel de um único aparelho | Login, carrinho, paginação | Lista de IPs permitidos de uma API, conta de longa duração |

## Termos: rotating proxy, backconnect, sticky e os demais

Os termos se confundem porque a mesma coisa recebe vários nomes e coisas diferentes recebem o mesmo nome. Nas fontes em português, "proxy rotativo", "proxy rotacional" e "rotating proxy" são o mesmo produto.

| Termo | O que descreve | Com o que costuma ser confundido |
|---|---|---|
| Rotação de IP / rotação de proxies | O processo: o IP de saída muda dentro de um pool | É tomado pelo nome do produto |
| Proxy rotativo / rotating proxy | O produto: um serviço de proxy que rotaciona no gateway | Uma lista de proxies |
| Backconnect | A arquitetura: um único endpoint e um pool atrás | É tomado por um tipo de proxy à parte; na verdade é o modo de funcionar do proxy rotativo |
| Gateway | O `host:port` ao qual você se conecta; o servidor que escolhe a saída | O IP de saída. O site de destino não vê o endereço do gateway |
| Nó de saída / IP de saída | O endereço que o site de destino vê | O endereço do gateway |
| Pool de IPs | O conjunto de endereços entre os quais o gateway escolhe | Endereços que pertencem a você. O pool é compartilhado |
| Sessão fixa (sticky) | O mesmo identificador de sessão vinculado por um tempo à mesma saída | Um IP estático. A sessão fixa é temporária |
| Proxy estático | Um endereço alocado para você que não muda | Uma sessão fixa longa |
| Lista de proxies | Uma série fixa de endereços que você rotaciona com seu próprio código | Um proxy rotativo |

Um aviso: ao pesquisar "sticky session" também aparece documentação de balanceadores de carga. Ali o termo descreve um visitante sendo encaminhado sempre ao mesmo servidor de backend. A lógica é a mesma e o sentido é o inverso: no balanceador fixa-se o tráfego de entrada, no proxy o de saída.

## Quem deve rotacionar, seu código ou o gateway?

Se você tem uma lista de endereços fixos que são seus, a rotação é feita pelo seu código: antes de cada requisição escolhe-se o próximo endereço da lista ou um aleatório. A seleção sequencial divide a carga por igual; a seleção aleatória não exige manter um contador comum entre trabalhos que rodam em paralelo. Tirar da lista o endereço que não responde e limitar o ritmo por endereço também fica por sua conta. O código Python dos dois métodos, passo a passo com Requests, está em [Como rotacionar proxies em Python](/pt-br/blog/how-to-rotate-proxies-in-python); não vamos repeti-lo aqui.

No modelo de gateway todas essas tarefas passam para o outro lado. No seu código sobra um único endereço de proxy e o modo de rotação é escolhido com parâmetros no nome de usuário. Em troca, você não conhece os endereços um a um: não dá para saber de antemão por qual IP a próxima requisição vai sair, você só define o país, a cidade e o comportamento da sessão. Para um trabalho pequeno com poucos endereços, uma lista basta; conforme o pool cresce, manter a lista toma mais tempo do que o próprio trabalho.

## Por que o IP não mudou? A reutilização de conexões

Quando você vê sempre o mesmo IP com a rotação por requisição ligada, o motivo mais comum não é o proxy, é o seu cliente. No HTTP/1.1 as conexões são persistentes por padrão ([RFC 9112, 9.3](https://www.rfc-editor.org/rfc/rfc9112#name-persistence)): depois de receber uma resposta, o cliente mantém a mesma conexão TCP aberta para a próxima requisição. Atrás de um proxy isso significa que o mesmo túnel `CONNECT` é reutilizado. Como a saída do túnel é escolhida quando ele é estabelecido, o gateway não encontra nenhum momento para rotacionar.

Os clientes que reutilizam a conexão são mais numerosos do que você imagina. No Python Requests, o objeto `Session` faz isso sozinho; a [documentação do Requests](https://requests.readthedocs.io/en/latest/user/advanced/#keep-alive) informa que o keep-alive é automático dentro de uma sessão. `Client` no HTTPX, `ClientSession` no AIOHTTP, os agents com keep-alive ativado no Node.js e todos os navegadores se comportam do mesmo jeito. As diferenças entre as bibliotecas estão em [Comparativo entre HTTPX, Requests e AIOHTTP](/pt-br/blog/httpx-vs-requests-vs-aiohttp).

O que fazer depende do que você quer:

- **Se você quer um IP novo a cada requisição**, abra uma nova conexão para cada requisição ou acrescente o cabeçalho `Connection: close`. O destino fecha a conexão depois da resposta e o túnel fecha junto. Você aceita o custo de um novo handshake a cada vez.
- **Se você quer ficar no mesmo IP**, não confie no keep-alive. A conexão pode cair por timeout, por decisão do servidor ou por uma nova tentativa, e uma nova conexão traz um novo IP. Construa a continuidade com o identificador de sessão, ou seja, com uma sessão fixa.
- **Na automação de navegadores**, uma única página abre muitas conexões paralelas para baixar seus recursos. Com rotação por requisição, o HTML de uma página é pedido a partir de um endereço e as imagens a partir de outros. Ao trabalhar com navegador, use sessão fixa; a configuração está em [O que é Playwright e como usá-lo com proxy](/pt-br/blog/playwright-proxy).

## Verificar a rotação: três requisições seguidas

A forma de ver que a sua configuração se comporta como esperado é enviar algumas requisições seguidas a um serviço que devolve seu IP de saída como resposta. O exemplo abaixo envia as mesmas três requisições de duas formas: primeiro com uma nova conexão a cada vez, depois por meio de uma única `Session`.

```python
import requests

PROXY = "http://user:pass@pr.proxynet.io:8000"
PROXIES = {"http": PROXY, "https": PROXY}
IP_ECHO = "https://api.ipify.org"

def new_connection_each_time(count=3):
    ips = []
    for _ in range(count):
        # Chamada sem sessão: cada requisição abre e fecha a própria conexão
        response = requests.get(IP_ECHO, proxies=PROXIES, timeout=20)
        ips.append(response.text.strip())
    return ips

def shared_session(count=3):
    ips = []
    with requests.Session() as session:
        session.proxies.update(PROXIES)
        for _ in range(count):
            # Mesma sessão: o túnel aberto na primeira requisição é reutilizado
            response = session.get(IP_ECHO, timeout=20)
            ips.append(response.text.strip())
    return ips

def report(label, ips):
    print(f"{label}: {ips} -> {len(set(ips))} IPs diferentes")

report("nova conexão a cada vez", new_connection_each_time())
report("sessão compartilhada (keep-alive)", shared_session())
```

Em um gateway que rotaciona por requisição, a saída esperada é parecida com esta (os endereços pertencem às faixas de exemplo reservadas para documentação):

```text
nova conexão a cada vez: ['203.0.113.24', '198.51.100.7', '203.0.113.181'] -> 3 IPs diferentes
sessão compartilhada (keep-alive): ['198.51.100.92', '198.51.100.92', '198.51.100.92'] -> 1 IPs diferentes
```

Ao testar o exemplo em um proxy de teste local, vimos no log do proxy que a primeira função abria três túneis `CONNECT` separados e a segunda apenas um; quando o cabeçalho `Connection: close` foi acrescentado à `Session`, o número de túneis voltou a subir para três. Se você também vê um único IP na primeira linha, está se conectando com um nome de usuário de sessão fixa ou com um endereço estático. Para conferir também o país do IP de saída e os vazamentos, veja [Seu proxy está funcionando? Como testar um proxy](/pt-br/blog/how-to-test-a-proxy).

## Como funciona um proxy móvel rotativo?

Ao ouvir "proxy móvel rotativo" vem à cabeça uma mesa cheia de celulares, mas o mecanismo real está na rede da operadora. As operadoras móveis dividem um único endereço IPv4 público entre muitos assinantes ao mesmo tempo (CGNAT); quando um aparelho se reconecta à rede, pode receber outro endereço do pool da operadora. A rotação do proxy móvel se apoia nesse comportamento: ou um único aparelho se reconecta em intervalos definidos (rotação por tempo), ou o gateway escolhe entre muitos aparelhos. Como o CGNAT funciona está explicado em [O que é CGNAT, como saber se você tem e como sair](/pt-br/blog/what-is-cgnat).

Isso tem duas consequências práticas. A primeira: um IP de saída móvel é compartilhado naquele momento com assinantes reais; usar o endereço de forma intensa afeta não só você, mas também essas pessoas, por isso em um pool móvel um ritmo baixo não é gentileza, é obrigação. A segunda: em um pool móvel, "IP novo" nem sempre significa um endereço que você ainda não viu; o pool da operadora é limitado e o mesmo endereço pode voltar para você. A parte de produto está na página [Proxies móveis](https://proxynet.io/pt-br/mobile-proxy).

## O que a rotação quebra

Algumas coisas quebram em silêncio quando a rotação é ligada. O ponto em comum é que o servidor também reconhece você por algo além do IP.

- **Incoerência entre cookie e IP.** Seu armazenamento de cookies continua o mesmo e o IP muda a cada requisição. O site vê o mesmo cookie de sessão vindo de cidades diferentes em questão de minutos; a lógica de segurança encerra a sessão ou pede uma nova verificação. A regra é simples: um armazenamento de cookies, um identificador de sessão, um IP. O desenho dos trabalhos que exigem login com a sua própria conta está em [Login, sessões e cookies em Python](/pt-br/blog/python-login-session-cookies).
- **A sessão que cai no meio da paginação.** Resultados de busca e listas com filtros muitas vezes dependem de um estado guardado no servidor (um cursor, uma sessão de busca). Se o IP muda na quinta página, o site pode mandar você de volta para a primeira ou entregar de novo os mesmos registros; os dados saem incompletos ou duplicados e você não vê nenhum código de erro. Os detalhes estão em [Paginação em web scraping](/pt-br/blog/pagination-web-scraping).
- **Rotação sem localização definida.** Se você não informa uma localização, rotaciona pelo pool inteiro: uma requisição sai da Alemanha, a seguinte do Brasil. Os preços chegam em outra moeda, as páginas em outro idioma e os dados coletados deixam de ser comparáveis entre si.
- **Contadores que não dependem do IP.** Se o limite de requisições é contado por conta, por cookie ou por chave de API, a rotação não muda nada. O que fazer em cada código está reunido em [Códigos de status HTTP no web scraping](/pt-br/blog/http-status-codes-web-scraping).

## Casos de uso

- **Monitoramento de preço e estoque em muitos sites.** Cada página de produto é uma requisição independente; o país é fixado e o modo é por requisição. O desenho está na nossa página de [monitoramento de preços](/pt-br/price-monitoring), e os métodos em [Como monitorar preços da concorrência no e-commerce](/pt-br/blog/competitor-price-tracking).
- **Coleta de catálogos e anúncios públicos.** Baixa concorrência por site e rotação para distribuir a carga: [solução de extração de dados](/pt-br/data-scraping).
- **Conferir como algo aparece em uma localização.** Para conferir, a partir de conexões domésticas, como um anúncio, um preço ou uma página aparece em uma cidade específica: [Proxies residenciais](https://proxynet.io/pt-br/residential-proxy).
- **Painéis em que você trabalha com suas próprias contas.** Um identificador de sessão por conta e o mesmo IP durante toda essa sessão: sessão fixa.
- **APIs que exigem lista de IPs permitidos.** Se o outro lado vai incluir seu endereço na lista dele, a rotação não serve, o endereço não pode mudar: [IP estático para acesso a API](/pt-br/blog/static-ip-for-api-access).

## Erros comuns

- **Esperar rotação por requisição com uma `Session`.** A sessão reutiliza a conexão; o IP continua o mesmo até o túnel fechar.
- **Dar o mesmo identificador de sessão a todos os trabalhos paralelos.** Todos se acumulam em um único IP e a vantagem de distribuir a carga se perde.
- **Colocar a rotação no lugar do limite de ritmo.** Mesmo com a troca de endereço, a carga total sobre o destino é a mesma; o limite de concorrência por site e as esperas continuam necessários.
- **Repetir a tentativa na hora com um IP novo.** Reenviar sem esperar depois de um `429` ou de um `503` desconsidera a desaceleração que o servidor pediu.

## Guia de decisão

| Necessidade | Recomendação |
|---|---|
| Muitas páginas públicas independentes entre si | Rotação por requisição, país fixo |
| Login, carrinho ou formulário de várias etapas | Sessão fixa, um identificador por fluxo |
| Lista longa percorrida com paginação | Sessão fixa; mude o identificador quando a lista acabar |
| Automação de navegadores (Playwright, Selenium) | Sessão fixa, um identificador por perfil de navegador |
| Contas independentes rodando ao mesmo tempo | Um identificador de sessão por conta |
| Lista de IPs permitidos, uma única identidade duradoura | Proxy estático |
| Você tem alguns endereços fixos | Rotação de lista no código |
| O site devolve `429` | Rotação não: espera e velocidade menor |

## Perguntas frequentes

### Rotação de IP e proxy rotativo são a mesma coisa?

Uma é o processo, o outro é o produto. Rotação de IP é a troca do endereço de saída, e você também pode fazê-la no seu próprio código com uma lista de proxies. O proxy rotativo (rotating proxy) é o serviço que faz isso por você no gateway.

### Proxy backconnect é um tipo de proxy à parte?

Não. Backconnect é o nome de uma arquitetura: você se conecta a um único endpoint e o gateway escolhe a saída no pool que está atrás. Os serviços de proxy rotativo residencial e móvel funcionam assim. O tipo do IP (conexão doméstica, móvel, datacenter) não é definido pelo backconnect, e sim pela origem do pool; a diferença entre os tipos está em [Proxy ISP ou residencial: diferenças e qual escolher](/pt-br/blog/isp-vs-residential-proxy).

### Por que o IP não muda a cada requisição com a rotação ligada?

O mais provável é que seu cliente esteja reutilizando a mesma conexão. No HTTPS o IP de saída é escolhido quando o túnel `CONNECT` é estabelecido e não muda enquanto o túnel continuar aberto. Abra uma nova conexão para cada requisição ou envie o cabeçalho `Connection: close`. Confira também se sobrou um parâmetro de sessão fixa no seu nome de usuário.

### Quanto tempo dura uma sessão fixa?

A duração é escolhida no painel, entre 1 e 60 minutos, e, mudando o identificador de sessão, você pode passar para um novo IP quando quiser. A duração é um limite máximo, não uma garantia: se o nó de saída sair da rede, o gateway transfere a sessão mais cedo para outro endereço. Escreva seu código de modo que ele reinicie o fluxo se o IP mudar no meio da sessão.

### Usar rotação dispensa respeitar o limite de requisições?

Não. A rotação reduz a carga por endereço, não a carga total sobre o servidor de destino. O limite de concorrência por site, as esperas entre requisições e o respeito ao cabeçalho `Retry-After` continuam necessários com rotação.

### Quantos IPs são necessários para rotacionar?

Não existe um número único correto; o cálculo parte do ritmo de requisições por endereço. No modelo de gateway você não precisa fazer essa conta, porque não compra endereços: rotaciona pelo pool inteiro e a cobrança costuma ser por tráfego. Os critérios de escolha estão em [O que observar ao comprar um proxy](/pt-br/blog/proxy-buying-guide).

## Em resumo

Rotação de IP é a troca do endereço de saída dentro de um pool, e quem decide é o gateway: a cada nova conexão, ao fim do prazo ou quando o identificador de sessão muda. Como no HTTPS a saída é escolhida quando o túnel é estabelecido, a rotação "por requisição" é na verdade por conexão; um cliente que reutiliza a conexão fica no mesmo IP. Escolha rotação por requisição para páginas independentes, sessão fixa para fluxos com estado e um endereço estático para identidades que não podem mudar, e sempre informe o país de forma explícita. A rotação não substitui o limite de ritmo; ela distribui a carga, e um ritmo de rastreamento respeitoso continua necessário. Você pode comparar os tipos adequados ao seu trabalho nos nossos [serviços de proxy](/pt-br/proxy).