WAF bloqueia clientes móveis devido ao CGNAT: 6 verificações e como corrigir bloqueios

Se a conversão do tráfego móvel caiu repentinamente e o formulário de registro ou pagamento está retornando um erro 403 para clientes reais — provavelmente, não é um hacker, mas sim o seu próprio WAF. O firewall vê milhares de solicitações de um único endereço IP de um operador de telefonia móvel e interpreta isso como um DDoS ou brute force. Na verdade, por trás desse IP estão centenas ou milhares de pessoas comuns — essa é a tecnologia CGNAT. Vamos entender como detectar e corrigir isso, sem abrir uma brecha para ataques reais.

O que é CGNAT e por que isso cria um problema

CGNAT (Carrier-Grade NAT) é uma tecnologia que os operadores de telefonia móvel utilizam devido à escassez de endereços IPv4. Em vez de atribuir um IP público único a cada assinante, o operador "esconde" milhares de usuários atrás de um ou vários endereços compartilhados. Para o site, isso se apresenta da seguinte forma: de um único IP, o tráfego vem de centenas de pessoas diferentes ao mesmo tempo — diferentes dispositivos, diferentes navegadores, diferentes comportamentos, mas o mesmo endereço externo.

Para um servidor web comum, isso não é um problema — ele simplesmente processa as solicitações. Mas para sistemas de proteção que contam as solicitações em uma unidade de tempo de um único IP, isso parece uma anomalia. Imagine: em um minuto, de um endereço, chegam 200 solicitações para a página de login. Para o WAF, isso é um padrão clássico de brute force ou scraping. Na verdade, podem ser 150 clientes reais de um operador de telefonia móvel na sua região que simplesmente abriram o site ao mesmo tempo após uma campanha publicitária ou publicação nas redes sociais.

O problema se torna ainda mais agudo em países com alta densidade de internet móvel — os operadores agrupam um enorme número de assinantes sob um número mínimo de IPs externos. É por isso que testar o comportamento do site deve ser feito não a partir de um IP de datacenter comum, mas sim a partir de proxies móveis, que realmente passam pela infraestrutura CGNAT do operador — só assim é possível reproduzir a mesma imagem que o WAF vê em usuários reais.

Por que o WAF vê o CGNAT como uma ameaça

A maioria das soluções WAF — Cloudflare, AWS WAF, Imperva, módulos integrados Nginx/ModSecurity — utiliza rate-limiting por endereço IP como mecanismo básico de proteção contra bots e DDoS. A lógica é simples: se de um único IP há mais de N solicitações em T segundos — bloqueamos ou mostramos um captcha. Essa regra funciona bem para ataques clássicos de um único dispositivo, mas quebra completamente no tráfego CGNAT.

Existem vários cenários típicos onde isso falha:

• Rate-limiting por IP. O limite de "100 solicitações por minuto de um único IP" é normal para tráfego de datacenter, mas catastrófico para uma região móvel com um milhão de assinantes sob um único endereço.
• Scoring comportamental. Se o sistema acumula "reputação" de IP com base no histórico de solicitações, um único usuário "ruim" sob CGNAT pode arruinar a reputação do endereço para milhares de clientes honestos subsequentes.
• Heurística geográfica. O WAF às vezes marca um IP como suspeito se vê saltos bruscos de atividade, que não são típicos de um "usuário comum" — e o comportamento do endereço CGNAT é exatamente esse: picos de carga durante as horas de atividade do público.
• Bloqueio por ASN do operador. Algumas regras do WAF bloqueiam faixas inteiras de ASN de operadores móveis, se anteriormente houve ataques dessas faixas — todos os clientes do operador no país são afetados.

Resultado: quanto mais rígido o WAF estiver configurado "de fábrica", maior a chance de que ele esteja bloqueando não bots, mas sim sua real audiência móvel — especialmente se o negócio estiver voltado para países com internet móvel desenvolvida e alta proporção de tráfego CGNAT.

Quais são os riscos para os negócios: clientes e dinheiro perdidos

O problema dos bloqueios CGNAT raramente é visível na análise padrão. O Google Analytics e o Yandex.Metrica simplesmente não registram aqueles que receberam um erro 403 no nível do WAF — essas visitas muitas vezes nem chegam ao contador. Como resultado, o profissional de marketing vê uma queda na conversão, mas não entende a razão e começa a otimizar criativos e páginas de destino, embora o problema esteja na infraestrutura.

