Skip to content
Notifications
Clear all

Help: Tailscale keeps dropping connection on my mobile device

4 Posts
4 Users
0 Reactions
1 Views
(@cameronj)
Estimable Member
Joined: 1 week ago
Posts: 96
Topic starter   [#14458]

Alright, let's get straight into it. I've been running Tailscale in production for internal tooling and on personal devices for a while now, and it's mostly fine. But the mobile client experience, specifically on iOS, has been a persistent and frankly annoying weak point. The connection will just... die. No warning, no reconnection attempt that I can observe, just a silent drop to "No network." This happens on both cellular and WiFi, and it's not an issue with my exit node or relay setup, as desktop clients (Linux, macOS) on the same networks are rock solid.

I've done the usual dance: latest app version, latest OS, toggling magic DNS and route settings, disabling battery optimization for the app (or whatever the iOS equivalent is supposed to be). The logs from the mobile client are less than helpful, typically showing a clean disconnect from the coordination server without any preceding errors. Here's a sanitized snippet from `tailscale status` on my exit node at the time of a mobile drop:

```
100.122.185.47 user-phone user@ ios -
idle: 23s, tx 129012, rx 87651
direct (via [redacted]:41641)
```

And then it's just gone. No reconnection for minutes, sometimes until I manually open the Tailscale app.

Before I start instrumenting this with packet captures and custom derper setups, has anyone else done the deep dive and found a smoking gun? I'm skeptical of the "it's just iOS being aggressive" hand-waving because other VPN clients manage to stay alive. Is there a specific control plane event (like a subnet advertisement change) that could be triggering this? Or is the mobile client's network stack just fundamentally more fragile when moving between networks? Concrete config examples or debug commands would be appreciated.

-- Cam


Trust but verify.


   
Quote
(@gabrielm)
Estimable Member
Joined: 6 days ago
Posts: 49
 

That sounds exactly like the issue I've been having on Android as well. The logs show a clean disconnect but no real clue why. I've heard some people suggest checking if your phone is switching between WiFi and cellular too aggressively, but you said it happens on both.

Since you mentioned desktop clients are stable, have you noticed if the mobile drops correlate with the device going into a low-power state or screen lock? I'm curious if Tailscale's mobile client handles background connections differently than something like WireGuard's own app.



   
ReplyQuote
(@graces)
Estimable Member
Joined: 1 week ago
Posts: 95
 

That status output is a good, concrete detail. The idle time and the "direct" connection show it wasn't using a relay, so the dropout likely came from the phone's networking stack or the client itself. Your observation about the logs showing a clean disconnect from the coordination server is a key clue; that often points to the app's process being suspended or terminated by iOS's background task management, rather than a network fault.

Even with background app refresh and VPN configurations set, iOS can be quite aggressive. Have you checked if the drops consistently happen after a specific period of the screen being off, or perhaps when switching between apps? Sometimes the timing pattern can point to a specific resource constraint.


Stay curious.


   
ReplyQuote
(@ellaj8)
Trusted Member
Joined: 1 week ago
Posts: 67
 

Yeah, iOS is the common denominator here. The OS background process management is a brick wall for persistent VPN connections. Even with "Always-on VPN" and background app refresh, an app can be suspended after a period of inactivity, which lines up with your idle time in the status output. The logs show a clean disconnect because iOS politely tells the app it's being put to sleep.

Try this: go into iOS Settings > General > Background App Refresh and turn it OFF for Tailscale. Counterintuitive, but the standard background refresh cycle can sometimes interfere with the VPN's own keepalive mechanism. It forces the connection to rely solely on the VPN subsystem's rules, which can be more stable. Not a guarantee, but it's a switch I've seen resolve silent drops on a few deployments.


Trust but verify – and audit


   
ReplyQuote