iOS 1.1.0 polls unreachable environments through Tailscale and kills the phone's tunnel every ~4 minutes

[Nelglor]

Summary

Since updating to T3 Code iOS 1.1.0 (App Store, 2026-09-10), my iPhone's Tailscale data plane dies about 3.5 minutes after every VPN restart while T3 is connected. The trigger is T3 polling a configured environment whose tailnet peer is unreachable. Removing that environment stops the failure immediately. Adding it back with the peer unreachable reproduces it on demand.

The receive-loop death itself is a Tailscale iOS bug (tailscale/tailscale#19504, reported to Tailscale as TSS-101601), but 1.1.0 is what exposes it. 1.0.x never did on the same phone, tailnet, and offline peer.

Setup

• iPhone, iOS 26.6.1, Tailscale 1.102.3, T3 Code 1.1.0
• Three environments configured: bb-1 (Linux, headless server behind Tailscale Serve on :3773), GIGAPC (Linux), KatiePC (Windows)
• Phone on home Wi-Fi, direct LAN path to bb-1 and GIGAPC
• KatiePC with Tailscale disconnected (machine on, at the lock screen), so the peer is unreachable on the tailnet

Observed

• T3 gets stuck on "Failed to connect. Retrying bb-1". Tailscale shows MagicSock Function Not Running: ReceiveDERP (magicsock-receive-func-error). Only a VPN off/on recovers it.
• Tailscale's own log on the phone, in the minute before each failure, shows T3 opening new TCP connections to KatiePC's t3 port roughly every 25 seconds (Accept: TCP{phone:port > <katiepc-tailnet-ip>:443}, then open-conn-track: timeout opening ... to node [<katiepc>]), each one driving WireGuard handshake retries to a peer the DERP relay doesn't know.
• Server-side, bb-1 sees the phone fall back to relay-only discovery pings and never answer direct pings until the phone's Tailscale restarts.

Evidence

• Week before the update: 0 phone VPN restarts per day, phone equally active on the tailnet each day.
• Day of the update: 24 restarts, 30 stall bursts, all inside T3 sessions.
• Same day, 7 hours with the phone on the tailnet and T3 closed: 0 stalls.
• Restart to next stall: median 214 s, typical 180 to 260 s (n=26).
• Removed KatiePC from T3 while it was offline: 0 stalls in 28 minutes of active use (baseline one every 4 minutes), and none overnight.
• Re-added KatiePC with its t3 server stopped but Tailscale still up on it: clean. Then disconnected Tailscale on KatiePC: stall 3.5 minutes later.

So the trigger is "environment whose tailnet peer is unreachable", not "environment whose server is down".

Ask

• Back off polling for an environment that is unreachable at the network layer, or stop polling environments that aren't selected in the current view. Continuous new-connection attempts every ~25 s against a dead peer is heavy for a mobile VPN path even without the Tailscale bug.
• Which 1.1.0 change introduced polling of every configured environment? Candidates from the changelog: usage-limit pooling across selected environments (feat(mobile): pool usage limits across selected environments #10334), shared preference sync across environments (fix(settings): sync auto-settle and other shared preferences across environments #9147).

Happy to test a TestFlight build; reproduction takes about four minutes.

[tghamm]

I can replicate this almost exactly. In my case, the only meaningful deltas are that T3 is pointed over tailscale to a Mac server and a Linux server, and I’ve been troubleshooting it for at least 4-5 days. 1.1.0 presently, but seems to predate this specific version.

When the Mac is asleep, I get the timeouts against all of T3 mobile (including Linux sessions) because of a degraded Tailscale connection caused by T3 aggressively probing the Mac. I temporarily removed the Mac from T3 mobile and the problem instantly stopped.

My recommendation would be basically the same - back off in some form. Happy to test also if helpful.

[juliusmarminge]

The preferred solution here is now the per-environment enable switch added in #11478. In Settings → Environments, switch off any environment that should not be polled. Turning it off disconnects that environment and stops its retry loop. The setting persists across app restarts, while keeping the saved connection and cached data so it can be switched back on without pairing again.

The underlying Tailscale receive-loop failure remains tracked upstream in tailscale/tailscale#19504. Closing this since T3 now has a persistent way to exclude specific environments from connection attempts.