Consequências reais para diferentes segmentos de negócios:

• E-commerce. Um comprador da internet móvel não consegue concluir a compra — o formulário de pagamento retorna um erro, o carrinho é perdido. Perdas diretas na receita, especialmente notáveis após o lançamento de anúncios no TikTok Ads ou Facebook Ads, onde o tráfego principal é móvel.
• SaaS e registros. O usuário tenta se registrar ou entrar na conta, recebe captcha a cada passo ou bloqueio — vai para um concorrente.
• Conteúdo e publicidade. O tráfego publicitário de dispositivos móveis "desconecta-se" em massa na landing page, o orçamento publicitário é gasto, mas não há conversões — os algoritmos das plataformas de anúncios interpretam isso como baixa qualidade da audiência e aumentam o custo por clique.
• Suporte ao cliente. Aumenta o número de reclamações "seu site não abre", "não consigo me registrar" — e o suporte técnico não vê o problema, porque acessa do desktop através do Wi-Fi do escritório sem CGNAT.

O mais desagradável é que tais bloqueios são difíceis de diagnosticar post-fato, porque o log do WAF mostra um único IP "suspeito" com um enorme número de solicitações, e o administrador vê nisso uma confirmação da correção do bloqueio, e não um falso positivo.

6 verificações com IPs móveis para encontrar o problema

Para entender se o seu WAF está bloqueando clientes móveis honestos, você precisa reproduzir as condições reais do CGNAT — ou seja, testar o site a partir de IPs móveis reais de diferentes operadores e regiões. Aqui está uma lista prática de 6 verificações.

Verificação 1: Acesso em massa de um único IP móvel

Configure várias sessões paralelas através do mesmo IP móvel (isso é natural para proxies com CGNAT do operador) e execute 50-100 ações comuns — abrir páginas, adicionar ao carrinho, navegar entre seções. Se após um determinado limite começar a aparecer captcha ou 403 — esse é o primeiro sinal de problema.

Verificação 2: Mudança de User-Agent com um único IP

Um endereço CGNAT atende a diferentes dispositivos — iPhone, Android, diferentes navegadores. Execute solicitações com diferentes strings de User-Agent através de um único IP e verifique se a regra do WAF "variabilidade suspeita de dispositivos de um único endereço" é ativada.

Verificação 3: Teste em formulários críticos

Passe pelo caminho completo do cliente — registro, login, finalização de pedido, pagamento — exatamente através do IP móvel do operador. Muitas vezes, o WAF está configurado de forma mais agressiva em formulários com entrada de dados (login, pagamento), onde o risco de brute force é maior, e este é o primeiro lugar onde clientes reais são perdidos.

Verificação 4: Teste com diferentes operadores e regiões

O comportamento do CGNAT varia entre diferentes operadores e países — em alguns lugares, por um único IP estão ocultos 50 assinantes, em outros 5000. Teste o site com IPs móveis de vários operadores em geos-chave para o negócio, para entender se há especificidades regionais nos bloqueios.

Verificação 5: Análise da resposta do servidor por códigos e cabeçalhos

Registre não apenas o fato do bloqueio, mas o código HTTP exato e os cabeçalhos da resposta (por exemplo, cf-mitigated: challenge no Cloudflare). Isso ajudará a entender qual mecanismo de proteção foi acionado — rate-limit, detecção de bot ou regra geográfica.

Verificação 6: Monitoramento de longo prazo da reputação do IP

Repita o teste a partir do mesmo IP móvel ao longo de vários dias. Se o acesso piorar ao longo do tempo sem razões visíveis da sua parte — significa que o sistema de scoring acumulativo "está arruinando" a reputação do endereço devido à atividade de outros assinantes sob o mesmo CGNAT, e isso é um problema sistêmico, não pontual.

Como configurar o WAF para não bloquear clientes honestos

Após o diagnóstico, é necessário ajustar as regras de proteção para não perder o nível de segurança, mas parar de bloquear usuários móveis reais. Aqui estão as principais abordagens.

