Repository navigation
[META] QR Code / Pairing issues — tracking umbrella #2437
Description
Activity
Também estou com o mesmo problema, caiu do nada e não gera QR CODE. Versão: evoapicloud/evolution-api:v2.3.6.
CONFIG_SESSION_PHONE_VERSION=2.3000.1028457684.Mesmo problema
Same problem here
mesmo problema
Será que tem relação? https://metastatus.com/whatsapp-business-api
Mesmo problema
Reacted by znltoEstava tendo esse mesmo problema e no meu caso o meu servidor tentava fazer a comunicação com as rotas do whatsapp usando ipv6 e isso retornava um erro, e quando eu fazia manualmente com ipv4 ele funcionava, sendo assim coloquei no compose uma instrução para forçar o ipv4 sempre no docker compose da evolution e voltou a aparecer o qrCode, isso também resolveu meu problema de aparece 'open' a instancia e não funcionar direito como se tivesse desconectado.
No compose eu adicionei:
sysctls:
- net.ipv6.conf.all.disable_ipv6=1
- net.ipv6.conf.default.disable_ipv6=1
- net.ipv6.conf.lo.disable_ipv6=1
environment:
# Forçar IPv4 (corrige VPS com IPv6 quebrado)
- NODE_OPTIONS=--dns-result-order=ipv4first.... resto do environment,
acho que pode ser um teste valido.
Todos aqui estão na hostinger?
Pelos meus testes, estou desconfiado que toda a rede da hostinger está bloqueada do lado do facebook, em todas as CDNs.Vou subir um servidor na AWS após o almoço, ou talvez tentar uma vpn e confirmar isso. Aí volto aqui para trazer uma atualização.
Sim, a hostinger está com um problema com a meta, tive problema com 3 VPS.
Mesmo problema aqui
Mesmo problema. Tomara quer resolvam logo.
Se alguém tiver uma alternativa e puder compartilhar.
Não gera QR Code e não envia webhook. Minha VPS é da Hostinger também
Sim, a hostinger está com um problema com a meta, tive problema com 3 VPS.
Webhook também não está enviando eventos né
-
Sim, a hostinger está com um problema com a meta, tive problema com 3 VPS.
Meus Agentes IA pararam todos. Exatamente às 02:55 da manhã
99 remaining items
- marked Error when trying to read QR Code #2057 as a duplicate of this issue
on Apr 22, 2026 - marked Geração de QR code com comportamento estranho na integração com o chatwoot #1984 as a duplicate of this issue
on Apr 22, 2026 - marked Erro logo após leitura do QR Code Versão desenv. 17/09/25 #1949 as a duplicate of this issue
on Apr 22, 2026 - marked Problema com versão 2.3.2 - Não gera QR Code. Mais alguém? #1917 as a duplicate of this issue
on Apr 22, 2026 - marked Qr code are not being generated #1873 as a duplicate of this issue
on Apr 22, 2026 - marked Evolution não gera QR CODE para integrar o WHATSAPP #1871 as a duplicate of this issue
on Apr 22, 2026 - marked Erro 404 no endpoint /instance/qrcode na v2.3.1 #1826 as a duplicate of this issue
on Apr 22, 2026 - added a commit that references this issue
on Apr 25, 2026 - added a commit that references this issue
on Apr 25, 2026 Adjacent — not a fix for QR/pairing failures themselves, but for the post-pairing "ban after 24-48h" pattern that often follows.
Shipped
baileys-antiban-evolutiontoday: adapter that adds rate-limiting + session-stability monitoring + device-fingerprint randomization to Evolution'sBaileysStartupServiceat runtime.https://github.com/kobie3717/baileys-antiban-evolution
Will help if your pairing succeeds but the account dies inside the first week. Won't help if pairing itself fails — that's protocol-level (Baileys upstream). Posting here in case it's adjacent for some people on the thread.
- added a commit that references this issue
on Aug 9, 2026 Working Docker recipe: patching Baileys inside the Evolution image to fix device pairing
The root cause is upstream, not Evolution. WhatsApp changed the companion-registration flow: since ~2026-07-28 the server sends
<notification type='companion_reg_refresh'>after the QR scan, which Baileys acks and discards — sopair-successis never emitted and the phone shows "couldn't link device / não foi possível conectar no momento". See Baileys #2737, reproduced independently in whatsmeow, which means it affects every open client, not just Baileys.Evolution v2.3.7 pins
baileys@7.0.0-rc.9, and no published Baileys release contains the fix (the handler is absent in rc13, rc14 and master). The fix only exists as unmerged PRs.I couldn't find any public recipe for replacing Baileys inside the Evolution image, so here is one that works:
FROM evoapicloud/evolution-api:v2.3.7 WORKDIR /evolution # Alpine is minimal: npm needs git to clone the fork; the package's `prepare` runs tsc. RUN apk add --no-cache git \ && npm install --no-audit --no-fund baileys@github:doryani-ai/Baileys#fix/companion-reg-refresh \ && apk del git # Optional — only if you use the PAIRING CODE flow (Baileys PR #2602 / issue #2600). # WhatsApp sends `link_code_companion_reg` in two shapes; the one without the crypto # fields crashes with Boom('Invalid buffer', 400). This guard skips it. RUN sed -i "s|const linkCodeCompanionReg = getBinaryNodeChild(node, 'link_code_companion_reg');|&\n if (!getBinaryNodeChildBuffer(linkCodeCompanionReg, 'primary_identity_pub')) { break; }|" \ /evolution/node_modules/baileys/lib/Socket/messages-recv.js
Build it, point your compose at the resulting image, and recreate only the
evolution-apiservice.Result: Baileys
7.0.0-rc14, QR pairing works again (state=open, session stable).Two things worth knowing
- Security bonus. rc14 also clears CVE-2026-48063 (Critical —
messages.upsert/ history-sync spoofing and app-state corruption), which affects< rc12. Anyone still on v2.3.7 is exposed regardless of the pairing issue. - Already-paired sessions keep working. This only breaks linking a new device, so it's an onboarding blocker rather than a runtime one.
⚠️ This depends on an unmerged upstream PR — treat it as tracked maintenance debt, not a permanent fix. The real fix is PR #2765 landing upstream and Evolution bumping Baileys.- Security bonus. rc14 also clears CVE-2026-48063 (Critical —
Known symptoms
/instance/connectreturns{"count": 0})stream errored out(code 515) +Pre-key upload timeout(code 408)device_removed)/instance/qrcodereturns 404 (v2.3.1)Known working workaround (community-sourced, see #2463 for full walkthrough)
Set the following env vars and restart the container:
Root cause (per community analysis): the server chokes on CPU/RAM when Baileys generates pre-keys at the same time that the Meta history "tsunami" arrives, causing pre-key timeout → stream error 515 → device kick. Redis over Docker network adds latency; disabling history sync and switching to local cache removes the bottleneck.
Scope
This umbrella tracks the infrastructure-level QR/pairing problem. Sub-topics that deserve their own issue:
For maintainers
All duplicate QR Code issues are being closed with
state_reason: duplicatepointing here. If you want to respond per-user, use this thread as the single source of truth.This issue was reorganized from the original report ("Não gera QR Code da Instancia") as part of the 2026-04 issue triage. The original reporter (@jpedrodouradoo-cell) and all community contributors remain credited in the comment history.