VPN Works Until the Screen Locks: What to Check

If a VPN works until the screen locks, first prove what stops. The VPN app may be suspended while the operating-system tunnel continues, the tunnel may disconnect at lock, the device may enter deeper sleep later, or Wi-Fi may switch to cellular while the screen is off. Those events can look identical after unlock but require different fixes.

Use the complete VPN guide for the wider connection path. This article isolates the lock transition. If the VPN remains working during a brief lock and fails only after the device sleeps and wakes, use the wake-from-sleep guide.

Key Takeaways

• Reproduce foreground, app-switch, lock, unlock, and sleep as separate transitions.
• Test tunnel behavior with a harmless connection check, not only the app's status label.
• Review background, battery, data, always-on, and managed-policy ownership without disabling protection broadly.
• Keep the network fixed before investigating Wi-Fi-to-cellular or interface changes.
• Do not promise that every VPN app or platform supports always-on, on-demand, or persistent background operation.

1. When the VPN works until the screen locks, does the tunnel stop or only the app UI?

Before locking, note the server or region, connection time, network type, and a harmless indicator that the VPN path is active. Lock the screen for 30 seconds without moving the device. After unlock, check whether protected traffic actually failed, whether the OS still shows a VPN indicator, and whether the app merely refreshed its status late.

Observation after unlock	What it suggests	Next check
Traffic worked while locked; app shows reconnecting briefly	App UI or process was suspended	Background status refresh and logs
Traffic stopped immediately at lock	Lock-triggered policy, app lifecycle, or tunnel ownership	Battery/background and VPN configuration
Traffic stops only after several minutes	Sleep timer, idle timeout, or network power policy	Timed lock versus sleep test
Wi-Fi changes to cellular	Interface transition or Wi-Fi sleep behavior	Hold one network constant
OS VPN indicator disappears	System tunnel was removed or disconnected	Disconnect reason and always-on owner

Do not use a sensitive payment, work transaction, or continuous upload as the probe. A small approved request or provider status check is enough. Record timestamps so the app, OS, and network events can be correlated.

2. Can you reproduce each transition separately?

Run a short transition matrix with the same device, server, protocol, and network:

1. Leave the VPN app in the foreground for two minutes.
2. Switch to another ordinary app without locking for two minutes.
3. Lock for 30 seconds, then unlock.
4. Lock for five minutes while keeping the device stationary.
5. If the platform distinguishes sleep, let it enter sleep and then wake it.

Stop when the first transition reliably causes the failure. Repeating twenty uncontrolled lock cycles adds noise and may trigger account or network rate limits. If switching apps is enough, focus on background execution. If only the long interval fails, compare sleep, idle timeout, and network power policy.

Use a VPN connection test to choose safe observations, but do not publish or send your full IP history, DNS results, or browsing destinations.

3. Are background, battery, or data controls suspending the client?

Modern systems limit background work to save power and data. The exact controls differ by OS, device vendor, management state, and app design. Check the VPN app's battery category, background-data permission, low-power mode, data-saver mode, and any vendor-specific “sleeping apps” list. Record the original value before changing one setting.

Use only the narrow exception required by the platform or VPN vendor. Do not disable battery optimization for every app, turn off endpoint protection, or grant unrelated accessibility and device-administrator permissions. If the system warns that unrestricted background use increases battery consumption, treat that as a tradeoff, not a harmless universal fix.

Android's VPN framework allows an app to provide a VPN service and documents an always-on option that can start the service and block non-VPN traffic, but availability and control depend on the app and device policy.［1］ This does not prove that a particular client supports every persistence mode.

4. Who owns always-on or on-demand behavior?

Always-on, connect-on-demand, auto-connect, and “block connections without VPN” are related but not interchangeable. A user setting may choose one VPN app; a managed policy may enforce a configuration; an app may offer its own trigger rules. Identify the owner before toggling anything.

Apple distinguishes VPN On Demand, which can establish a connection based on rules, from Always On VPN managed through device management.［2］ A work or school device may intentionally prevent the user from changing these controls. If a setting is disabled, shows an organization, or returns after restart, contact the administrator.

Review how VPN auto-connect works for trigger concepts. Do not enable two apps as competing owners, and do not remove a managed profile to test persistence. If the policy deliberately blocks traffic whenever the tunnel is absent, a brief lock-time interruption can appear as complete network loss; preserve that protection while diagnosing the disconnect.

5. Does the underlying network change while locked?

Keep the device beside the access point and temporarily hold one approved network constant. Some devices reduce Wi-Fi activity while locked, roam between access points, or prefer cellular after signal loss. A VPN then has to preserve or rebuild its tunnel across a new interface.

