VPN Keeps Disconnecting on Mobile? Fix Keepalive Settings

A VPN that works during a download but stalls after your phone sits idle often has a different problem from one that disconnects whenever you leave Wi-Fi. Treating both as weak encryption leads to unnecessary configuration changes.

This guide shows how to build a disconnect timeline, test NAT expiration, and choose keepalive settings without confusing them with reconnection controls. Use your own devices and an authorized endpoint, and follow your network's acceptable-use policy.

Start with a timeline, not a shorter timer

Record last successful traffic, screen state, connection type, and the first failed request. Note whether opening the VPN app restores service, or whether you must reconnect manually. These observations distinguish an idle mapping problem from an application suspended by the operating system.

Use the Unix Timestamp Converter below to translate epoch timestamps from exported logs into readable UTC times. Put phone and server events on the same timeline before deciding that one caused another. Check whether a field contains seconds or milliseconds; a three-digit scale error produces meaningless comparisons.

Keep the original log and a separate redacted copy. Remove account identifiers, public addresses, and device names before sharing evidence. A timestamp tells you when something happened, not why, so pair every important entry with a user-visible symptom.

Separate NAT expiration from roaming and sleep

Mobile carriers commonly use carrier-grade NAT, where many subscribers share public addresses. A UDP mapping may expire while your tunnel is quiet. The client still shows a configured interface, but inbound packets no longer reach the expected mapping until the client sends again.

By contrast, network roaming changes the usable path. Switching from Wi-Fi to cellular may replace the source address, change IPv6 availability, and require endpoint resolution or a fresh handshake. Keepalives cannot guarantee uninterrupted traffic during a radio outage or an operating-system network transition.

Use three controlled trials, repeated on the same endpoint:

1. Keep the screen awake and exchange normal traffic for several minutes.
2. Leave the tunnel idle with the screen awake, then request a small page.
3. Repeat with the screen locked, then separately switch between Wi-Fi and cellular.

If only the idle test fails, investigate mappings and tunnel liveness. If only the locked-screen test fails, inspect battery management. If only transitions fail, focus on reconnect behavior. The WireGuard quick start explains why persistent keepalives are useful for peers behind NAT, but they are not mandatory for every peer.

Do not interpret an old WireGuard handshake as an outage by itself. Handshakes are not continuous application probes. Confirm a failure by sending permitted traffic to a known reachable service through the tunnel and observing whether it succeeds.

Set WireGuard keepalives on the NAT-side peer

For a phone behind NAT that must remain reachable during idle periods, a common starting point is PersistentKeepalive = 25 on the phone's peer entry for its server. The value is seconds. Use the app's supported configuration editor or import workflow, rather than assuming desktop configuration paths exist on mobile.

[Interface]
PrivateKey = <CLIENT_PRIVATE_KEY>
Address = 10.44.0.2/32

[Peer]
PublicKey = <SERVER_PUBLIC_KEY>
Endpoint = vpn.example.com:51820
AllowedIPs = 10.44.0.0/24
PersistentKeepalive = 25

This is a split-tunnel example for a private lab subnet, not a complete internet privacy configuration. Replace placeholders locally, and never paste private keys into support tickets. Server forwarding, routes, and firewall policy must already permit the traffic you intend to carry.

A keepalive is an authenticated empty packet that maintains a mapping. It does not increase the carrier's radio coverage, bypass a blocked UDP port, or promise faster downloads. Shorter intervals also mean more radio activity and potential battery impact. Start with the documented value, retest, and avoid reducing it aggressively without evidence.

On a Linux server you administer, collect a compact status snapshot without dumping private keys:

date -u '+%Y-%m-%dT%H:%M:%SZ'
sudo wg show wg0 latest-handshakes
sudo wg show wg0 transfer

The handshake output includes peer public keys and epoch times; treat even public identifiers as operational metadata. Compare counters before and after a controlled client request. Rising transmitted bytes without received replies suggests a path or policy problem, not necessarily a keepalive setting.

Understand OpenVPN ping and restart controls

OpenVPN uses ping traffic and restart timers for related but different purposes. A ping interval creates traffic during quiet periods. A restart timer controls how long the client tolerates missing peer traffic before restarting its connection. Neither setting guarantees a successful reconnect when the network is unavailable.

For a server you control, this common directive illustrates the relationship:

# Server configuration; coordinate with existing pushed options.
keepalive 10 60

In server mode, the helper configures ping behavior and pushes corresponding settings to clients; server-side restart timing is deliberately longer. Do not assume the second number is a universal disconnect deadline on every participant. Consult the OpenVPN community resources for your installed version and client implementation.

For a commercial profile, prefer its documented app settings and ask support before overriding pushed options. Mobile clients do not necessarily implement every desktop directive. Keep a known-good profile so that an experiment can be reversed without rebuilding credentials or weakening certificate verification.

Never remove certificate validation, switch to obsolete cryptography, or disable a kill switch just to make a reconnection appear successful. If traffic resumes only outside the tunnel, you have changed the protection boundary rather than repaired the VPN.

Validate battery, DNS, and recovery behavior

Check the operating system's background activity and VPN options. Android battery restrictions vary by manufacturer; always-on VPN and blocking connections without VPN are separate choices. Apple platforms expose different VPN controls depending on the app and device management. Use supported settings rather than blanket advice to disable every battery safeguard.

After each change, measure recovery time and idle battery impact across comparable trials. Convert your recorded epoch events again with the timestamp conversion tool, and keep all comparisons in UTC. Record whether recovery required unlocking the screen, opening the app, or generating traffic.

Test a private IP and a hostname separately. Working IP connectivity with failed names points toward DNS configuration, which the Linux DNS leak troubleshooting guide explores in more detail. A DNS failure should not automatically trigger more frequent keepalives.

Finally, repeat the test on Wi-Fi and cellular without changing multiple settings at once. For broader privacy trade-offs, the EFF Surveillance Self-Defense guide is useful context: a stable tunnel is only one component of protecting communications.

Key takeaways

• Build a UTC timeline before changing timers; distinguish idle failures, screen-lock suspension, and network transitions.
• Use PersistentKeepalive on the NAT-side WireGuard peer when idle reachability requires it, then measure battery impact.
• Separate OpenVPN ping generation from restart behavior, and preserve certificate verification during troubleshooting.
• Validate DNS and actual application traffic after recovery; a connected badge is not proof of a working protected path.