IP de proxy residencial não está rotacionando? Causas e soluções

Geralmente o proxy está rotacionando normalmente e o seu cliente HTTP está reutilizando uma conexão. Veja como identificar a diferença e as seis causas que vale a pena verificar.

Você configurou um proxy rotativo, enviou dez requisições, e todas voltam reportando o mesmo endereço de saída. A conclusão óbvia é que a rotação está quebrada. Geralmente não está. Na maioria dos casos, o gateway está distribuindo endereços novos exatamente como solicitado, e algo entre seu código e ele está impedindo que isso aconteça, e o culpado mais comum é um recurso do seu cliente HTTP que existe para tornar as coisas mais rápidas.

Aqui estão as causas na ordem que vale a pena verificar, com a correção para cada uma.

Primeiro, verifique corretamente

Antes de diagnosticar, garanta que o teste em si seja válido. Uma única requisição de linha de comando por invocação é a verificação mais limpa, porque cada execução é um processo separado sem estado compartilhado:

for i in 1 2 3 4 5; do
  curl -s -x customer-USERNAME:PASSWORD@p.shifter.io:443 https://ipinfo.io/json \
    | python3 -c "import sys,json; print(json.load(sys.stdin)['ip'])"
done

Cinco endereços diferentes significa que a rotação funciona e sua aplicação é o problema. Cinco idênticos significa que a configuração é. Essa única distinção economiza a maior parte do tempo de depuração, então execute isso primeiro.

Causa um: um identificador de sessão no nome de usuário

A explicação mais simples. Se seu nome de usuário contém uma flag sid, você solicitou explicitamente uma sessão fixa, e manter o endereço é o comportamento correto em vez de uma falha.

customer-USERNAME-country-us-sid-abc123    # fixa: mesmo IP por design
customer-USERNAME-country-us               # rotativa: IP novo por requisição

Isso pega quem copiou um exemplo da documentação, ou quem construiu o nome de usuário com um helper que adiciona uma sessão por padrão. Remova a flag sid, e o ttl junto com ela já que o TTL só tem sentido junto com uma sessão. A semântica está em sticky versus rotating e na documentação de sessões.

Uma versão mais sutil: seu identificador de sessão é constante quando você queria que variasse. Se você gera um por job mas o job executa muitas requisições, cada requisição naquele job compartilha um endereço, o que é correto mas pode não ser o que você pretendia.

Causa dois: reutilização de conexão, a que pega todo mundo

Essa é a resposta na maioria das vezes quando o loop curl acima rotaciona e seu código não.

Clientes HTTP modernos mantêm conexões vivas e as reutilizam, porque abrir uma nova conexão TCP e TLS para cada requisição é lento. Quando seu cliente reutiliza um túnel existente para o proxy, a requisição viaja pela conexão que já está estabelecida, e essa conexão já tem um endereço de saída associado. A rotação acontece por conexão, não por requisição enviada por uma conexão já existente, então um objeto de sessão que mantém um pool de conexões enviará fielmente todas as requisições pela mesma saída.

A correção depende de quanto controle você quer. Ou desabilite o keep-alive, ou force uma nova conexão por requisição, ou faça cada requisição lógica usar um cliente novo.

import requests

PROXY = "http://customer-USERNAME:PASSWORD@p.shifter.io:443"
PROXIES = {"http": PROXY, "https": PROXY}

# Reutiliza uma conexão: mesmo endereço de saída em toda requisição
s = requests.Session()
for _ in range(5):
    print(s.get("https://ipinfo.io/json", proxies=PROXIES).json()["ip"])

# Conexão nova por requisição: rotaciona como esperado
for _ in range(5):
    r = requests.get("https://ipinfo.io/json", proxies=PROXIES,
                     headers={"Connection": "close"}, timeout=20)
    print(r.json()["ip"])

O mesmo se aplica em outros lugares: um http.Agent com keep-alive no Node, um HttpClient compartilhado no .NET ou Java, um pool de conexões no Go. Se sua linguagem tem um cliente padrão que agrupa conexões, e todas têm, isso é a primeira coisa a verificar no código da aplicação.

Vale dizer claramente: isso é um trade-off, não um bug. A reutilização de conexão é mais rápida e mais barata. Se seu trabalho realmente quer um endereço novo por requisição, você paga o custo de uma nova conexão a cada vez; se não quer, a reutilização é boa e muitas vezes preferível.

