[RESOLUÇÃO] - QR Code não gera, loop infinito e Erros 515 e 408 (Pre-key Timeout) - A verdadeira solução para a v2.3.x #2463
Description
Usei bastante o Gemini pro para analisar comigo oque estava de errado e oque teríamos que consertar, após conseguir a aprovação, pedi para que ele gerasse um passo a passo detalhado de como resolver
Obrigado por todos que colocaram Issues aqui, pois foram de grande valia como estudo para meu Gemini.
Olá!
Se você atualizou para a versão 2.3.x (desde a 2.3.3) e está preso numa guerra com a conexão do WhatsApp, este guia é para você. Após dias de testes exaustivos, debugs profundos e várias tentativas frustradas, trago a documentação completa do que não funciona e do que realmente resolve o problema.
🚩 Os Sintomas (A Jornada do Erro)
O problema costuma apresentar-se em duas fases distintas:
Fase 1 (O Vácuo): Você tenta criar uma instância, mas o QR Code simplesmente não gera. Fica a carregar infinitamente.
Fase 2 (A Falsa Esperança): O QR Code finalmente aparece, você escaneia com o celular, o log da Evolution API mostra a glória do CONNECTED TO WHATSAPP, mas segundos depois a instância entra num loop de reinicialização com os seguintes erros fatais:
"msg":"stream errored out" (code: 515)
"message":"Pre-key upload timeout" (statusCode: 408)
❌ O Grande Mito: "O seu IP foi bloqueado pela Meta" (O que NÃO fazer)
Quando você pesquisa por esses erros (especialmente o 515 e o timeout das pre-keys), 99% da comunidade vai dizer que o IP da sua VPS (Hostinger, Hetzner, etc.) está numa blacklist da Meta e que o WebSocket está a ser cortado.
NÃO GASTE DINHEIRO COM PROXIES. Nós testámos esta teoria exaustivamente:
Usámos Proxies de Datacenter (Webshare) -> Falhou.
Subimos uma máquina limpa e gratuita na AWS (EC2 t2.micro) e criámos um TinyProxy privado e exclusivo -> Falhou exatamente com o mesmo erro 408.
Conclusão: Se um IP totalmente novo e limpo da Amazon dá o mesmo erro, a rede é inocente. O bloqueio não é de internet.
🔍 A Verdadeira Causa: O "Gargalo" de Hardware
O problema real é o seu servidor a sofrer um "engarrafamento" de processamento (CPU/RAM).
No momento em que o QR Code é lido, três coisas extremamente pesadas acontecem ao mesmo tempo no seu servidor:
A biblioteca Baileys tenta gerar e enviar milhares de chaves de criptografia pesadas (as pre-keys) para os servidores do WhatsApp.
A Meta envia um "tsunami" com o histórico de mensagens, grupos e contatos do seu celular.
A Evolution API tenta agarrar nesse tsunami e gravar tudo simultaneamente no PostgreSQL e no Redis.
O que acontece: A CPU bate nos 100%. O Redis engasga na rede interna do Docker. O servidor "congela" a pensar, a geração das chaves de segurança atrasa, o tempo limite do WhatsApp esgota (Timeout 408) e a Meta, por segurança, fecha a porta na sua cara (Erro 515).
✅ A Solução Definitiva (Passo a Passo)
Para resolver isso, precisamos de "fechar a torneira" de dados desnecessários e libertar a CPU para focar apenas na criptografia.
Passo 1: Limpeza da Área (Matando os Fantasmas)
Como os processos anteriores falharam a meio, você tem sessões corrompidas presas.
No seu celular, vá ao WhatsApp > Aparelhos Conectados e desconecte as sessões com erro.
No Manager da Evolution API, delete as instâncias problemáticas.
Se estiver a usar n8n ou Webhooks para disparar mensagens logo após a conexão, pause os envios. A API precisa de silêncio absoluto para conectar.
Passo 2: O Tratamento de Choque (Variáveis de Ambiente)
Vá ao seu gerenciador de containers (EasyPanel, Portainer, etc.) e altere as variáveis da Evolution API.
A. Troque o Cache do Redis pela Memória Local:
O Redis gera latência de rede interna e consome muito processamento nesta etapa crítica. A memória local é 100x mais rápida para o Baileys arrancar.
CACHE_REDIS_ENABLED=false
CACHE_LOCAL_ENABLED=true
B. Desative o Tsunami do Banco de Dados:
Impeça que a API tente gravar o histórico passado. Deixe-a focar-se apenas no presente.
DATABASE_SAVE_DATA_CHATS=false
DATABASE_SAVE_DATA_CONTACTS=false
DATABASE_SAVE_DATA_HISTORIC=false
DATABASE_SAVE_DATA_LABELS=false
C. Force a Versão Estável (Opcional, mas altamente recomendado):
Para garantir a melhor comunicação com a versão atual do Baileys.
CONFIG_SESSION_PHONE_VERSION=2.3000.1033773198
Passo 3: Deploy e Triunfo
Salve as variáveis e faça o Restart/Deploy do container da Evolution API.
Vá ao Manager e crie uma NOVA instância com um nome que ainda não usou (para ignorar lixos de cache antigo).
Leia o QR Code.
O log mostrará o CONNECTED TO WHATSAPP e, desta vez, permanecerá estável com o status open. O erro de Pre-key timeout desaparecerá para sempre, pois o seu servidor teve "fôlego" para processar a segurança no tempo exigido pela Meta.
Espero que este documentário detalhado poupe dias de frustração a todos. Um grande abraço à comunidade!