#WhatsApp Web connection flapping — 408 timeout every 1-3 minutes

1 messages · Page 1 of 1 (latest)

grizzled dragon
#

Running OpenClaw 2026.4.26 on a Turing Pi RK1 (aarch64, Ubuntu 22.04, K3s, Ethernet 1Gbps).

WhatsApp Web connects successfully, sends/receives messages, then drops with status 408 (Request Time-out / "Connection was lost") every 1-3 minutes. It auto-reconnects fine but the cycle repeats indefinitely.

What I've checked:

Network is solid: ping to WhatsApp CDN <12ms, HTTPS to web.whatsapp.com works, 0 rx_errors, Gigabit Ethernet
No session conflicts (closed all other WhatsApp Web sessions — initially had a 440 conflict, resolved)
Fresh link — re-paired via openclaw channels login --channel whatsapp after migrating from x86 host
Set TCP keepalive to 60s (net.ipv4.tcp_keepalive_time=60) — no improvement
Gateway restart multiple times — same pattern
No OOM, memory fine (15GB total, 2GB used)

Log pattern:
[whatsapp] Listening for personal WhatsApp inbound messages. [whatsapp] WhatsApp Web connection closed (status 408). Retry 1/12 in 2.14s… [whatsapp] Listening for personal WhatsApp inbound messages. [whatsapp] WhatsApp Web connection closed (status 408). Retry 1/12 in 2.31s…

Occasionally after multiple retries:
[whatsapp] channel exited: {"statusCode":408,"error":"Request Time-out","message":"WebSocket Error (Opening handshake has timed out)"} [whatsapp] auto-restart attempt 1/10 in 5s

Stack trace (when it exits):
promiseTimeout → awaitNextMessage → validateConnection (baileys/Socket/socket.ts) Environment:

OpenClaw 2026.4.26 (be8c246)
RK1 (Rockchip RK3588, aarch64)
Kernel 5.10.160-rockchip
Node v22.22.2
Baileys (bundled with OpenClaw)
Is this a known issue with Baileys on ARM64 or with the current WhatsApp Web protocol? Any config flags to tune the WS connection timeout or heartbeat interval?

upbeat thistleBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

earnest sphinxBOT
#

This looks known-ish for 2026.4.26, but I would not call it ARM64-specific yet.

Key bit: 2026.4.26 predates a WhatsApp fix that exposed the actual Baileys socket timing knobs. The merged PR says OpenClaw previously did not pass/expose keepAliveIntervalMs, connectTimeoutMs, or defaultQueryTimeoutMs, and that Baileys can emit 408 Request Time-out Connection was lost when its inbound-frame watchdog exceeds the keepalive window. (github.com)

So for 2026.4.26 specifically: no, those Baileys WS timing flags are probably not tunable yet in your build. They landed on main after that release as:

{
  web: {
    whatsapp: {
      keepAliveIntervalMs: 15000,
      connectTimeoutMs: 90000,
      defaultQueryTimeoutMs: 120000,
    },
  },
}
#

Main docs now describe these under web.whatsapp.*: keepAliveIntervalMs, connectTimeoutMs, and defaultQueryTimeoutMs. (github.com)

There was also a follow-up fix today making WhatsApp report transport activity into the gateway health system, so stale/wedged sockets don’t sit around until WhatsApp’s own 408 path fires. (github.com)

What I’d try:

  1. Update to a build after Apr 29, 2026 / after PRs #73580 and #72656 if one is available for your install method.
  2. Then add the web.whatsapp timing block above.
  3. Restart gateway.
  4. If it still flaps every 1–3 min, test once outside K3s / with host networking to rule out pod NAT/conntrack/overlay behavior for long-lived WebSockets.

If it still reproduces after those two WhatsApp fixes, that’s worth a GitHub issue with openclaw status --all, openclaw channels status --json, and the redacted 408 log loop.