Problema	Solução no WAF
Rate-limit rígido por IP	Aumentar o limite para ASN conhecidos de operadores móveis ou mudar para limite por sessão/cookie em vez de IP puro
Scoring acumulativo da reputação do IP	Reduzir o tempo de "memória" da reputação para faixas CGNAT, adicionar whitelist para ASN conhecidos de operadores
Bloqueio por geo/ASN inteiro	Substituir o bloqueio total por um desafio suave (verificação JS) em vez de 403
Captcha rígido em formulários de login	Ativar captcha de forma adaptativa — apenas quando houver sinais reais de brute force (múltiplas tentativas malsucedidas de uma conta), e não apenas pelo fato de ser um IP CGNAT

Uma boa prática é manter uma lista própria de faixas conhecidas de operadores móveis em suas geos-chave e aplicar regras separadas, mais suaves, em comparação com o tráfego de internet comum. Isso requer tempo para configuração, mas reduz drasticamente o número de bloqueios falsos.

Ferramentas para testes com proxies móveis

Para auditorias regulares da proteção do site, é conveniente usar uma combinação de navegador anti-detect e proxies móveis. Navegadores anti-detect (Dolphin Anty, AdsPower, Multilogin, GoLogin, Octo Browser) permitem criar perfis isolados com diferentes impressões de dispositivos, enquanto os proxies móveis fornecem tráfego CGNAT real dos operadores.

Abordagem passo a passo para testes:

1. Crie vários perfis no navegador anti-detect com diferentes parâmetros de dispositivo (diferente User-Agent, resolução de tela, fuso horário).
2. Conecte a cada perfil proxies móveis da região e operador desejados — isso proporcionará um comportamento real do CGNAT.
3. Realize os principais cenários de usuário: registro, login, adição ao carrinho, pagamento.
4. Registre todos os casos de captcha, 403 e outros bloqueios, e compare com as configurações do WAF.
5. Repita o teste com proxies residenciais para comparação — isso ajudará a entender se o problema é específico para o tráfego móvel.

Para testes paralelos em diferentes geos, também são úteis proxies residenciais — eles ajudam a avaliar quão agressivo o WAF é para o tráfego doméstico comum e para o CGNAT móvel. Se você planeja testes de carga a partir da infraestrutura do servidor sem vinculação a um operador, para verificações de controle sem o efeito CGNAT, você pode conectar proxies de datacenter — eles fornecerão uma linha de base limpa sem distorções típicas das redes móveis.

Essa abordagem abrangente — IPs móveis, residenciais e de datacenter em um único teste — fornece uma imagem completa: você vê exatamente onde a proteção é acionada e para qual tipo de tráfego, e não fica adivinhando com base em indícios indiretos nos logs.

Perguntas frequentes

É possível excluir completamente as faixas CGNAT das regras do WAF?
Não é recomendado — isso reduzirá a proteção contra ataques reais, que também podem ocorrer através de redes móveis. O mais correto é suavizar os limites e mudar para um desafio suave em vez de um bloqueio rígido.

Com que frequência esses testes devem ser realizados?
No mínimo uma vez por mês e sempre após qualquer alteração nas regras do WAF ou lançamento de uma nova campanha publicitária para o público móvel.

Isso afeta o SEO?
Sim — se bots de busca ou usuários reais de dispositivos móveis recebem 403, isso aumenta a taxa de rejeição e pode impactar negativamente nas métricas de comportamento de classificação.

Conclusão

CGNAT não é uma ameaça, mas uma característica da internet móvel, com a qual praticamente qualquer negócio com uma audiência móvel se depara. O problema não está na tecnologia em si, mas no fato de que as configurações padrão do WAF não consideram sua especificidade e penalizam usuários honestos por comportamentos típicos de redes móveis comuns. As seis verificações deste artigo ajudarão a diagnosticar rapidamente se você está perdendo clientes devido a bloqueios falsos, e o ajuste pontual das regras do WAF pode recuperar a conversão sem diminuir o nível de proteção.

Se você planeja testar regularmente o comportamento do site e dos funis de vendas como os veem os clientes móveis reais, recomendamos o uso de proxies móveis — eles fornecem tráfego CGNAT real dos operadores e permitem identificar bloqueios falsos antes que seus clientes os encontrem.