Voltar ao blog

Um IP, Milhares de Pessoas: Como o CGNAT Quebra o Banimento por IP

A proteção de sites há décadas considerava que um IP era um único respondente. O CGNAT quebrou essa suposição: por trás do endereço do operador móvel estão centenas de assinantes ativos, e banir esse endereço se tornou uma operação paga. A Cloudflare digitalizou o efeito — e os números se mostraram contraintuitivos: o limite de taxa é três vezes mais frequente, e aprenderam a distinguir CGNAT de pools de proxy com um modelo separado.

📅16 de agosto de 2026
Um IP, Milhares de Pessoas: Como o CGNAT Quebra o Banimento por IP
```html

Um ano e meio de proteção de sites foi baseado na suposição: um endereço IP é uma entidade que pode ser punida. Engenheiros da Cloudflare mediram o quão quebrada essa suposição está e publicaram os números. O principal deles é inesperado: endereços que são compartilhados por centenas de pessoas reais recebem limitações de velocidade três vezes mais frequentemente do que os normais. Vamos analisar o que é CGNAT, por que proxies móveis são mais resilientes do que os outros — e por que o "efeito multidão" deixou de ser uma indulgência.

Por que "simplesmente banir um IP" deixou de ser uma solução barata

Qualquer proteção contra automação — lista negra, limite de taxa, detector de anomalias — parte do pressuposto de que há um respondente claro por trás do endereço. Se você bloqueia o endereço, pune o infrator. O custo do erro é considerado zero: bem, você não deixou passar um bot.

Essa aritmética é válida até o momento em que realmente há um único usuário por endereço. Um IP de data center é assim: um endereço — uma entidade alugada, o banimento não custa nada para o site. Com um provedor doméstico — uma única residência, também quase nada. Mas com um operador móvel, um único endereço público pode atender a um bairro inteiro da cidade. E lá, o banimento de repente se torna uma operação custosa: junto com o scraper, o site desliga centenas de clientes reais que não cometeram nenhuma infração.

É essa assimetria de custo — e não a "magia dos IPs móveis" — que determina quem é banido severamente e quem é poupado. E isso tem um nome técnico específico.

O que é CGNAT e por que é total entre os operadores

CGNAT (Carrier-Grade NAT, também conhecido como LSN — Large Scale NAT) é a tradução de endereços em nível de operador, e não do roteador doméstico. Formalmente, a base está documentada na RFC 6598 (abril de 2012): para as necessidades dos tradutores de operadores, foi reservado o intervalo 100.64.0.0/10 — 4.194.304 endereços que não são roteáveis na rede global e não devem cruzar a fronteira da rede do provedor.

A motivação no texto da RFC é clara: o espaço de endereços IPv4 está quase esgotado, mas os provedores devem suportar o crescimento dos clientes IPv4 até que o IPv6 seja totalmente implementado. O bloco /10 foi escolhido como o menor tamanho que permite implementar CGN regionalmente, sem construir tradutores aninhados.

Os operadores móveis enfrentam a escassez de endereços de forma mais aguda: há milhões de assinantes e apenas dezenas de milhares de IPv4 públicos. Portanto, CGNAT não é uma opção, mas a norma por padrão. Um único endereço público atende a centenas, e em horários de pico, até milhares de sessões, e o endereço do assinante muda constantemente — ao alternar entre torres, ao reconectar sessões, ao gerenciar largura de banda.

Daí vem todo o valor prático dos proxies móveis: você não obtém um IP "limpo", você obtém um endereço que o site não pode desligar sem causar danos colaterais.

O que exatamente a Cloudflare mediu

No estudo "One IP address, many users: detecting CGNAT to reduce collateral effects" (Vasilis Giotsas e Marwan Fayed, publicado em 29 de outubro de 2025, atualizado em 15 de julho de 2026), a Cloudflare resolve o problema inverso: aprender a distinguir endereços sob a tradução do operador, para aplicar medidas mais suaves a eles.

A metodologia foi reunida a partir de várias fontes independentes:

  • Traceroutes distribuídos de mais de 9000 nós do RIPE Atlas — para capturar endereços do intervalo 100.64.0.0/10 ao longo do caminho;
  • Registros WHOIS e PTR — busca de marcadores cgnat, cgn, lsn em nomes e descrições;
  • Catálogos públicos de anonimização — para coletar endereços de VPN e proxies;
  • Modelo XGBoost com sinais de clientes, comportamento de nível de transporte, volume de tráfego e diversidade de direções, com agregação tanto por IP individual quanto por sub-rede /24.

Tamanho da amostra de treinamento: 200 mil endereços CGNAT, 180 mil endereços de VPN e proxies, 900 mil endereços normais, divisão 70/30, validação cruzada de dez vezes. A qualidade declarada — precisão 0,98, F1 ponderado 0,97, perda logarítmica 0,04, macro-AUC 0,9946.

Um detalhe separado, sobre o qual pouco se fala na indústria: a proporção de user-agents em relação ao número de endereços é significativamente maior na África do que em outras regiões. A distribuição histórica de grandes blocos de IPv4 foi herdada pela América do Norte e Europa há décadas — e hoje isso resulta em usuários de regiões em desenvolvimento sendo mais frequentemente alvo de punições coletivas. A Cloudflare chama isso de viés socioeconômico.

O número principal: limite de taxa três vezes mais frequente

O resultado chave do estudo soa contra-intuitivo para todos que estão acostumados a considerar o IP móvel "intocável": usuários sob CGNAT enfrentam limitações de velocidade três vezes mais frequentemente do que usuários fora do CGNAT.

Não há contradição aqui — há uma divisão de medidas de custo. O banimento severo de um endereço é caro, pois afeta assinantes reais. Já o limite de taxa, desafios e CAPTCHA são baratos e reversíveis. Portanto, a proteção não desliga esse endereço, ela o estrangula. Além disso, o próprio mecanismo é acionado com mais frequência por uma razão aritmética: no endereço compartilhado, o tráfego de muitas pessoas independentes se soma, e os limites são alcançados mais rapidamente.

Um segundo par de números explica por que os sites estão dispostos a tolerar tais endereços. A proporção de bots em endereços CGNAT: mediana de 4,8% contra 4,7% dos outros — ou seja, em termos de mediana, a diferença é praticamente inexistente. Mas em média, a situação muda: 7% para CGNAT contra 13,1% para não-CGNAT. Isso se lê assim: entre os endereços normais, há uma longa cauda quase totalmente automatizada — um intervalo típico de data center, onde não há pessoas reais, e isso puxa a média para cima. Sob a tradução do operador, tal cauda não pode existir: sempre há assinantes reais que diluem qualquer automação.

Para o praticante, a conclusão é direta: o proxy móvel é adquirido não pela velocidade, mas pela resiliência. A largura de banda por endereço provavelmente será pior do que a de um data center — mas o endereço não se esgota para sempre após o primeiro erro.

Más notícias: CGNAT e proxies aprenderam a se distinguir

A tentadora conclusão "já que há muitas pessoas por trás de um endereço comum, vou me passar por um endereço comum" se quebra na formulação do problema no próprio estudo. Observe a composição da amostra: endereços CGNAT e endereços VPN/proxy são duas classes diferentes, e o modelo foi treinado para distingui-los, e não para agrupá-los em uma única cesta de "muitos usuários por um IP".

Elas se diferenciam por características que o locatário do endereço não controla:

  • Topologia. A tradução do operador é visível na rota e nos registros de serviço — pelo intervalo 100.64.0.0/10, pelos registros PTR e WHOIS.
  • Diversidade de direções. Um verdadeiro bairro da cidade se conecta a milhares de serviços diferentes; um nó para scraping se conecta a dezenas, muitas vezes a apenas um.
  • Perfil por sub-rede. A agregação por /24 mostra se o bloco de endereços vizinho se comporta como um endereço de assinante ou como um pool alugado.
  • Sinais de cliente. O conjunto de dispositivos por trás de um endereço comum deve parecer uma população real, e não como o mesmo stack replicado cem vezes.

Além disso, isso não é exclusividade da Cloudflare: fornecedores de inteligência de IP há muito oferecem não um sinal binário "proxy ou não", mas uma avaliação numérica — e a distinção entre "endereço de assinante comum" e "pool alugado" já está embutida nela.

Três conclusões práticas

  1. Reduza a carga no endereço, em vez de aumentar a paralelidade. Como um endereço comum está, por definição, mais próximo do limite de taxa, a estratégia de "extrair o máximo de RPS de um único IP" falha mais rapidamente. Espalhe a tarefa ao longo do tempo e distribua-a entre endereços, e não entre fluxos dentro de um único.
  2. Proteja a sessão. A resiliência do endereço é um recurso que você perde ao mudar de IP de forma agressiva: cada novo endereço passa novamente pela verificação de confiança. Para tarefas com autenticação e carrinho, uma sessão pegajosa quase sempre é mais vantajosa do que a rotação — onde está a linha, foi discutido no guia sobre sessões pegajosas.
  3. Conte não os endereços, mas as respostas bem-sucedidas. O pool de data center é mais barato por endereço e quase sempre mais caro por solicitação bem-sucedida onde há uma proteção séria. Comparar tipos faz sentido apenas pelo preço do resultado: endereços residenciais e móveis se pagam exatamente onde os endereços de data center não chegam à resposta.

Onde o "efeito multidão" não ajuda de forma alguma

É importante não transferir a lógica além do ponto em que ela funciona. A proteção contra punições coletivas atua apenas no nível do endereço de rede. Assim que a plataforma passa a outros identificadores, a vantagem desaparece:

  • Banimento de conta. Se a ação está vinculada a uma conta, a qualidade do IP não tem relação com a decisão.
  • Impressão digital do dispositivo e do navegador. A consistência do stack é verificada independentemente do endereço — e geralmente se desfaz antes que o filtro de IP seja acionado.
  • Vinculação de contas. As plataformas buscam interseções por sub-redes e por coincidências comportamentais, e não apenas pelo endereço exato.

Um fator separado de 2026 — a oferta. Em um mês, o mercado sofreu dois golpes nas fontes de endereços residenciais: em julho, a LG anunciou a proibição de SDK de proxy, descobrindo que cerca de 42% dos aplicativos em sua loja estavam envolvendo a TV em uma rede proxy, e em 3 de agosto de 2026, a Samsung impôs uma proibição de plataforma sobre SDK de proxy residencial e já restringiu o registro de novos aplicativos com essa funcionalidade. A descoberta foi relatada por Harrison Sand da norueguesa Mnemonic; aplicativos individuais relataram instalações em centenas de milhões de televisores. Uma análise detalhada da primeira onda está no material sobre a proibição de SDK de proxy em TVs LG. Menos fontes de IPs residenciais — maior preço, e mais evidente a diferença entre um endereço barato e um endereço que realmente chega à resposta.

Conclusão

CGNAT quebrou a suposição mais básica da proteção na web — "um endereço é igual a um respondente" — e a proteção reconheceu e digitalizou isso. Mas o reconhecimento não resultou em anistia, mas em uma reestruturação das medidas: endereços sob a tradução do operador são desligados menos frequentemente para sempre e são estrangulados três vezes mais frequentemente com limites, e sua distinção dos pools de proxy foi transformada em uma tarefa separada de classificação.

O significado prático para quem trabalha através de proxies é simples: o tipo de endereço não determina "se você passará ou não", mas sim qual o custo que o site pode usar para parar você. Construa seu trabalho em torno de medidas suaves — ritmo moderado, sessões longas, cálculo honesto do custo de uma solicitação bem-sucedida — e escolha o tipo de IP com base no custo do erro, e não no custo do gigabyte.

```