Evolution API, Baileys e WPPConnect resolvem o mesmo problema — conectar números de WhatsApp em servidor — e por isso costumam ser tratados como intercambiáveis. Na hora de colocar proxy, não são. Cada uma conecta ao WhatsApp de um jeito, e o proxy entra num lugar diferente em cada arquitetura. Copiar a configuração de uma para outra é a causa mais comum de "configurei o proxy e continua saindo pelo IP da VPS".
As três arquiteturas lado a lado
| Evolution API | Baileys | WPPConnect | |
|---|---|---|---|
| O que é | API pronta que gerencia instâncias | Biblioteca Node que fala com o WhatsApp por WebSocket | Biblioteca que controla um WhatsApp Web num Chromium |
| Onde o proxy entra | No payload da instância ou em variável de ambiente | No agente passado ao criar o socket | Nos argumentos do Chromium, com autenticação à parte |
| Protocolo mais estável | SOCKS5 ou HTTP | SOCKS5 ou HTTP | HTTP |
| Cuidado principal | Proxy global serve a todas as instâncias | Mídia precisa do mesmo agente | Usuário e senha não vão na URL do Chromium |
Evolution API: por instância ou global
A Evolution API aceita proxy de duas formas:
- Por instância — os dados de proxy vão no corpo da requisição que cria a instância, ou num endpoint próprio para atualizar uma instância existente. É o desenho certo quando há mais de um número, porque cada instância sai por um endereço.
- Global — por variáveis de ambiente, valendo para todas as instâncias do servidor. Simples, mas coloca todos os números no mesmo IP.
O passo a passo, com os campos e o endpoint de atualização, está em proxy na Evolution API.
Baileys: o agente e o detalhe da mídia
No Baileys, o proxy é um agente passado ao criar o socket — com socks-proxy-agent para SOCKS5 ou https-proxy-agent para HTTP.
O detalhe que passa despercebido: existem dois campos. O agent roteia a conexão principal do WebSocket; o fetchAgent roteia o download de mídia. Configurar só o primeiro faz as mensagens saírem pelo proxy e a mídia sair pelo IP da máquina — uma inconsistência de origem na mesma sessão.
Configuração completa, com um proxy por instância, em proxy no Baileys.
WPPConnect: o navegador é quem conecta
O WPPConnect não abre WebSocket direto: ele sobe um Chromium com o WhatsApp Web. Por isso a configuração do Baileys não serve aqui — o agente de proxy do Node não pluga o navegador.
No WPPConnect, o proxy vai nos argumentos do Chromium, sem usuário e senha na URL; a autenticação entra depois, na página. HTTP é o caminho estável; SOCKS5 com senha no Chromium é irregular. O passo a passo está em proxy no WPPConnect.
A regra que vale para as três
Um IP por número que deve parecer independente. Dez instâncias no mesmo servidor, sem proxy por instância, são dez números saindo pelo mesmo endereço — se ele apresentar problema, todos são afetados, e números de clientes diferentes ficam associados.
Antes de conectar o número, confirme o IP de saída de cada instância. Se o teste de IP do proxy passa e a sessão ainda cai, o problema provavelmente não é rede: versão da biblioteca, sessão corrompida ou comportamento do número entram no diagnóstico — ver número banido no WhatsApp API.
Qual escolher, do ponto de vista do proxy
- Quer gerenciar instâncias por API, sem programar a conexão → Evolution API, com proxy por instância.
- Quer controle total em Node e menos recursos por número → Baileys, lembrando do
fetchAgent. - Precisa do WhatsApp Web completo no navegador → WPPConnect, com proxy HTTP.
Nas três, o tipo de IP recomendado é o mesmo: ISP dedicado brasileiro, um por número. O ISP é IP de provedor de internet brasileiro e passou no nosso teste de conexão ao WhatsApp; parte dos IPs de datacenter, como o IPv4 dedicado, não abre o WhatsApp. Por que o IP da VPS costuma ser o problema, e como dimensionar, está em proxy para Evolution API.