Record Wi-Fi name, signal category, whether cellular is enabled, and whether the interface changed. Test Wi-Fi alone and cellular alone only if your plan and organization policy permit it. Do not disable a managed network, forget credentials, or consume metered data without authorization.

If the VPN survives lock on cellular but not Wi-Fi, investigate router roaming, captive portal expiry, Wi-Fi power policy, and local reachability. If it fails on both at the same transition, app lifecycle, tunnel configuration, or idle policy is more likely. Apple notes that VPN and other third-party security software can affect some network connections, so inspect the named software and its settings rather than deleting all network tools.［3］

6. Is an idle timeout being mistaken for screen lock?

The screen lock and the failure may simply share a timer. Compare a two-minute unlocked idle period, a 30-second lock, and a five-minute lock. If all sessions fail after the same elapsed time, look for server idle timeout, NAT state expiry, reauthentication, or a scheduled token refresh rather than the lock event itself.

Generate minimal harmless traffic only if policy permits; do not run constant pings, automated keep-alives, or synthetic traffic to defeat an enforced timeout. A managed service may require periodic reauthentication by design. Record whether reopening the app reconnects, whether manual reconnect is required, and whether credentials are requested.

If the session fails after wake rather than at lock, move to the sleep guide. If it fails at random while the screen remains on, use general VPN connection troubleshooting instead of forcing this diagnosis.

7. What evidence should you escalate?

Provide device and OS version, VPN app version, original network, server or region, protocol if the client exposes it, exact transition that first fails, timestamps, OS VPN indicator state, and whether traffic or only the app label changed. Include the original and tested battery/background settings.

For a managed device, include the visible policy owner without sending enrollment tokens, certificates, account identifiers, or private configuration. For network changes, report only the interface type and sanitized access-point information.

With AethoVPN on Android, install the current APK before the repeat test so an outdated build is not one of the variables, connect to the same in-app location you used before, then lock the screen for the same interval and check whether the system VPN indicator and a fresh page load survive; on Windows, run lock and sleep as two separate tests with the current .exe build. The app cannot override operating-system suspension, device-management policy, or a Wi-Fi/cellular handover, so keep the timestamps and policy state rather than weakening management controls to keep the tunnel alive. Download the current Android or Windows client, then compare the unlocked and locked runs on the same network.

Summary

Separate a brief screen lock from app switching, long idle, true sleep, and network transition. Confirm whether the system tunnel stops or only the client UI pauses, then test one background, power, policy, or network variable at a time. Preserve always-on and managed protections, and escalate with the first failing transition and redacted timestamps.

FAQ

Why does the VPN icon remain while the app says disconnected?

The app UI may have been suspended and may refresh later than the operating-system tunnel. Test a harmless request and compare OS tunnel status before reconnecting.

Should I disable battery optimization for every app?

No. If the platform or VPN vendor requires a narrow exception, apply it only to the VPN client and record the original setting. Broad exceptions increase battery use and weaken control.

Is screen lock the same as sleep?

No. A screen can lock while the device remains active; deeper sleep may occur minutes later. Short and long lock tests distinguish the transitions.

Will always-on VPN solve every lock-screen disconnect?

No. Support and ownership vary by app, OS, and management policy. Always-on may also block traffic when the tunnel is unavailable, so diagnose the disconnect instead of assuming the setting is a cure.

Why does the VPN fail only when Wi-Fi is enabled?

The device may roam, power down Wi-Fi, encounter a captive portal, or switch interfaces while locked. Hold one network constant and record the transition.

Is automatic keep-alive traffic a safe fix?

Not by default. It can waste power or data and may evade an intentional idle policy. Use only vendor- or administrator-supported behavior.

What should I send to support when the VPN stops on screen lock?

Send versions, network type, exact transition, timestamps, tunnel-versus-UI evidence, and tested settings. Redact account data, certificates, tokens, private hostnames, and browsing history.

Disclaimer: Do not bypass device management, organization policy, metered-data controls, or platform security to keep a VPN active in the background.

Sources:

1. Android Developers, "VPN": https://developer.android.com/develop/connectivity/vpn?authuser=002
2. Apple Platform Deployment, "VPN overview": https://support.apple.com/guide/deployment/vpn-overview-depae3d361d0/web
3. Apple Support, "Check VPN and other third-party software": https://support.apple.com/en-us/102281

Sources checked 6 September 2026.

---

Related Articles:

• Understand the whole VPN path
• Diagnose a VPN after sleep and wake
• Understand VPN auto-connect ownership
• Run a safe VPN connection test