O login cai não por causa de um proxy "bugado", mas porque o site compara o tempo todo o endereço da requisição com o que foi registrado na entrada. Trocar o IP no meio de uma sessão logada parece, para o servidor, exatamente um roubo de cookie: o mesmo token chega de outro ponto da rede. Vamos entender a mecânica dessa vinculação, por que a rotação prejudica justamente as sessões longas e como organizar o trabalho para que o login não caia.

Como a sessão fica presa ao endereço e à sub-rede

Depois do login, o servidor entrega um token ou cookie e, na maioria dos sistemas, guarda junto com ele uma impressão digital da requisição: IP, às vezes só a sub-rede /24, User-Agent, conjunto de cabeçalhos. A cada requisição seguinte, isso é comparado com o valor salvo. Uma divergência de país ou de ASN quase sempre zera a sessão na hora: o site não consegue distinguir uma troca de endereço do sequestro do cookie por outra pessoa. A troca dentro da mesma sub-rede passa sem perguntas em parte dos serviços; em outros, também exige novo login: a política depende de quão sensível o site é a operações financeiras.

O ASN, a rede autônoma à qual o endereço pertence, é um fator à parte: ao passar de um provedor residencial para uma operadora móvel, mudam ao mesmo tempo a sub-rede e o ASN, mesmo que formalmente o país e a cidade continuem os mesmos. Como isso acontece no nível da identificação do endereço está explicado no artigo o que é ASN e por que ele importa para proxies.

O que acontece na rotação em um canal por tráfego

Canais residenciais e móveis com cobrança por gigabyte trocam, por padrão, o endereço entregue por timeout ou por limite de tráfego por sessão: isso faz parte da mecânica do canal, não é uma falha. Se uma requisição logada chega de um novo IP, de outro pool, o servidor vê a troca de endereço em um token ativo e então pede uma nova verificação ou zera a sessão inteira. Para scraping ou coleta de dados isso não atrapalha: ali cada requisição é independente. Para trabalhar dentro de uma conta, é a causa direta de logins constantes.

O problema piora se a rotação estiver configurada de forma agressiva, por exemplo a cada poucos minutos em vez de ser atrelada a uma operação. Aí até um uso tranquilo da área logada vira uma série de quedas, porque o endereço muda com mais frequência do que dura uma sessão típica de usuário.

Por que sessão longa vale mais que um endereço "novo"

Em um cenário logado, a reputação de um IP específico importa menos do que a estabilidade dele durante toda a operação. Para o site, é mais importante ver o mesmo endereço da entrada até a saída do que receber um IP formalmente "limpo" no meio da sessão. A troca frequente de endereço em uma mesma conta, por si só, aumenta a suspeita: é um padrão típico de sequestro de conta ou de uso por botnet, não de um usuário comum. Portanto, enquanto você trabalha logado, o objetivo não é o endereço "mais novo", e sim o mesmo endereço durante toda a sessão.

Isso não quer dizer que o endereço deva ser eterno: um aluguel mensal sem rotação não é necessário para uma operação pontual. Quer dizer que o tempo de vida do endereço entregue deve ser maior ou igual ao tempo que você passa logado em cada acesso.

Sessões sticky e a duração delas

Sessão sticky é o modo em que o canal mantém o mesmo endereço por um tempo definido, em vez de rotacionar a cada requisição. As janelas típicas vão de alguns minutos até uma hora; em parte dos canais é possível fixar o endereço durante todo o período pago, como em um IP dedicado de datacenter ou ISP. A diferença de abordagem: os canais por tráfego vendem o tempo de retenção do endereço, enquanto o IP dedicado vende o próprio endereço durante todo o período de aluguel, sem janela flutuante.

Para entrar em uma conta, a janela sticky deve ser escolhida com folga em relação à duração real da sessão, e não no limite: se o trabalho típico leva 20 minutos e a janela é de 15, a queda acontece de qualquer forma no meio da tarefa. A verificação adicional costuma disparar justamente na virada da janela, se nesse momento o site recebe uma requisição de um novo endereço com o token ativo.

Como planejar a troca de endereço para não perder o login

O endereço deve ser trocado entre as sessões, e não dentro delas: saia da conta, troque o IP e entre de novo, em vez de trocar na hora. Se o site oferece verificação multifator, esteja preparado para que o primeiro login com o novo endereço a exija: é uma reação normal, não um bloqueio. Mantenha a coerência do contexto: país do IP, idioma da interface, fuso horário e, se for o caso, o país do número devem combinar entre si, senão nem um endereço estável evita uma nova verificação.

Para tarefas com login permanente em uma única conta, um endereço dedicado durante todo o período de trabalho é mais prático do que um canal com rotação por sessão: você não precisa ajustar a janela sticky à duração da operação. Como escolher o tipo de canal para cada tarefa está explicado no artigo proxies móveis versus residenciais, e a reputação de um endereço já entregue pode ser verificada pelo método do artigo como verificar a qualidade do proxy.

Perguntas frequentes

É possível desativar a rotação do endereço enquanto trabalho em uma conta?

Sim, para isso se usa o modo sticky ou um endereço dedicado: ambos mantêm um mesmo IP durante todo o período definido, em vez de trocar a cada requisição ou por um timeout curto.

Por que a sessão cai mesmo quando o endereço muda dentro da mesma cidade?

Coincidir a cidade não garante coincidir o ASN e a sub-rede: o servidor pode comparar justamente esses parâmetros, e não apenas a marca geográfica do país, e trata qualquer divergência como troca de dispositivo.

O que fazer se o login cair no meio de uma operação?

Faça o login de novo e, se o site oferecer, confirme a verificação adicional: é uma reação esperada à troca de endereço em um token ativo, não um sinal de bloqueio da conta.

Você encontra um canal com o tempo de retenção de endereço adequado (residencial, móvel ou dedicado) na seção de proxies.