Por que seu número de WhatsApp é banido
(8 sinais técnicos que a Meta usa)

Esses sinais não são segredo de Estado. A Meta documenta parte deles na FAQ pública sobre banimento, e a comunidade de operadores complementa o resto através de engenharia reversa observacional. Rodando 312 instâncias em produção há mais de um ano, a gente conseguiu mapear o que dispara cada um e como prevenir antes de virar incidente.

Este artigo é o resultado dessa observação. Cada sinal vem com explicação técnica de como a Meta detecta, exemplo prático do que dispara, e o que fazer pra reduzir o risco a quase zero. Sem promessa milagrosa, banimento nunca chega a 0% absoluto, mas dá pra cair de uma média de 12% pra menos de 1% com setup correto.

Sinal 1, Velocidade inicial de envio

O sinal mais óbvio e o mais negligenciado. Conta nova de WhatsApp tem padrão de uso que cresce devagar: dia 1, talvez 5-20 mensagens; dia 7, talvez 50-100; mês 1, talvez 200-500. É a curva natural de qualquer humano configurando um número novo.

Quando você instala um número novo em automação e dispara 1.000 mensagens nas primeiras 24 horas, está apertando um botão vermelho gigante na infraestrutura da Meta. Não importa que o conteúdo seja inofensivo, que o número esteja verificado, ou que você tenha autorização do destinatário. O volume inicial sozinho dispara revisão automática, e a maioria das contas nesse cenário é banida em 24-72h.

Como prevenir: warmup phased obrigatório. Comece com 20 mensagens/dia na primeira semana. Suba pra 50 na segunda. 100 na terceira. 200 na quarta. Só depois de 30 dias considere passar de 500/dia. Esse é o padrão que a gente roda em produção e tem 0,3% de ban rate. Detalhamos a curva exata aqui.

Sinal 2, IP de origem suspeito

Cada conexão WebSocket do WhatsApp Web sai de um endereço IP. A Meta inspeciona esse IP em duas dimensões: (1) é IP residencial ou data center? e (2) já vi muitas contas saindo desse mesmo IP recentemente?

IP de data center (AWS, Google Cloud, DigitalOcean, Hetzner) é flag instantâneo: humanos não acessam WhatsApp pelo IP do EC2. IP residencial compartilhado por múltiplas contas (proxy pool genérico) é flag igualmente forte, quando a Meta vê 50 contas saindo do mesmo IP residencial em 24h, sabe que é serviço de proxy reciclando endereços.

Como prevenir: IP residencial estática (ISP) dedicada por instância. Cada número precisa ter sua própria IP, exclusiva enquanto a instância existir, nenhum outro cliente usa em paralelo. Não é caro: ISP proxy custa cerca de R$ 20-30/mês por IP em provedores como Bright Data, IPRoyal ou Smartproxy. Dividido em qualquer plano de WhatsApp em escala, é margem irrelevante. Catcher provisiona automaticamente alinhada à região do DDD do número quando há inventário (em DDDs de baixa densidade, usa adjacente da mesma macrorregião como fallback).

Importante: ISP proxies são tratadas como residenciais pelas listas de reputação que a Meta consulta, mas a máquina que serve o IP fica em datacenter do provedor. É melhor que IP de datacenter (que é flag instantâneo) e que pool compartilhado, mas é pior que 4G móvel real. Pra grande maioria das operações WhatsApp não-oficial, ISP dedicada é o ponto certo de custo-benefício. E lembre: IP é só uma das 10 camadas, não é bala de prata sozinha.

Sinal 3, Fingerprint do dispositivo

Quando você abre o WhatsApp Web no celular, o cliente reporta uma série de metadados: modelo do device (iPhone 14 Pro, Samsung Galaxy S23, etc.), versão do sistema operacional, versão do app WhatsApp, fuso horário, idioma, MCC/MNC (mobile country code/network code). Junto, esses metadados formam um fingerprint.

