Se você é proprietário de uma loja online, um profissional de marketing ou um especialista em tráfego, e sua conversão de tráfego móvel caiu repentinamente — o problema pode não estar nos criativos ou na página de destino. O problema está na captcha, que aparece para alguns usuários móveis simplesmente porque eles acessaram com um endereço IP de um operador de telefonia móvel. Vamos entender por que isso acontece, quantos compradores reais são perdidos e como verificar isso por conta própria em 15 minutos.
Por que os usuários móveis veem mais frequentemente a captcha: a razão está no CGNAT
A maioria dos operadores móveis — MTS, Beeline, MegaFon, Tele2 e seus equivalentes em outros países — utiliza a tecnologia CGNAT (Carrier-Grade NAT). Isso significa que milhares, às vezes dezenas de milhares, de assinantes reais estão "conectados" ao mesmo tempo por um único endereço IP externo. Para o seu site e para os sistemas de proteção contra bots (Cloudflare, reCAPTCHA, regras WAF próprias), isso parece que um único IP está fazendo um número anormalmente alto de solicitações em um curto período de tempo.
O sistema anti-bot não consegue distinguir "500 pessoas diferentes de uma área da cidade acessando o site pela internet móvel" de "um bot fazendo 500 solicitações por minuto". Portanto, a proteção é ativada, e todo o intervalo de IP recebe um nível elevado de suspeita — captcha, lentidão e, às vezes, até bloqueio total de acesso.
Adicione a isso que os endereços IP móveis são periodicamente reutilizados entre diferentes assinantes (o operador os atribui dinamicamente), e a reputação de um endereço específico pode ser "danificada" por um usuário anterior — por exemplo, se um parser ou bot de spam recentemente operou a partir desse mesmo IP. O próximo assinante que receber esse IP herdará a má reputação e receberá captcha, mesmo sem saber por quê.
Quantos compradores você está perdendo devido à captcha no móvel
De acordo com vários estudos de UX e conversão, cada verificação adicional no caminho do usuário (captcha, confirmação via SMS, "aguarde, verificando o navegador") reduz a conclusão da ação desejada em 15–40%. Em dispositivos móveis, esse efeito é amplificado: tela pequena, entrada de texto desconfortável com imagem distorcida, conexão instável — e parte dos usuários simplesmente fecha a aba.
Para uma loja online, isso significa perda direta de receita: o comprador adicionou um produto ao carrinho, passou para a finalização do pedido, e o sistema de proteção considerou seu tráfego suspeito exatamente porque ele acessou através de um operador móvel com um pool de IPs compartilhado. Ele não é um bot, não é um parser e não é um fraudador — é apenas uma pessoa comum que decidiu pagar o pedido pelo telefone no metrô ou no táxi.
Isso é especialmente doloroso em segmentos com alta participação de tráfego móvel: entrega de comida, marketplaces, ingressos, reservas de serviços. Se 60–70% dos seus pedidos vêm de dispositivos móveis, e parte desse tráfego é "cortada" pela captcha na entrada ou durante o pagamento — você está perdendo dinheiro de forma discreta, porque na análise isso aparece apenas como "abandonos na página de pagamento", sem a anotação "captcha é a culpada".
Quais sinais fazem os sistemas anti-bot exibirem captcha
Para entender por que exatamente seu site exibe captcha para compradores móveis, é útil saber em quais sinais os sistemas de proteção modernos reagem:
| Sinal | Como afeta os usuários móveis |
|---|---|
| Frequência de solicitações de um IP | CGNAT combina centenas de assinantes — o limite de ativação é ultrapassado sem bots |
| Reputação do IP (listas negras) | O endereço foi usado anteriormente por um spammer ou parser, a reputação é transferida para o novo assinante |
| Geolocalização vs fuso horário do dispositivo | Durante o roaming ou mudança de estação base, a discrepância provoca verificação |
| Ausência de histórico de cookies/sessões | Um novo usuário sem histórico de visitas automaticamente parece mais suspeito |
| Mudança abrupta de IP durante a sessão | Alternar entre estações base do operador muda o IP externo em tempo real |
Um ponto importante: esses sinais afetam igualmente tanto os compradores comuns quanto aqueles que testam anúncios ou gerenciam várias contas para negócios. Portanto, entender a lógica da proteção anti-bot é útil não apenas para os proprietários de sites, mas também para os afiliados que configuram campanhas no Facebook Ads e TikTok Ads e enfrentam verificações semelhantes nas plataformas de anúncios.
Como verificar seu site pelos olhos de um comprador móvel
A maneira mais confiável de saber se seus compradores reais veem a captcha é não adivinhar pela análise, mas reproduzir sua experiência. Para isso, você precisa acessar o site com um endereço IP semelhante ao que os usuários móveis realmente usam. Aqui está um plano passo a passo:
- Abra o site com um Wi-Fi comum e registre se a captcha aparece durante a finalização do pedido, autenticação ou ao acessar o site.
- Conecte um proxy móvel com o IP do operador da sua região-alvo — por exemplo, da faixa da MTS ou MegaFon, se a audiência principal for da Rússia.
- Repita o mesmo caminho do usuário: transição do anúncio, adição do produto ao carrinho, finalização do pedido, pagamento.
- Compare o resultado: se a captcha aparece apenas através do proxy móvel e não aparece através do Wi-Fi comum ou do IP do datacenter — o problema está exatamente nos intervalos de CGNAT dos operadores.
- Teste diferentes operadores e diferentes regiões — às vezes a captcha é acionada apenas para o IP de um operador específico, que tem um pool de endereços especialmente "sujo".
Para esse tipo de teste, os proxies móveis são os mais adequados — eles usam endereços IP reais de operadores de telefonia móvel, ou seja, você verá o site exatamente como um comprador real vê pelo telefone em uma rede móvel, e não através do Wi-Fi doméstico ou do IP do servidor do datacenter.
Ferramentas para teste: proxies e navegadores anti-detect
Para que o teste seja correto e repetível, é conveniente usar uma combinação de um navegador anti-detect e um proxy. Navegadores anti-detect — Dolphin Anty, AdsPower, Multilogin, GoLogin, Octo Browser — permitem criar perfis isolados de navegador com diferentes parâmetros de dispositivo, fuso horário e endereço IP. Isso é conveniente se você quiser testar o site imediatamente com vários "compradores virtuais" de diferentes regiões e operadores, sem a necessidade de limpar cookies e alterar configurações constantemente.
O algoritmo é simples: crie um novo perfil no Dolphin Anty ou AdsPower → nas configurações do perfil, indique o tipo de proxy SOCKS5 ou HTTP → insira o login, senha, host e porta do proxy móvel → escolha a região e o operador desejados → abra o perfil e acesse seu site, repetindo o caminho de um comprador real. Assim, em 15–20 minutos, você verifica 5–10 combinações de "região + operador" e vê onde exatamente a captcha aparece.
Para comparação, também vale a pena testar o site através de proxies residenciais — são IPs de usuários domésticos comuns, que em alguns casos também estão atrás de NAT, mas com padrões de bloqueio menos agressivos do que os dos operadores móveis. A diferença no comportamento da captcha entre IPs móveis e residenciais ajuda a entender melhor qual lógica anti-bot está sendo acionada no seu site.
| Tipo de proxy | O que imita | Quando usar para teste |
|---|---|---|
| Proxies móveis | IPs de operadores de telefonia móvel, CGNAT | Verificar a experiência de compradores pelo telefone em uma rede móvel |
| Proxies residenciais | IPs de provedores domésticos | Verificar a experiência de usuários com Wi-Fi doméstico |
| Proxies de datacenter | IPs de servidores | Grupo de controle — geralmente a captcha quase não aparece ou aparece por outra razão |
Checklist de diagnóstico da captcha no site
Antes de tirar conclusões, passe por um breve checklist — ele ajuda a distinguir o verdadeiro problema do CGNAT de outras razões para a aparição da captcha:
- A captcha aparece apenas com proxies móveis, mas não com residenciais e de datacenter — sinal do efeito CGNAT.
- A captcha aparece para todos os tipos de IP de forma semelhante — o problema provavelmente está nos gatilhos comportamentais (velocidade de cliques, ausência de movimento do mouse na versão desktop, padrões de navegação).
- A captcha aparece com mais frequência de um operador específico — verifique a reputação de seus intervalos de IP em serviços como AbuseIPDB ou no painel do seu WAF/CDN.
- A captcha aparece apenas ao finalizar o pedido, e não na página inicial — provavelmente, o problema está nas configurações de proteção do gateway de pagamento ou do sistema anti-fraude, e não na proteção geral do site.
- A captcha desaparece após uma nova solicitação em 1–2 minutos — um sinal clássico de rate-limit por IP, que é característico do CGNAT.
Como reduzir o número de captchas para compradores legítimos
Se o teste confirmou que o problema está nos intervalos de CGNAT móveis, existem várias etapas práticas que podem ser discutidas com o desenvolvedor ou a agência que gerencia o site:
- Revise os limites de rate-limit. Se o limite de solicitações de um IP por minuto for muito rígido, aumente-o para intervalos pertencentes a operadores móveis conhecidos.
- Use análise comportamental em vez de um filtro de IP puro. Serviços de proteção modernos (Cloudflare Bot Management, sistemas anti-fraude próprios) conseguem analisar o movimento do cursor, a velocidade de preenchimento de formulários e os padrões de toques na tela — isso é mais confiável do que apenas a frequência de solicitações de um IP.
- Adicione uma captcha "suave" em vez de uma rígida. invisible reCAPTCHA ou verificação em um clique reduzem a fricção para usuários reais, mantendo a proteção contra bots automáticos.
- Configure exceções por sessão e dispositivo. Se o usuário já passou pela verificação uma vez, não mostre a captcha novamente dentro da mesma sessão, mesmo que o IP tenha mudado devido à troca de estação base.
- Teste regularmente através de proxies móveis e residenciais após cada atualização das regras anti-fraude — isso permite monitorar se a situação piorou após mais uma "ajuste de segurança".
Essas etapas são especialmente importantes para projetos de e-commerce, onde o tráfego móvel representa uma grande parte dos pedidos. A perda de 5–10% de compradores na etapa de pagamento devido a verificações desnecessárias reflete diretamente na receita, e essas perdas raramente aparecem nos relatórios padrão de análise da web como uma causa separada de abandono.
Conclusão
A captcha no site nem sempre significa atividade de bots — muitas vezes é um efeito colateral do CGNAT dos operadores móveis, que faz com que milhares de compradores reais compartilhem um único endereço IP e sejam percebidos pelo sistema anti-bot como tráfego suspeito. Para entender a magnitude do problema em seu site, não é necessário adivinhar através de gráficos na análise — basta reproduzir o caminho do comprador através de um IP móvel real e comparar o resultado com uma conexão comum.
Se você deseja testar como exatamente seu site aparece para compradores de redes móveis de diferentes operadores e regiões, recomendamos experimentar proxies móveis — eles fornecem uma visão precisa do que o público real enfrenta e ajudam a encontrar rapidamente a causa de bloqueios excessivos antes que isso afete a receita.