iOS iPhone Battery Draining Issue

I have just setup Tailscale on my home network. Loved it!
I ran Tailscale 24/7 on both my iPhones and noticed a significant drop on both iPhones battery life.
I did switched off background app refresh on Tailscale app but that doesn’t stop Tailscale from draining the battery.
Tailscale on iPadOS is fine though.

Waking up the radio frequently is the main cause of battery use in this situation, and there are two common reasons:

  • presence of a very old Tailscale client on the Tailnet, roughly 1.0 or before. The older versions were much more chatty.
  • Periodically contacting another node on the Tailnet (like a DNS server?) but having to use DERP to do so. Each time, the client will try again to find a direct path by sending DISCO messages to all endpoints.

For the first case: upgrading the older node will help.

For the second case: tailscale netcheck can help identify why direct tunnels are not being established.

The last several Tailscale releases added much improved support for NAT-PMP, PCP, and UPnP-IGD, which are protocols to ask a firewall to open a port. Enabling NAT-PMP (etc) in the router can make it possible to get direct connections which otherwise would not.

Hi DGentry,

All of my tailscale clients are running the latest version, 1.14.0 except for iOS devices, which Tailscale only offers version 1.12.3.
Yes, I do have a pi-hole server on my Tailscale network to resolve DNS queries.

I followed your advice and did the tailscale netcheck. Most of my devices are connected via UDP Tailscale default port 41641, so I don’t think there is any complication to establish connection.

Its great that the devices are using port 41641 but are they actually establishing direct connections to the Pi-hole? You can tell this via tailscale status:

$ tailscale status
100.123.126.54  ubuntu     dgentry@   linux   active; direct 10.1.10.13:59969, tx 4152 rx 3276
100.92.61.18    freebsd    dgentry@   freebsd active; relay "fra", tx 1108 rx 188

Or tailscale ping:
pong from server2 (100.101.102.103) via 10.1.10.28:35386 in 2ms
vs:
pong from server2 (100.99.98.97) via DERP(fra) in 88ms