O problema: bibliotecas open source de WhatsApp Web tradicionais reportam fingerprint genérico, geralmente "WhatsApp Web Desktop" com timezone UTC, MCC zerado, e versão de app desatualizada. Esse padrão é incompatível com humano em SP rodando WhatsApp em iPhone 14 com timezone GMT-3, MCC 724 (Brasil), MNC 5 (Claro), versão de app atualizada na semana passada.

Quando o fingerprint não bate com o IP de origem (IP brasileiro mas device reportado como genérico desktop), a Meta marca como anomalia. Várias anomalias dessas em sequência viram ban.

Como prevenir: fingerprint TLS coerente com browser real (navegador inteiro, não só User-Agent string). A Catcher mantém um pool uTLS validado bytewise contra Safari 17.4 e Chrome 147 (Mac/Windows), cada nova instância recebe um profile sticky no pareamento e fica nele pelo lifetime. TLS handshake, User-Agent, sec-ch-ua-platform e DeviceProps todos coerentes, porque qualquer divergência cruzada entre essas 4 dimensões é red flag instantâneo.

Sinal 4, Padrão temporal de envio

Humanos não enviam mensagens com timing constante. Há gaps naturais: pausa pra digitar, pausa pra pensar, pausa pra atender outra coisa. Bot que dispara 1 mensagem por segundo, 3.600 por hora, em ritmo perfeitamente cadenciado, é detectável só pela regularidade.

A Meta calcula a entropia temporal das suas mensagens, basicamente, quão "aleatória" é a distribuição. Entropia muito baixa (envios cadenciados) ou muito alta (rajadas em milissegundos seguidas de horas em silêncio) ambas levantam suspeita. O ideal é a entropia mediana, que é o que humano produz naturalmente.

Como prevenir: intervalos randomizados entre envios. A Catcher usa jitter natural (gap mínimo de 1.5-3s entre mensagens, com ruído gaussiano) e auto-pause em sinais de rate-limit com backoff exponencial até hard-pause após 4 throttles consecutivos. Você pode implementar parecido em qualquer biblioteca: nunca sleep(1), sempre sleep(random.uniform(2, 8)).

Sinal 5, Resposta a "indicador de digitação"

Quando você manda mensagem pra alguém, o WhatsApp espera que a outra ponta veja o "digitando..." aparecer antes da mensagem chegar. É um sinal social: humano abre conversa, lê o que a pessoa mandou, começa a digitar (indicador aparece), eventualmente envia.

Bot que pula essa etapa (manda direto sem nunca acionar typing indicator) destoa do padrão. Não é fatal sozinho, mas combinado com volume alto vira sinal forte. A Meta interpreta como "essa conta nunca dá feedback social, só dispara mensagens".

Como prevenir: antes de enviar, simule o typing indicator por 1-3 segundos. A Catcher chama isso de "humanize" e faz automaticamente quando a flag está ativa. Implementação manual: o protocolo WhatsApp Web tem um payload de presence "composing", envie por 1.5s antes do payload de mensagem.

Sinal 6, Taxa de leitura antes de resposta

Humano que recebe mensagem geralmente lê (gera read receipt) antes de responder. O timing dessa leitura também tem padrão: alguns segundos de gap entre receber e ler, depois mais alguns segundos antes da resposta começar a sair.

Bot que responde sem nunca ter mandado read receipt antes, porque está processando o webhook server-side e respondendo diretamente, está pulando dois passos sociais (read + typing). Conta com 100% das respostas nesse padrão é detectada rapidamente.

Como prevenir: antes de responder, mande explicitamente o "mark as read" no protocolo. Espere 2-5 segundos. Mande o typing indicator por 1-3 segundos. Só então envie a resposta. Sequência: read receipt → typing indicator → message. A Catcher faz isso automaticamente quando humanize está ativo.

Sinal 7, Conteúdo repetitivo entre destinatários

O sinal mais forte de spam: mesma mensagem (ou variação ínfima) enviada pra centenas ou milhares de destinatários em janela curta. A Meta usa hashing semântico, não basta trocar uma palavra ou adicionar emoji aleatório, ela detecta a similaridade estrutural mesmo com variações superficiais.

