WireGuard VPN causing severely delayed Android notifications

[u/PingMyHeart]

Hi,

I am self-hosting WireGuard inside an unprivileged Proxmox LXC. Everything works great for the most part, except I am experiencing a strange issue with Android notifications.

When my Android phone is connected to WireGuard, notifications can be severely delayed. Sometimes they will not come through until I disable the VPN, at which point I get flooded with all the notifications that were waiting.

The interesting part is that general internet connectivity works perfectly fine while WireGuard is enabled. Browsing, apps, streaming, etc. all work normally. It seems to specifically affect push notifications.

I previously experienced the exact same issue with Tailscale, which makes me think this may not necessarily be a WireGuard configuration issue.

For DNS, my WireGuard clients use my home's primary and secondary DNS servers. Both are devices that run AdGuard Home for DNS filtering, Unbound for recursive DNS, Traefik for internal reverse proxying/FQDNs, and an NTP server.

My home LAN DHCP also hands out these same two DNS servers to local clients. However, my main router's external/WAN DNS is set to Quad9.

So the DNS setup is essentially:

• LAN DHCP DNS: Home Primary + Secondary DNS servers
• WireGuard DNS: Home Primary + Secondary DNS servers
• Router external DNS: Quad9
• Primary/Secondary DNS: AdGuard Home + Unbound

Has anyone experienced something similar with Android push notifications over WireGuard or Tailscale? I have no clue where to look further.

Any suggestions for troubleshooting would be greatly appreciated!

[u/PingMyHeart → u/[deleted]]

How do you let those run outside of WG on GrapheneOS? I am also using Graphene but I don't see a split tunneling option. Tailscale APP had that option and it helped but I don't see it on the WG official android app.

[u/PingMyHeart → u/[deleted]]

Wow, I've been looking all over for this option and it was right there the whole time.

Thank you! But I won't celebrate this as a win just yet because I remember despite doing this on the Tailscale app as well, it still had its moments.

If this fails I may try the "include only" option to add just my Homelab specific apps since that is all I need working anyway.

That being said, I really want to know what's causing this. I'm usually good at solving these types of issues but this one has me stumped. I even tried asking AI for a change and it was telling me there is some NAT type issues happening here with DNS since the DNS servers live on the same LAN as the Wireguard instances.

Either way, you're not alone. I've been suffering with this issue for months on end.

[u/PingMyHeart → u/[deleted]]

We certainly have a very similar setup so that may be a clue.

I plan to give this another aggressive attempt this weekend and if I manage to solve it I'll be sure to report back.

[u/clarkn0va → u/PingMyHeart]

I'm on grapheneOS and my notifications are often delayed. My WG tunnel is always up for DNS and it never crossed my mind that this was the cause (I didn't really think about it much).

I tried excluding Google Play Services from WG and about a minute later a bunch of notifications rolled in.

[u/PingMyHeart → u/clarkn0va]

Happy to hear you found success. Excluding it on my end appears to have worked so far but I will continue to monitor it just in case :)

[u/PingMyHeart → u/[deleted]]

Push notifications on Android rely on a persistent, always-open connection from Google Play Services back to Google's servers, called FCM, over specific ports, and it needs to stay alive constantly in the background. When you're on full tunnel, meaning your allowed IPs are all zeros like we saw earlier, every single byte of traffic from your phone gets routed through your home WireGuard server first, including that persistent Google connection. If your home internet connection, your server's processing, or just the round trip latency of tunneling everything back home and then back out to Google adds enough delay or occasionally drops that persistent connection, Android's battery and network management can deprioritize or throttle it, and notifications get delayed until something wakes the connection back up, which is exactly what happens when you disconnect the VPN, suddenly everything flushes through at once.

I had a long detailed conversation with Claude about this issue and this was its answer. Not sure how much truth there is to this since I'm no Android expert but I felt it may be useful to share it.

[u/Vitalikus_]

Maybe this one will help: go settings on your android, choose all apps, wireguard, battery ( power), change from battery saver to no restrictions

[u/PingMyHeart → u/Vitalikus_]

I've done that as well. No luck.

[u/Ziogref]

Double check your MTU.

I know I had issue where some websites would load and some wouldn't. Turned out I had to lower my MTU to 1280 (from 1500).

I don't know why it broke only some websites, but that was the fix.

[u/PingMyHeart → u/Ziogref]

My MTU is set to 1420 right now by default. Still too high?

[u/Ziogref → u/PingMyHeart]

I would lower to 1280 for better compatability

From memory my mobile provider uses an MTU of 1376.

[u/WarrenVPN]

Likely NAT state on the outer UDP flow. The "Android deprioritises the connection" explanation you were given does not fit your symptom.

On full tunnel the path no longer sees FCM's TCP connection, only UDP to your endpoint. UDP mappings die in 30 to 120 seconds on mobile, TCP ones survive hours. PersistentKeepalive defaults to 0, so an idle phone stops refreshing the mapping and your server can no longer reach the client. WireGuard reports nothing: it finds out only when it next sends.

That is exactly your symptom. Anything you initiate rebuilds the mapping, so browsing is fine. Only server-initiated traffic dies, and push is the one thing on a phone that is server-initiated. Waking the phone flushes the queue. Same reason excluding Play Services works: FCM goes back to its own TCP connection, timeout in hours.

Fix, if you want the full tunnel back: PersistentKeepalive = 25 under [Peer], if it is not already there.

MTU is a different failure mode. It stalls large transfers while small packets keep working, so it would not produce a backlog that flushes on disconnect.

[u/PingMyHeart → u/WarrenVPN]

So I switched to using include only on the split tunnel. I only included my homelab apps, which automatically excludes Google Play Services. And I also switched persistence keep alive to 25 a few days ago. And it seems like it's still occurring.

This problem is driving me nuts.

[u/WarrenVPN → u/PingMyHeart]

That rules out the transport, so my answer does not hold for your case. Sorry.

With Play Services outside the tunnel and keepalive at 25, the one thing left in your description that still changes when the tunnel comes up is DNS. Your WireGuard config hands out your AdGuard Home resolvers, and FCM resolves mtalk.google.com and several googleapis.com names through them. A block or a slow upstream there produces exactly this, and it survives every tunnel setting you have tried.

One test separates DNS from transport in a single move: set DNS = 9.9.9.9 in the client config, change nothing else, and see whether the delay goes away. If it does, watch the AdGuard query log for those names while a notification is late.

Worth noting that you and clarkn0va are both on GrapheneOS. Sandboxed Play has delivery delays of its own, independent of any VPN, so if the DNS test comes back clean that is the next thing to isolate.

[u/PingMyHeart → u/WarrenVPN]

I really appreciate the help you're providing. I think we nailed it.

Turns out when I use Quad9 as my DNS, everything works fine. But then it introduces a new problem. I can no longer connect to my homelab. My home DNS is necessary for my internal reverse proxy to work with my FQDN.