🔗 No es el WebSocket. Es todo lo que lo rodea

«La librería reproduce el protocolo directamente - WhatsApp no la distinguirá» - supuesto que se desmorona al analizarlo. Baileys y whatsapp-web.js funcionan sin navegador ni teléfono, pero no son invisibles. Qué está confirmado y qué es reconstrucción comunitaria.

Por qué persiste la confusión

El tesis original nombra comportamiento y versión de protocolo. Comportamiento confirmado sólidamente. Versión de protocolo como mecanismo de detección no confirmada oficialmente - hipótesis plausible. Paralelo web: extensiones e isTrusted.

Antes / Después

Antes: Dos factores: comportamiento (velocidad sin pausas, sin «escribiendo») y versión de protocolo.

Después: Riesgo confirmado - señales conductuales: velocidad, intervalos perfectos, envío masivo idéntico. Versión de protocolo como factor Meta verificado - no confirmada; hipótesis de librerías retrasadas.

Antes: Ausencia de «escribiendo» = factor principal.

Después: Ausencia de presence (composing, paused) - marcador plausible. Sin confirmación de que Meta verifique ese evento concreto - solo timings antinaturales - antispam conductual.

Baileys vs whatsapp-web.js

Parámetro	Baileys	whatsapp-web.js
Funcionamiento	WebSocket reverse-engineered [✓]	Puppeteer/Chromium [✓]
Riesgo principal	Protocolo + comportamiento	Fingerprints navegador + comportamiento
Marcadores	Protobuf, TLS	webdriver, Canvas/WebGL, isTrusted
Presence	`sendPresenceUpdate()` manual [✓]	Emulación UI

Ninguno más seguro por defecto. Headless genera decenas de señales de automatización.

Confirmado oficialmente

Baileys - implementación reverse-engineered documentada.
WhatsApp prohíbe acceso no oficial y reverse-engineering - viola ToS.
Antispam conductual: velocidad, acciones masivas, intervalos regulares.
IP datacenter = menor confianza - proxy, ARM nube.
WABA - HTTP/REST oficial, arquitectura distinta.
Presence en Baileys - capacidad técnica confirmada; ausencia ≠ detección garantizada.

Mini-caso: 4 números en 20 min

whatsapp-web.js en Docker/Ubuntu. 4 bans en 20 min. Logs: navigator.webdriver = true, sin movimiento de cursor.

Muestra: anomalías técnicas en servidor. No prueba: webdriver como única causa - velocidad de envío combinada.

Segundo caso Baileys: sendPresenceUpdate('composing') + 50 ms/carácter → 150 msg/día. Correlación, no prueba única.

Debate: stealth vs huella de red

Stealth vs TCP/IP en datacenter. Sin confirmación - esquemas grises.

Cifras práctica

500 msg idénticos en 5 s - trigger documentado.
≤30 msg/min - guía.
Benchmarks por edad de cuenta (50/h nuevo, 150–200/h maduro…).
2–5 s delay aleatorio.
1–5 min ban con protocolo desactualizado (foro).
10–30 msg antes de bloqueo «bare» (foro).
1–2/mes cambios Protobuf (foro Baileys).

Últimos bloques - foro, no Meta.

Riesgo extra: forks maliciosos

Paquetes npm falsos Baileys robando chats y tokens - compromiso directo, no antiban.

Mitos

«Protocolo oficial = cliente legítimo» - Falso.

«whatsapp-web.js más seguro por abrir navegador» - Falso.

«QR escaneado = seguro» - Falso.

«Stealth resuelve todo» - No confirmado.

Conclusiones

Riesgo confirmado: perfil conductual.
Versión protocolo como factor Meta - no confirmado.
Riesgos distintos; ninguna ventaja estructural por defecto.
Presence + pausas - correlación positiva, no garantía.
WABA oficial - sin emular protocolo cliente.

🎯 Siguiente paso

¿Caída en Baileys/whatsapp-web.js? Primero perfil conductual. Actualizar librería por estabilidad de sesión, no por «detección de versión».

Conclusión

Regla práctica:

Sin navegador no significa sin huellas - las huellas cambian de capa.