Esse sinal escala: quanto mais destinatários receberem variações da mesma mensagem em pouco tempo, maior o multiplicador no score de risco. Disparar 50 mensagens "Olá! Tudo bem? Confira nossa promoção em [link]" nas primeiras 2 horas após gerar QR é praticamente garantia de ban.

Como prevenir: variação genuína de mensagem (não só substituição de variáveis) + distribuição temporal (nunca rajada). Use templates com pelo menos 5 variantes estruturalmente diferentes, randomize ordem de elementos, varie o cumprimento ("oi" / "olá" / "boa tarde" / "tudo bem?"). E ainda assim, distribua o disparo ao longo de horas, não minutos.

Sinal 8, Reports de destinatário

O sinal mais punitivo. Quando alguém recebe sua mensagem e clica em "Reportar spam" no WhatsApp, esse report vai pra um sistema centralizado da Meta. Threshold conhecido pela observação: 5 reports em 30 dias tipicamente dispara revisão automática; 10 reports resulta em ban quase certo, independente de qualquer outro sinal estar limpo.

Esse sinal é o que torna comprar lista de contatos uma estratégia suicida, pessoas que não pediram pra receber sua mensagem reportam em ritmo proporcional ao volume disparado. 1% de taxa de report em 1.000 mensagens = 10 reports = ban.

Como prevenir: só envie pra contatos que opt-in explicitamente. Inclua opção fácil de descadastro no rodapé. Monitore taxa de bloqueio (quando o destinatário bloqueia o número), se passar de 0.5%, pause campanha imediatamente e investigue. A Catcher emite webhook quando um número é bloqueado, então você consegue reagir em tempo real.

Como tudo isso combina

A Meta não usa esses sinais em isolamento. Ela calcula um score combinado, e bater em apenas um geralmente é tolerado. Bater em três ou quatro simultaneamente é onde a maioria dos bans acontece. Por isso o setup que funciona em produção ataca todos os 8 vetores em paralelo:

Sinal	Mitigação	Custo
Velocidade inicial	Warmup phased	Tempo (30 dias)
IP suspeito	IP residencial estática (ISP) dedicada	R$ 20-30/mês por IP
Fingerprint genérico	Device + timezone + MCC alinhado	Configuração one-time
Padrão temporal	Jitter randomizado	Throughput menor (-30%)
Sem typing indicator	Humanize ativo	~1.5s de latência por msg
Sem read receipt	Mark-as-read antes de responder	~2-5s de latência
Conteúdo repetitivo	Templates com 5+ variantes	Esforço editorial
Reports	Lista opt-in + monitoramento	Disciplina operacional

Com os 8 mitigados, ban rate cai pra menos de 1%. Com 5-6 mitigados, fica entre 3-7%. Sem nenhum, você está nos 12% de média de mercado, perdendo 1 número a cada 8.

Onde a Catcher entra

Os 8 sinais acima são problemas que todo operador de WhatsApp em escala enfrenta. A pergunta não é se você vai resolver, é quanto tempo você vai gastar resolvendo cada um manualmente vs usando uma plataforma que já resolve por padrão.

A Catcher é nossa resposta. Cada instância vem com IP residencial estática (ISP) dedicada (alinhada à região do DDD quando há inventário), TLS fingerprint sticky de navegador real (Safari ou Chrome validados bytewise contra capture nativa), termômetro de contato (score 0-100 + bloqueio antes de padrão chegar à Meta), humanize com mark-as-read + typing indicator, anti-fingerprinting de mídia (bytes únicos por send) e quarantine automática em 8 rails, as 10 camadas operando integradas, não em isolado. E se ainda assim banir dentro dos limites, a gente devolve o que você pagou + R$ 200 pelo seu tempo perdido, categoria-de-um do mercado.

R$ 97/mês a primeira instância, descendo até R$ 47 em volume. Trial 7 dias com cartão. Ver pricing completo.