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

Publicado:

21 min de leitura

Acar Diveroli
Autor: Acar Diveroli
Centenas de rotas de saída se abrem em leque a partir de um único núcleo de gateway, com etiquetas de três IPs de saída

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.

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; 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? e em Como mudar o endereço IP. 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, e a resposta correta a um 429 está em O que é o erro 429 Too Many Requests e o rate limit.

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.
  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, 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.

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, em que o endereço é alocado para você.

Por requisiçãoPor tempoSessão fixaEstático (para comparação)
Evento que muda o IPCada nova conexãoO fim do intervaloA mudança do identificador de sessão ou o fim do prazoNão muda
Quem tem o controleO gatewayO relógioVocêNinguém
Fluxos com estadoQuebramQuebram no momento da trocaSão preservadosSão preservados
Em trabalhos paralelosUm IP diferente por conexãoTodos no mesmo IPUm IP diferente por identificadorTantos quantos IPs você tiver
Trabalho típicoLeitura em massa de páginas independentesPorta móvel de um único aparelhoLogin, carrinho, paginaçãoLista 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.

TermoO que descreveCom o que costuma ser confundido
Rotação de IP / rotação de proxiesO processo: o IP de saída muda dentro de um poolÉ tomado pelo nome do produto
Proxy rotativo / rotating proxyO produto: um serviço de proxy que rotaciona no gatewayUma lista de proxies
BackconnectA 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
GatewayO host:port ao qual você se conecta; o servidor que escolhe a saídaO IP de saída. O site de destino não vê o endereço do gateway
Nó de saída / IP de saídaO endereço que o site de destino vêO endereço do gateway
Pool de IPsO conjunto de endereços entre os quais o gateway escolheEndereços que pertencem a você. O pool é compartilhado
Sessão fixa (sticky)O mesmo identificador de sessão vinculado por um tempo à mesma saídaUm IP estático. A sessão fixa é temporária
Proxy estáticoUm endereço alocado para você que não mudaUma sessão fixa longa
Lista de proxiesUma série fixa de endereços que você rotaciona com seu próprio códigoUm 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; 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): 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 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.

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.

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.

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.

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.

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.
  • 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.
  • 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.

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, e os métodos em Como monitorar preços da concorrência no e-commerce.
  • 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.
  • 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.
  • 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.

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

NecessidadeRecomendação
Muitas páginas públicas independentes entre siRotação por requisição, país fixo
Login, carrinho ou formulário de várias etapasSessão fixa, um identificador por fluxo
Lista longa percorrida com paginaçãoSessã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 tempoUm identificador de sessão por conta
Lista de IPs permitidos, uma única identidade duradouraProxy estático
Você tem alguns endereços fixosRotação de lista no código
O site devolve 429Rotaçã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.

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.

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.