Welcome!
What did you do?
🇧🇷 [PT-BR] Falha silenciosa ao gerar QR Code (Baileys) - Retorna {"count":0}
Subi a Evolution API via Docker Compose (PostgreSQL+Redis). Criei uma instância WHATSAPP-BAILEYS no Manager. Como a tela do Manager não exibiu o QR Code, disparei uma requisição local para forçar a conexão:
curl -X GET "https://meu-dominio.com.br/instance/connect/nome-da-instancia" -H "apikey: GLOBAL_KEY"
🇺🇸 [EN-US] Silent failure on Baileys QR Code generation - Returns {"count":0}
Spun up the Evolution API via Docker Compose (PostgreSQL+Redis). Created a WHATSAPP-BAILEYS instance via the Manager. Since the Manager UI failed to load the QR code, I fired a local request to force the connection:
curl -X GET "https://my-domain.com/instance/connect/instance-name" -H "apikey: GLOBAL_KEY"
What did you expect?
🇧🇷 [PT-BR]
Esperava que o QR Code fosse gerado em base64 na resposta do curl (ou renderizado via WebSocket no Manager) e que o terminal do Docker na VPS (docker logs -f) começasse a registrar os logs do motor do Baileys iniciando a sessão.
🇺🇸 [EN-US]
I expected the QR Code payload to be returned in base64 (or rendered via WebSocket in the Manager), and the Docker terminal (docker logs -f) to show the Baileys engine startup sequence logs.
What did you observe instead of what you expected?
🇧🇷 [PT-BR]
O Manager não exibe nada. O curl responde instantaneamente com {"count":0}. O mais grave é que o terminal da VPS (docker logs -f) não registra absolutamente nenhuma linha de log, aviso ou erro. A requisição morre silenciosamente, como se o evento do WebSocket não encontrasse a instância.
🇺🇸 [EN-US]
The Manager UI displays nothing. The curl request instantly returns {"count":0}. Crucially, the VPS terminal (docker logs -f) shows absolutely zero activity, warnings, or errors. The request dies silently before hitting the event emitter.
Screenshots/Videos
Which version of the API are you using?
2.2.3
What is your environment?
Docker Compose (Linux VPS)
Other environment specifications
🇧🇷 [PT-BR]
Docker Compose (Linux VPS)
Other environment specifications
- Hospedagem: Google Cloud Platform (GCP)
- Proxy Reverso: Caddy
- CDN/DNS: Cloudflare (Full Strict habilitado)
- Banco/Cache: PostgreSQL 15 + Redis (rodando isolado no banco 1: redis://redis:6379/1)
- Variáveis já configuradas no .env: WEBSOCKET_ENABLED=true e WEBSOCKET_GLOBAL_EVENTS=true
🇺🇸 [EN-US]
Docker Compose (Linux VPS)
Other environment specifications
- Hosting: Google Cloud Platform (GCP)
- Reverse Proxy: Caddy
- CDN/DNS: Cloudflare (Full Strict enabled)
- DB/Cache: PostgreSQL 15 + Redis (isolated on db 1: redis://redis:6379/1)
- Env vars already set: WEBSOCKET_ENABLED=true and WEBSOCKET_GLOBAL_EVENTS=true
If applicable, paste the log output
// Inspect Payload upon instance creation (born with 'close' status):
[{"name":"teste-macbook","connectionStatus":"close","integration":"WHATSAPP-BAILEYS","token":"...","Websocket":null}]
// cURL response for /instance/connect route:
{"count":0}
// Docker Logs (docker logs -f) during the request:
(Completely empty. The API does not emit any logs for this aborted request).
Additional Notes
🇧🇷 [PT-BR]
-Já fiz um "Hard Reset" da stack (docker compose down -v e up -d) para garantir que não era lixo no cache do Redis.
-Há um mês eu tive exatamente esse erro usando uma VPS da Contabo. Na época, sugeriram que era bloqueio de ASN/IP pela Meta. Agora refiz toda a infraestrutura do zero no Google Cloud (GCP) com IP limpo e o comportamento persiste.
-Parece ser um bug de inicialização do socket ou falha no event emitter na versão atual.
🇺🇸 [EN-US]
-Performed a "Hard Reset" (docker compose down -v and up -d) to ensure no zombie cache was left in Redis.
-Experienced this exact issue a month ago on a Contabo VPS. At the time, it was suggested to be an ASN/IP block by Meta. I have now rebuilt the entire infrastructure from scratch on Google Cloud (GCP) with a clean IP, and the exact same behavior persists.
-It appears to be a socket initialization bug or an event emitter failure in the current version.
Welcome!
What did you do?
🇧🇷 [PT-BR] Falha silenciosa ao gerar QR Code (Baileys) - Retorna {"count":0}
Subi a Evolution API via Docker Compose (PostgreSQL+Redis). Criei uma instância WHATSAPP-BAILEYS no Manager. Como a tela do Manager não exibiu o QR Code, disparei uma requisição local para forçar a conexão:
curl -X GET "https://meu-dominio.com.br/instance/connect/nome-da-instancia" -H "apikey: GLOBAL_KEY"
🇺🇸 [EN-US] Silent failure on Baileys QR Code generation - Returns {"count":0}
Spun up the Evolution API via Docker Compose (PostgreSQL+Redis). Created a WHATSAPP-BAILEYS instance via the Manager. Since the Manager UI failed to load the QR code, I fired a local request to force the connection:
curl -X GET "https://my-domain.com/instance/connect/instance-name" -H "apikey: GLOBAL_KEY"
What did you expect?
🇧🇷 [PT-BR]
Esperava que o QR Code fosse gerado em base64 na resposta do curl (ou renderizado via WebSocket no Manager) e que o terminal do Docker na VPS (docker logs -f) começasse a registrar os logs do motor do Baileys iniciando a sessão.
🇺🇸 [EN-US]
I expected the QR Code payload to be returned in base64 (or rendered via WebSocket in the Manager), and the Docker terminal (docker logs -f) to show the Baileys engine startup sequence logs.
What did you observe instead of what you expected?
🇧🇷 [PT-BR]
O Manager não exibe nada. O curl responde instantaneamente com {"count":0}. O mais grave é que o terminal da VPS (docker logs -f) não registra absolutamente nenhuma linha de log, aviso ou erro. A requisição morre silenciosamente, como se o evento do WebSocket não encontrasse a instância.
🇺🇸 [EN-US]
The Manager UI displays nothing. The curl request instantly returns {"count":0}. Crucially, the VPS terminal (docker logs -f) shows absolutely zero activity, warnings, or errors. The request dies silently before hitting the event emitter.
Screenshots/Videos
Which version of the API are you using?
2.2.3
What is your environment?
Docker Compose (Linux VPS)
Other environment specifications
🇧🇷 [PT-BR]
Docker Compose (Linux VPS)
Other environment specifications
🇺🇸 [EN-US]
Docker Compose (Linux VPS)
Other environment specifications
If applicable, paste the log output
// Inspect Payload upon instance creation (born with 'close' status):
[{"name":"teste-macbook","connectionStatus":"close","integration":"WHATSAPP-BAILEYS","token":"...","Websocket":null}]
// cURL response for /instance/connect route:
{"count":0}
// Docker Logs (docker logs -f) during the request:
(Completely empty. The API does not emit any logs for this aborted request).
Additional Notes
🇧🇷 [PT-BR]
-Já fiz um "Hard Reset" da stack (docker compose down -v e up -d) para garantir que não era lixo no cache do Redis.
-Há um mês eu tive exatamente esse erro usando uma VPS da Contabo. Na época, sugeriram que era bloqueio de ASN/IP pela Meta. Agora refiz toda a infraestrutura do zero no Google Cloud (GCP) com IP limpo e o comportamento persiste.
-Parece ser um bug de inicialização do socket ou falha no event emitter na versão atual.
🇺🇸 [EN-US]
-Performed a "Hard Reset" (docker compose down -v and up -d) to ensure no zombie cache was left in Redis.
-Experienced this exact issue a month ago on a Contabo VPS. At the time, it was suggested to be an ASN/IP block by Meta. I have now rebuilt the entire infrastructure from scratch on Google Cloud (GCP) with a clean IP, and the exact same behavior persists.
-It appears to be a socket initialization bug or an event emitter failure in the current version.