Causa três: você está verificando rápido demais, ou o pool é menor do que você pensa para aquele filtro

Dois efeitos relacionados.

Se você restringiu o filtro rigidamente, para uma cidade pequena ou um ASN específico, o conjunto de endereços que pode atendê-lo é muito menor do que o pool geral, então o mesmo endereço legitimamente reaparece com mais frequência. Isso não é uma falha, é aritmética. Amplie o filtro e a repetição desaparece.

Também lembre-se de que um pool residencial é feito de conexões reais que aparecem e desaparecem, então ver um endereço duas vezes em muitas requisições é esperado, não suspeito. Rotação significa que a próxima requisição é selecionada de forma independente, não que um endereço nunca pode se repetir. Se você precisa de distinção garantida para um workload, isso é uma restrição de design a ser tratada no seu próprio código.

Causa quatro: algo a montante está fazendo cache

Se você está testando por meio de um navegador, uma extensão, uma configuração de proxy em nível de sistema, ou uma rede corporativa, a requisição pode não estar indo para onde você pensa. Navegadores em particular mantêm conexões abertas de forma agressiva e as reutilizam entre abas, então um navegador é o pior ambiente para verificar rotação. Teste primeiro pela linha de comando, depois na sua aplicação, e só então em um navegador.

Da mesma forma, se seu código define variáveis de ambiente de proxy além de passar configuração explicitamente, uma pode estar sobrepondo a outra e enviando tráfego por algo diferente do gateway que você configurou.

Causa cinco: o endereço é o mesmo, mas a requisição nunca saiu

Uma direta que vale a pena descartar: se o proxy não está sendo realmente usado, toda requisição reporta o mesmo endereço, a saber, o seu. Confirme que o endereço que você está vendo não é o endereço do seu próprio servidor. Se for, a configuração do proxy não está sendo aplicada de forma alguma, o que é um problema diferente e geralmente é uma entrada https faltando junto com a http, ou um cliente que ignora a configuração de proxy para o esquema que você está usando.

Causa seis: uma sessão fixa que ainda não expirou

Se você está usando sessões fixas deliberadamente e esperando que rotacionem depois de um tempo, lembre-se de que o endereço se mantém até o TTL expirar. O tempo de vida padrão é 120 segundos a menos que você defina ttl explicitamente. Se quiser um endereço novo mais cedo, mude o identificador de sessão em vez de esperar, já que um identificador novo significa uma sessão nova.

Observe também que um endereço fixo pode cair antes do seu TTL se a conexão subjacente desaparecer, já que essas são conexões domésticas reais em vez de infraestrutura dedicada. Sticky significa melhor esforço pela duração solicitada, não uma garantia.

Um caminho de decisão rápido

Execute o loop curl. Se ele rotaciona e seu código não, você tem um problema de reutilização de conexão, que é a causa dois. Se nenhum dos dois rotaciona, verifique o nome de usuário quanto a uma flag sid, depois confirme que você não está vendo seu próprio endereço, depois amplie qualquer filtro geográfico estreito. Se rotaciona com menos frequência do que você gostaria, mas rotaciona, você está lidando com o tamanho do pool para aquele filtro, não com uma falha.

Para tudo mais, o comportamento ao redor está documentado em how rotation works, e se as requisições estão falhando em vez de se repetir, why requests time out e fixing 407 errors cobrem os dois modos de falha mais comuns.

Resumo final

Problemas de rotação geralmente não são problemas de rotação. Teste com processos separados primeiro para estabelecer se o gateway está rotacionando de fato, e se estiver, olhe para seu cliente HTTP, porque a reutilização de conexão é a favorita disparada: requisições enviadas por um túnel já aberto mantêm o endereço de saída que aquele túnel já tem. Depois disso, verifique se há uma flag sid perdida, confirme que você não está vendo seu próprio endereço, e lembre-se de que um filtro geográfico muito estreito extrai de um conjunto muito menor, então repetições são normais. Sessões fixas mantendo seu endereço estão funcionando conforme projetado, e mudar o identificador lhe dá um novo imediatamente.

O próprio modelo de rotação, e as flags que o controlam, estão na residential proxy network, onde o comportamento de sessão é um parâmetro por requisição em vez de uma configuração de plano, cobrado por GB independentemente da frequência com que você rotaciona.