Como funcionam os proxies móveis: rotação de IP e sessões
Por que o site ainda reconhece você depois de trocar o IP: do que é feita a saída móvel, por que a operadora usa CGN, os três tipos de "sessão", o que a rotação muda de fato e o que verificar antes de alugar.
Como funcionam os proxies móveis: rotação de IP e sessões
Você clica no link de troca de IP, a página de consulta de IP mostra outra região e a loja online continua cumprimentando você pelo nome e guardando o carrinho. Nada quebrou: mudou a saída para a rede, não a sessão do navegador. Aqui explicamos quais camadas participam, o que a rotação realmente faz e como testar uma saída móvel no seu próprio cliente. Se a dúvida é qual modo escolher, veja proxy rotativo e sessão sticky.
01O endereço mudou, mas o site ainda lembra de você
Cena típica. Você conectou o navegador a proxies móveis, abriu a página "qual é o meu IP" e anotou o endereço.
Você clicou no link de troca de IP, atualizou a página e o endereço mudou, às vezes até com outra cidade na base de geolocalização. Aí você entra na sua conta de uma loja online e continua logado, o carrinho está lá, as recomendações são as mesmas.
Para quem está começando, isso parece uma contradição: o endereço é novo, mas a identidade é a mesma. Na verdade, não há contradição, porque o IP de saída e a sessão do aplicativo vivem em camadas diferentes e quase não se conhecem.
Para parar de se confundir, vale a pena entender do que é feita a saída móvel e o que a rotação realmente muda.
02Do que é feita a saída móvel
Um proxy móvel encaminha as requisições por uma saída na rede celular. No modelo típico, o cliente se conecta a um gateway, e daí o tráfego passa por um modem com chip SIM ou outro dispositivo com conexão móvel. A implementação concreta varia de serviço para serviço. O cliente (navegador, script, aplicativo) se conecta ao gateway via HTTP(S) ou SOCKS5, o gateway repassa o tráfego ao modem, o modem entrega à operadora, e a operadora coloca os pacotes na internet já com o endereço dela.
Daí vem a primeira distinção, que muita gente perde.
A palavra "móvel" descreve a rede de saída, ou seja, de onde o site vê a sua conexão. As palavras HTTP e SOCKS5 descrevem o protocolo pelo qual você conversa com o gateway. São coisas independentes. Uma mesma saída móvel pode estar disponível via HTTP e SOCKS5; o endereço, a porta e o método de autenticação devem ser tirados das configurações da conexão específica. O protocolo de conexão não diz nada sobre o tipo de saída, e o tipo de saída não define o protocolo. A diferença também é prática. O SOCKS5 trabalha no nível das conexões TCP e pode fazer proxy não só de web; um proxy HTTP entende a estrutura das requisições, sabe fazer CONNECT para HTTPS, mas em estado puro é voltado ao tráfego web.
Com a mesma saída, as duas opções podem usar um único endereço público. Mas o site pode levar em conta outros sinais da requisição: o mesmo IP não torna as conexões totalmente indistinguíveis.
03Por que o IP pode ser compartilhado
O endereço que o site vê não está necessariamente reservado só ao seu dispositivo.
Para distribuir endereços IPv4 públicos entre assinantes, a operadora pode usar CGN (carrier-grade NAT), ou seja, a tradução de endereços feita pela operadora. Nesse caso, o endereço interno do assinante e o endereço público que o site vê são diferentes; um único endereço público pode atender vários assinantes. Para essa camada interna, a RFC 6598 reserva um bloco à parte, 100.64.0.0/10, que não é roteado na internet, então os sites nunca o veem. Aqui cabem duas ressalvas. Primeiro, cada operadora monta o esquema de NAT do seu jeito, e o tamanho dos pools, a ligação dos assinantes aos endereços e o tempo de vida das traduções variam, de modo que não existe um esquema único para todas as operadoras móveis. Segundo, do fato de o endereço ser compartilhado não decorre nem exclusividade nem anonimato.
Um único IP público pode estar em uso por muitos assinantes ao mesmo tempo, e o seu modem pode, no minuto seguinte, receber um endereço que acabou de ser de outra pessoa. Isso é uma característica natural das redes celulares, e não uma particularidade de um proxy específico.
Daí também decorre que a base de geolocalização e o ASN continuam sendo sinais indiretos. Eles mostram a qual operadora e mais ou menos a qual região o bloco pertence, mas não provam que o modem está numa cidade específica e não dizem nada sobre a qualidade do endereço. A reputação de um IP específico é verificada à parte, por exemplo em listas negras DNSBL.
04Três "sessões" diferentes
A palavra "sessão" nas conversas sobre proxies significa no mínimo três coisas diferentes, e a confusão entre elas gera a maior parte dos mal-entendidos.
1. Sessão do canal móvel, ou IP de saída. É o intervalo de tempo durante o qual o modem mantém o mesmo endereço público. Ele termina por seu comando (rotação), pelo timer do gateway ou sem a sua participação, quando a operadora refez a tradução ou o modem se reconectou à rede; a troca de estação base por si só não necessariamente muda o IP público. A esse nível está ligado o conceito de sticky session: o gateway tenta manter a saída escolhida para requisições com um mesmo identificador de sessão durante uma janela acordada. Isso não é a mesma coisa que a sessão da conexão móvel nem a autenticação no site. É importante entender de quem é essa promessa. O sticky continua sendo uma condição do serviço específico, que simplesmente não inicia a troca por conta própria. A operadora não dá nenhuma garantia nesse sentido, e uma troca forçada de endereço pela rede continua possível a qualquer momento. Quanto tempo o endereço aguenta sem comando depende da rede específica e do dia específico; não há constante aqui.
2. Sessão de conexão, ou seja, TCP e HTTP. Segundo a RFC 9293, uma conexão TCP é definida por um par de sockets, endereço e porta de cada lado. Se uma conexão já aberta perde o endereço anterior ou o mapeamento NAT, ela pode cair ou ficar travada até o timeout. Mas o gateway pode aplicar a rotação apenas às novas conexões, mantendo a rota antiga para as já abertas: o comportamento precisa ser verificado à parte.
Conexões HTTP longas e WebSocket dependem do transporte. Ao mesmo tempo, a conexão do cliente com o gateway e a conexão do gateway com o site são trechos diferentes: a perda da saída móvel não necessariamente fecha o primeiro deles na hora. Restaurar o transporte e restaurar a autenticação também exigem verificações diferentes.
3. Sessão do aplicativo, cookies e autenticação. Esse nível é gerenciado pelo site e pelo navegador. O servidor emite um cookie, o navegador o guarda e o devolve a cada requisição conforme regras de domínio, caminho, prazo e atributos, como descrito no guia de cookies da MDN. Nenhuma dessas regras menciona o endereço IP do cliente. A troca do endereço externo por si só não limpa cookies, localStorage nem cache. Se o site quiser reagir à troca de endereço, pedir novo login, mostrar um aviso ou limitar ações, isso será uma decisão da lógica do servidor. Essa reação não é consequência automática da rotação.
Agora a situação inicial se explica sem mágica: a rotação afetou o nível 1, talvez tenha derrubado algo no nível 2, e o nível 3 ficou intocado, porque o cookie está no navegador e continua sendo enviado como antes.
Esquema conceitual: a saída pela rede móvel e a sessão da aplicação são camadas distintas.
05O que acontece na rotação
O comando de troca de IP normalmente é implementado de uma de duas maneiras. Ou por timer, quando o gateway inicia a troca sozinho em um intervalo definido, ou por link ou chamada de API, quando é você que dispara. Tecnicamente, a troca se resume a reconectar o modem à rede da operadora. O modem encerra a sessão de dados e abre uma nova, a operadora emite uma nova tradução, e um endereço público diferente aparece para fora. Essa reconexão pode interromper o acesso temporariamente; a duração precisa ser verificada na conexão específica. Numa arquitetura com pool, a troca de saída pode ser feita de outra forma, sem reconectar o mesmo modem. Daí vêm algumas consequências que quem usa proxies móveis no trabalho deve ter em mente.
O novo endereço não precisa ser radicalmente diferente do antigo, porque o pool da operadora é finito, e após a reconexão o modem pode receber um endereço da mesma sub-rede, às vezes exatamente o mesmo de antes. Isso não é erro do proxy, pois o gateway fez o que pôde, e a distribuição dos endereços continua sendo área da operadora.
Pelo mesmo motivo, não faz sentido julgar a qualidade da rotação por ter mudado ou não o primeiro octeto. O comando pode até não dar resultado. O modem não se registrou na rede, o timeout da resposta da operadora expirou, houve uma queda breve de cobertura, e tudo isso termina sem novo endereço ou com ele aparecendo com atraso. Um código de cliente adequado verifica o endereço depois do comando, em vez de supor que ele mudou. As conexões antigas não são transferidas. Em alguns gateways, a nova rotação se aplica às novas conexões, e as já abertas terminam à parte; em outros, tudo cai ao mesmo tempo. Troca de endereço sem interrupção no nível TCP não existe, porque a conexão por definição está ligada aos endereços.
Se a rotação afetou a rota de um download ou WebSocket já aberto, o cliente pode precisar reconectar. Se a saída antiga foi mantida até o fim da operação, ela pode terminar sem interrupção.
O intervalo do timer continua sendo um parâmetro seu, e não uma propriedade da rede.
Separadamente, sobre DNS e IPv6. Se o cliente resolve nomes localmente e envia apenas TCP pelo proxy, o site vê o endereço móvel, mas as consultas DNS saem do seu endereço de casa, e com IPv6 acontece algo parecido, porque parte dos clientes e sistemas prefere a rota IPv6 fora do proxy, se estiver disponível.
Nenhum dos dois vazamentos depende da rotação, e ambos são verificados à parte.
06Onde a rede móvel é útil e onde a estabilidade importa mais
Os benefícios da saída móvel em cenários permitidos são suficientes, e não têm relação com contornar nada. Veja onde os proxies móveis fazem sentido.
Ver o próprio site pelos olhos de um assinante móvel. Com essa saída, é prático verificar a exibição regional, a segmentação geográfica e o comportamento da CDN nos seus próprios sites. No entanto, o IP móvel por si só não transforma um navegador de desktop em celular: o layout responsivo, o User-Agent e o comportamento do dispositivo são testados à parte.
Testar a resistência do cliente à troca de endereço. Se você desenvolve um aplicativo com conexões longas, a rotação oferece uma forma reproduzível de verificar como o cliente lida com a queda, se reconecta, se perde dados e se trava até o timeout. Aqui justamente são necessárias trocas controladas, e não estabilidade.
Depurar a lógica de autenticação do seu lado. É útil ver o que o seu site faz quando o IP muda dentro da sessão, ou seja, nada, um aviso ou um pedido de novo login. É um teste da sua própria lógica de servidor, não da de outro.
Também há os casos opostos, como exportações longas, uploads grandes, chamadas via WebRTC e sessões de API com estado e longa duração, em que a perda da conexão anterior pode exigir repetir a operação; a saída móvel, com sua instabilidade natural, não é a melhor escolha ali. Se a tarefa exige um único endereço por horas, é preciso ou um modo sem timer, sabendo que a operadora ainda pode intervir, ou outro tipo de saída.
E a regra geral é que proxies móveis não tornam você invisível, não criam uma nova identidade e não protegem contra verificações dos sites. Eles mudam uma coisa só: de qual endereço e por qual rede a conexão chega. Todo o resto fica com você e com as regras das plataformas que utiliza.
07O que muda e o que não muda na rotação
| Nível | Muda na rotação? | Comentário |
|---|---|---|
| IP público de saída | Sim, em geral | Pode coincidir com o anterior ou ficar na mesma sub-rede |
| ASN e região pela base de geolocalização | Às vezes | Sinais indiretos, dependem do pool da operadora |
| Conexões TCP abertas | Podem cair | Depende da manutenção da rota antiga e da implementação da rotação |
| Conexões HTTP longas e WebSocket | Dependem do transporte | Em caso de queda, pode ser necessária uma nova conexão |
| Cookies, localStorage, cache do navegador | Não | Ficam armazenados no cliente, não estão ligados ao IP |
| Autenticação no site | Não, a menos que o site decida o contrário | A reação é definida pela lógica do servidor |
| Fingerprint do navegador e do dispositivo | Não | Headers, fontes, canvas e afins não têm relação com o endereço |
| Consultas DNS locais e rota IPv6 | Não | Se saem fora do proxy, continuam sendo seus |
A tabela explica por que a loja continua cumprimentando você pelo nome. O endereço de rede e o estado do navegador mudam de forma independente; o servidor do aplicativo pode usar os dois sinais ao verificar a sessão.
08Checklist antes de alugar
Antes de alugar proxies móveis, o melhor é testá-los no cliente real e no seu próprio site ou num ambiente de teste ao qual você tem direito de se conectar. Em resumo, ponto por ponto.
- Tipo de rede de saída. Confirme que o endereço pertence mesmo a uma operadora móvel, e não a um data center com fachada de móvel. Uma consulta à página de verificação de IP e a olhada no ASN dão uma checagem mínima, mas lembre que é um sinal indireto.
- Modo de rotação. Por timer, por link ou API, e se dá para desligar o timer de vez. Verifique se o comando realmente troca o endereço e quantos segundos isso leva no seu caso.
- Manutenção do endereço durante a operação. Execute uma operação longa, como o upload de um arquivo ou uma série de requisições, e veja se o endereço chega ao fim sem comando. Repita algumas vezes, porque um único resultado não prova nada.
- Encerramento das conexões antigas. Abra uma conexão longa, troque o IP e registre o que aconteceu: queda imediata, travamento até o timeout ou continuação pelo endereço antigo. Qualquer variante é aceitável, mas é preciso conhecê-la antes.
- Latência e quedas. A disponibilidade básica e o tipo de anonimato aparecem num verificador de proxy, mas meça o tempo de resposta e a parcela de requisições com falha no seu próprio tráfego, no horário em que pretende trabalhar. Números alheios não ajudam aqui.
- DNS e IPv6 no cliente real. Verifique por onde saem as consultas DNS e se a rota IPv6 não contorna o proxy. Faça isso no navegador ou na biblioteca que você vai usar, e não num utilitário separado.
- Limites, tráfego e protocolos. Restrições de tráfego, de número de conexões simultâneas e de frequência de trocas, suporte a HTTP e SOCKS5, e UDP se precisar.
- Regras de uso. O que os termos do serviço e a legislação da sua jurisdição permitem e quais ações levam ao bloqueio da conta no provedor. Testar recursos de terceiros sem permissão não entra nesta lista.
Você pode passar por esta lista com qualquer serviço do catálogo de proxies móveis. O mobileproxy.space, por exemplo, oferece os três modos do artigo: troca de IP por link ou API, rotação automática a cada N minutos e sem rotação, com portas em HTTP e SOCKS5:
Proxies móveis em SIMs reais por país e operadora, pacotes de banda residencial, mais linhas de servidor e backconnect. Pague com cartão, SBP ou cripto.
09O que vale verificar primeiro
A rotação de IP muda o ponto de saída para a internet, e só ele.
As conexões podem cair se a rotação afetou a rota anterior delas; para novas conexões e para as já abertas, o comportamento do gateway pode diferir. Cookies, autenticação e fingerprint do navegador vivem no cliente e não dependem do endereço, a menos que o site decida reagir a ele.
O endereço público compartilhado continua sendo uma consequência normal do NAT da operadora, e não promete nem exclusividade nem anonimato. Se você mantiver esses três níveis separados, os proxies móveis deixam de ser um mistério: são uma forma de olhar para o seu site e as suas conexões pelos olhos de um assinante de rede celular, com todas as suas particularidades, como o endereço real da operadora, as reconexões e o pool limitado.
Vale escolhê-los para a tarefa em que essa característica é realmente necessária, e testá-los no seu próprio cliente antes de alugar, não depois.
10Perguntas frequentes
Por que o site não me deslogou quando o IP mudou?
Por que o IP continuou o mesmo depois da rotação?
O que é sessão sticky em proxies móveis?
As conexões abertas caem quando o IP muda?
Proxies móveis deixam você anônimo?
Artigos relacionados
Proxy no Python requests: configuração, autenticação e erros
Como configurar proxy no Python Requests, autenticar sem vazar senha, separar HTTP de CONNECT, tratar timeout, TLS e 407, e conferir SOCKS5 versus socks5h.
Proxies grátis: riscos e limites antes de usar
Proxy grátis é seguro? O que o dono do proxy vê com HTTP e HTTPS, os riscos para suas senhas, lista pública ou teste oficial e como testar sem se expor.
O que é proxy ISP e quando usar IP fixo
Proxy ISP explicado: de onde vem o IP, o que o ASN revela, por que IP estático não é o mesmo que sessão sticky residencial e como checar o produto antes de pagar.
