Proxy no WPPConnect

WPPConnect sobe uma sessão de WhatsApp Web dentro de um Chromium controlado. A origem padrão é o IP da máquina. Vários session no mesmo servidor, sem proxy por instância, são vários números no mesmo endereço.

Isso não é o mesmo mecanismo do Baileys. Copiar socks-proxy-agent para o WPPConnect não pluga o browser.

Objetivo deste guia

Fazer cada sessão sair por um IPv4 dedicado brasileiro, sem misturar credenciais entre clientes.

Pré-requisitos

• Credenciais no painel ProxyBox (host, porta HTTP, usuário, senha)
• Teste de IP verde no painel ou cURL respondendo um endereço
• Um IP por sessão independente
• Pacote @wppconnect-team/wppconnect já instalado no projeto

Passo 1 — Proxy HTTP no Chromium

O Chromium aceita --proxy-server sem usuário e senha na URL. A autenticação entra depois.

import wppconnect from '@wppconnect-team/wppconnect'

const proxyHost = 'p1.exemplo.com'
const proxyPort = 8000
const proxyUser = 'seu-usuario'
const proxyPass = 'sua-senha'

const client = await wppconnect.create({
  session: 'cliente-a',
  puppeteerOptions: {
    args: [`--proxy-server=http://${proxyHost}:${proxyPort}`],
  },
})

Confira na sua versão se a opção se chama puppeteerOptions ou browserArgs. O efeito é o mesmo: o processo Chrome precisa nascer já apontando para o host:porta.

Passo 2 — Autenticação (usuário e senha)

Chromium não lê http://usuario:senha@host:porta de forma confiável. Depois que o browser existe, autentique a página:

const page = client.page // o nome do accessor varia; confira no client da sua versão
await page.authenticate({
  username: proxyUser,
  password: proxyPass,
})

Se a sua versão do WPPConnect não expõe page de forma estável, o padrão de produção é um encaminhador local:

npm install proxy-chain

import ProxyChain from 'proxy-chain'

const anonymized = await ProxyChain.anonymizeProxy(
  `http://${proxyUser}:${proxyPass}@${proxyHost}:${proxyPort}`
)

await wppconnect.create({
  session: 'cliente-a',
  puppeteerOptions: {
    args: [`--proxy-server=${anonymized}`],
  },
})

O browser fala com 127.0.0.1 sem senha; o proxy-chain injeta a credencial no proxy real. Feche o proxy anonimizado no shutdown da sessão para não vazar processo.

Passo 3 — Uma sessão, um IP

const contas = [
  { session: 'cliente-a', host: 'p1.exemplo.com', user: 'user_a', pass: 'pass_a' },
  { session: 'cliente-b', host: 'p2.exemplo.com', user: 'user_b', pass: 'pass_b' },
]

Cada objeto vira um create() com o --proxy-server daquele host. Reutilizar o mesmo IP em dois session anula o motivo de ter dois números.

Verificação

1. Painel ProxyBox → Testar proxy → país BR no plano padrão.
2. Com a sessão aberta, um verificador de IP no próprio WhatsApp Web (ou uma aba no mesmo Chromium) deve devolver o IP contratado, não o da VPS.
3. Dois números, dois testes, dois endereços.

Erros comuns

Os dois números saem iguais. A segunda instância herdou host da primeira, ou o Chromium subiu sem --proxy-server.

407 / proxy authentication required. A senha não chegou ao proxy: page.authenticate não rodou, ou o proxy-chain está com URL malformada (espaço na cola).

Sessão sobe na VPS mesmo com args. Você passou browserArgs numa chave que a versão ignora. Logue process.spawnargs do Chrome ou abra chrome://version no browser da sessão.

Sessão cai com o proxy no ar. Origem ok; investigue auth state, versão do WhatsApp Web e device. O proxy não substitui isso.

SOCKS5 “porque no Baileys funciona”. No Chromium, comece em HTTP. SOCKS5 entra só com encaminhador, não como primeira tentativa.

Depois de configurar

• Baileys se a stack for socket Node, não Chromium
• Evolution API se você mistura as duas
• Boas práticas de IP dedicado
• Landing Evolution se ainda vai comprar o IP