Sharing a deep-dive I did into a recurring ~30 second message delivery delay on WhatsApp, in case it helps someone else or someone here has more insight into WhatsApp's transport logic
Setup: Reproduced on 3 different Android devices, 3 different manufacturers/ROMs (stock, a custom ROM, and another OEM skin), across both home WiFi and mobile data. So this isn't a single-device or single-network quirk
Symptom: Messages arrive almost instantly with the screen on / app in foreground. As soon as the screen turns off and the app goes to background for a bit, incoming messages take ~30+ seconds to actually show up/notify, even though the phone has a solid connection the whole time
Method: Packet-captured with PCAPdroid on-device, analyzed in Wireshark, filtered to WhatsApp's own traffic by UID. Did this across three separate capture sessions on different days to check for reproducibility
What the packet captures show:
- WhatsApp's QUIC traffic (UDP/443) to Meta's edge servers goes completely unidirectional during the delay — the client sends repeated "Initial" packets with textbook exponential backoff (roughly 0.1s → 0.2s → 0.4s → 0.8s → 1.6s … up to ~30s), and the server never sends a single packet back. Not a rejection (no ICMP unreachable), just total silence. This happened across 5+ separate QUIC flows to different Meta IPs in the same subnet range, consistently, across all 3 capture sessions
- In parallel, on the same device at the same time, plain TCP/443 (TLS) to the same Meta IP addresses completes its handshake normally and transfers data without issue
- There's also a lightweight HTTP/80 channel WhatsApp keeps alive with short keepalives (~10s interval) that never breaks, even while QUIC is failing — so it's not that the app process is fully frozen/killed
What we ruled out:
- DNS filtering (using a private DNS resolver / DoT) — confirmed the resolver's config has no mechanism to intercept traffic post-resolution, and none of the blocked domains correspond to the servers WhatsApp actually connects to for messaging.
- The app process being completely suspended — ruled out because the HTTP/80 keepalive channel survives fine throughout.
- Standard Android Doze whitelist issues — checked and already correctly configured (app whitelisted)
Question: has anyone else noticed WhatsApp relying more heavily on QUIC recently, or noticed fallback-to-TCP behavior taking unusually long when QUIC handshakes fail? Curious whether this is a broader rollout-related regression or something specific to certain network paths/ISPs filtering UDP
Happy to share more packet capture details if useful — trying to keep this post readable rather than dumping raw pcap data
Source: r/GBWhatsapp · by /u/Ankherth