Anti-ban
As práticas que reduzem o risco de o WhatsApp restringir o número de uma pessoa protegida — o que a pesquisa recomenda e o que o código já impõe.
Os Termos do WhatsApp proíbem clientes não oficiais, e o risco de ban do número da pessoa protegida é inerente ao produto (AD-002). A pesquisa achou que Baileys e whatsmeow foram atingidos pelas mesmas ondas de ban, inclusive em uso passivo: a detecção é comportamental e de fingerprint, não por biblioteca. Então o que importa é parecer um dispositivo vinculado comum, usado por uma pessoa.
Aqui está só o que as fontes dizem. Ainda não temos números próprios de ban: até 2026-10-18 nenhum celular real tinha sido pareado.
Regra zero: a instância nunca envia
- Nunca enviar mensagem, status, grupo ou broadcast pela instância (AD-002). Nenhum caminho de código chama um endpoint de envio do WAHA; o compose de dev deixa isso escrito como lembrete.
- A taxa de envio pela instância é, portanto, zero. O que precisa chegar à
pessoa (o link de consentimento e, quando o template
WABA_RECONNECT_TEMPLATEexistir, o pedido de reconexão) sai pela API oficial da Meta (infra/messenger,WABA_*), nunca pela sessão dela. - Sem presença sintética (online, digitando, lido). O adapter não tem chamada de presença.
- A única leitura de perfil é a foto do próprio número conectado; contatos nunca.
O número e o dispositivo
| Prática (pesquisa) | No produto |
|---|---|
| Número já em uso real, não recém-criado | premissa: o número é o da pessoa |
| Um dispositivo vinculado por conta | um pareamento vivo por seat_channel (PAIRING_EXISTS) |
| Preferir código de pareamento; QR como fallback | D3: código no celular da pessoa, QR de reserva |
| Evitar repareamento | reconexão reinicia a sessão existente; só desiste depois de 3 tentativas |
| Estado de autenticação em banco | sessões no Postgres do WAHA (waha-db) |
| Reconexão com backoff | 30 s, 2 min, 10 min (RECONNECT_DELAYS_MS) |
| Biblioteca sempre atualizada | imagem fixada e atualizada por roteiro (Atualizar o WAHA) |
| String de dispositivo constante | ver "Em aberto" abaixo |
Cada pedido de código conta contra o número no WhatsApp, por isso um pareamento
pede no máximo 5 códigos (MAX_CODES_PER_PAIRING) e só pede outro quando o
atual expira. As rotas públicas de pareamento ainda limitam por link e por IP.
Em aberto
A pesquisa recomenda manter constante a string de dispositivo. O POST /api/sessions não define nome nem identificação de dispositivo, então vale o
padrão do WAHA/GOWS. Não verificamos qual é nem se muda entre versões.
Rede: um proxy por sessão
- IP fixo, brasileiro, ISP: só se compra
isp_dedicated; a adoção recusaDATACENTER,FOREIGN_REGISTRYe endereço por onde o WhatsApp não responde. - Poucas sessões por IP:
PROXY_SEATS_PER_IPcomeça em 3. A pesquisa não achou número público e chama 10 por IP de agressivo; o valor sobe quando os nossos números de queda e ban permitirem. - A família junta: as sessões de uma conta vão para o mesmo endereço enquanto houver vaga.
- Sem rotação: "Fresh IPs every renewal" desligado e auto-extend pelo saldo. Endereço vencendo com sessões dentro é incidente, porque todas voltariam de outro IP ao mesmo tempo, o padrão de sequestro de conta.
- Proxy que cai vira reconexão, e reconexão é sinal de risco: uptime do fornecedor importa mais que preço (AD-002).
Detalhes em Proxies.
Em aberto
AD-002 pede validar na prática qual protocolo o GOWS usa melhor no proxy (HTTP ou SOCKS5). A sonda confirma que o WhatsApp é alcançável pelos dois num IP do IPRoyal, mas uma sessão GOWS de longa duração via SOCKS5 ainda não foi medida.
Histórico: uma vez, no vínculo
O WhatsApp só entrega o passado no momento do vínculo e dentro dos limites que o container do WAHA anuncia. A pesquisa pede não repetir sincronização completa a cada reconexão. A configuração (igual em dev e produção):
| Variável no container WAHA | Valor |
|---|---|
WAHA_GOWS_DEVICE_REQUIRE_FULL_SYNC | true |
WAHA_GOWS_DEVICE_HISTORY_SYNC_FULL_SYNC_DAYS_LIMIT / …_RECENT_SYNC_DAYS_LIMIT | WAHA_HISTORY_DAYS (90) |
WAHA_GOWS_DEVICE_HISTORY_SYNC_INITIAL_SYNC_MAX_MESSAGES_PER_CHAT | WAHA_HISTORY_MESSAGES_PER_CHAT (100) |
WAHA_GOWS_DEVICE_HISTORY_SYNC_FULL_SYNC_SIZE_MB_LIMIT / …_STORAGE_QUOTA_MB | 100 |
WAHA_GOWS_DEVICE_HISTORY_SYNC_THUMBNAIL_SYNC_DAYS_LIMIT | 0 (sem miniaturas retroativas) |
WAHA_API_DOWNLOAD_MEDIA / WAHA_EVENTS_DOWNLOAD_MEDIA | false / true (histórico sem mídia) |
- O WAHA guarda o que chega (
gows.storage: mensagens, chats, contatos, grupos; sem etiquetas e semmessageSecrets), e a nossa importação lê essa cópia. WAHA_HISTORY_DAYStambém existe no backend, para a importação parar na mesma borda que o WAHA pediu.- Mudar qualquer limite exige parear todos os celulares de novo. Trate como decisão, não como ajuste.
Fontes
backend/src/domains/channels/adapters/waha-adapter.ts,use-cases/{start-pairing,refresh-challenge,apply-provider-state}.tsbackend/src/domains/proxies/use-cases/{allocate,supply,supply-orders}.ts,backend/src/config/env.tsbackend/docker-compose.yml,backend/docker-compose.prod.yml,backend/src/domains/ingest/use-cases/run-sync.tsbackend/src/http/routes/consents/pairing.route.ts(limites públicos)- Vault: AD-002,
research/2026-09-11-whatsapp-nao-oficial(seção Anti-ban),research/2026-09-11-proxies-residenciais-br(consenso, adendo 2026-09-29),specs/2026-10-18-redesign-blueprint(estágio real)