Android VPN Keeps Turning Off in the Background: The Setting Was Only Half the Fix

The upload reached 63 percent before I switched to the authenticator app for a login code. When I returned, the browser said there was no internet connection. The VPN key had disappeared from the top of my Android screen, and the upload had returned to zero. I reopened the VPN, connected again, and started from the beginning. Then the phone locked while I answered a call. When I unlocked it, the VPN was off again.

I was working from a hotel lobby in Jaipur, waiting for a taxi to the airport. An overseas client needed a corrected design package before their morning review. I had about twenty-five minutes to upload a 180 MB file and send the download link.

The hotel Wi-Fi could open ordinary websites, but the client’s file portal kept stalling. Mobile data was stronger near the entrance and almost absent beside the reception desk. A VPN made the portal usable, but only while its app remained on the screen.

The moment I opened email, copied a verification code, answered a call, or let the display turn off, the connection vanished.

My search history became increasingly direct:

“Android VPN disconnects when screen off.”

“VPN background me band ho jata hai.”

“Battery optimization off but VPN still stops.”

At least I was not the only person arguing with a small key icon.

Android was closing the app to save power

The VPN I was using came from an established provider. It had years of public history, a large server network, and an Android app with more reviews than I could reasonably read.

That made the failure feel like a temporary software bug. I cleared the cache, changed servers, and reinstalled the app.

Nothing lasted.

One clue came from an Android 16 issue reported after VPN app updates. Google’s public issue tracker describes VPN connectivity failing after an app update and returning only after the device is restarted.

My phone had installed several updates overnight, so I restarted it.

The VPN connected again, and the client portal opened immediately. For a few minutes, I thought the problem was solved.

Then I locked the screen to carry my bag toward the lobby entrance.

When I checked the phone again, the VPN had disappeared.

The restart had fixed one failure, but the repeated background shutdown had a more ordinary cause. Android and phone manufacturers aggressively manage apps that continue running after the user leaves the screen.

A VPN normally runs as a foreground service with a persistent notification. Android also offers an Always-on VPN setting that helps keep the service active or restart it when necessary. Phone manufacturers often add their own battery controls on top.

Samsung has Sleeping apps and a Never sleeping list. Realme exposes background activity and auto-launch controls. Other phones use labels such as Unrestricted battery use, No restrictions, Background activity, or App lock.

The names vary, but the decision is the same: the phone chooses whether the VPN is important enough to remain active when it is no longer visible.

I set the VPN’s battery use to unrestricted, allowed background activity and auto-launch, and enabled Android’s Always-on VPN option.

This time, locking the screen did not remove the key icon.

That was progress. The file still had to reach 100 percent.

Keeping the VPN alive did not preserve the upload

I returned to the client portal and restarted the file.

The progress bar moved beyond 20 percent. I opened the authenticator, copied the required code, and came back. The VPN remained connected.

Forty-two percent.

I moved from the sofa toward the lobby entrance, where the hotel Wi-Fi weakened and the phone switched to mobile data.

The VPN key remained visible, but the upload stopped.

After several seconds, the app displayed “Reconnecting.” The browser waited, then returned an expired-session message. I had to sign in and begin again.

That exposed the part most troubleshooting guides miss. Preventing Android from closing the VPN process solved the background shutdown. It did not make the connection recover quickly when the phone changed networks.

Other Android users describe the same practical sequence: battery optimization is disabled, the app is locked in memory, and Always-on VPN is enabled, yet the connection still breaks when the screen turns off or the phone moves between Wi-Fi and mobile data.

The established provider was now staying alive. It was not keeping my work alive.

Changing servers would not solve that. The server was not moving. My phone was moving between two unreliable networks, and each reconnection destroyed the portal session.

The taxi was eleven minutes away.

The next connection recovered before the portal gave up

I opened OnlydogVPN and selected the preset for a weak, changing network.

There was no country list to study or protocol menu to compare. I connected, reopened the portal, and selected the file again.

The upload started.

At 27 percent, I switched to the authenticator app. The VPN remained active. I returned to the browser and entered the code.

At 48 percent, the hotel Wi-Fi faded and the phone moved to mobile data.

The progress bar paused.

I waited for the error message I had already seen twice.

Instead, it continued.

Sixty-one percent.

Eighty-four.

One hundred.

The portal generated the download link. I copied it into the client chat, sent the message, and received a reply before the taxi arrived: “Got it. Opening now.”

The task was complete.

The Android settings had stopped the operating system from putting the VPN to sleep. The smaller app handled the next problem: it recovered the route when the phone changed networks.

Its HTTP/3-based transport is designed for weak and shifting connections, allowing the session to continue instead of rebuilding everything from the beginning.

The result mattered more than the protocol name. The established VPN stayed visible but lost the upload. The smaller app carried the same file through the Wi-Fi-to-mobile-data switch.

I could not observe whether the earlier failures came from Android process management, the hotel network, the mobile handoff, the provider’s reconnection behavior, or several factors together. What I could observe was that the correct Android permissions and the smaller app’s recovery behavior kept the portal session alive long enough to finish.

“Always on” was not the same as “still working”

After sending the file, I put the phone in my pocket and walked outside.

The client sent a question about one of the exported images. I unlocked the phone, opened the chat, and downloaded the screenshot without reconnecting manually.

That smaller moment clarified the original problem.

I had assumed the VPN was turning off because one Android setting was wrong. In many cases, that is the first thing to fix. Battery optimization, sleeping-app lists, or disabled auto-launch can close a VPN as soon as the operating system decides it has been inactive for too long.

But keeping the process alive is only the foundation.

Always-on VPN can keep or restart the service. It cannot make a slow tunnel recover before a browser upload, call, or messaging session expires. The VPN itself still has to respond well when Wi-Fi disappears, mobile data returns, or the phone wakes from a low-power state.

The established provider offered more countries, more public reviews, and a longer operating history. Those strengths did not help the upload survive the walk from the hotel sofa to the entrance.

The smaller service has fewer server locations, fewer independent ratings, and a shorter public history. Someone who needs a particular exit country every day may still prefer the larger provider.

My requirement was more immediate. I needed the Android VPN to remain useful after I left its screen and after the phone changed networks.

The final fix was not a single battery switch. Android had to stop closing the app, and the VPN had to recover before the work session expired.

The first change kept the key icon visible. The second got the client’s file to 100 percent.